\documentclass[11pt,twoside]{article}\makeatletter

\IfFileExists{xcolor.sty}%
  {\RequirePackage{xcolor}}%
  {\RequirePackage{color}}
\usepackage{colortbl}
\usepackage{wrapfig}
\usepackage{ifxetex}
\ifxetex
  \usepackage{fontspec}
  \usepackage{xunicode}
  \catcode`⃥=\active \def⃥{\textbackslash}
  \catcode`❴=\active \def❴{\{}
  \catcode`❵=\active \def❵{\}}
  \def\textJapanese{\fontspec{Noto Sans CJK JP}}
  \def\textChinese{\fontspec{Noto Sans CJK SC}}
  \def\textKorean{\fontspec{Noto Sans CJK KR}}
  \setmonofont{DejaVu Sans Mono}
  
\else
  \IfFileExists{utf8x.def}%
   {\usepackage[utf8x]{inputenc}
      \PrerenderUnicode{–}
    }%
   {\usepackage[utf8]{inputenc}}
  \usepackage[english]{babel}
  \usepackage[T1]{fontenc}
  \usepackage{float}
  \usepackage[]{ucs}
  \uc@dclc{8421}{default}{\textbackslash }
  \uc@dclc{10100}{default}{\{}
  \uc@dclc{10101}{default}{\}}
  \uc@dclc{8491}{default}{\AA{}}
  \uc@dclc{8239}{default}{\,}
  \uc@dclc{20154}{default}{ }
  \uc@dclc{10148}{default}{>}
  \def\textschwa{\rotatebox{-90}{e}}
  \def\textJapanese{}
  \def\textChinese{}
  \IfFileExists{tipa.sty}{\usepackage{tipa}}{}
\fi
\def\exampleFont{\ttfamily\small}
\DeclareTextSymbol{\textpi}{OML}{25}
\usepackage{relsize}
\RequirePackage{array}
\def\@testpach{\@chclass
 \ifnum \@lastchclass=6 \@ne \@chnum \@ne \else
  \ifnum \@lastchclass=7 5 \else
   \ifnum \@lastchclass=8 \tw@ \else
    \ifnum \@lastchclass=9 \thr@@
   \else \z@
   \ifnum \@lastchclass = 10 \else
   \edef\@nextchar{\expandafter\string\@nextchar}%
   \@chnum
   \if \@nextchar c\z@ \else
    \if \@nextchar l\@ne \else
     \if \@nextchar r\tw@ \else
   \z@ \@chclass
   \if\@nextchar |\@ne \else
    \if \@nextchar !6 \else
     \if \@nextchar @7 \else
      \if \@nextchar (8 \else
       \if \@nextchar )9 \else
  10
  \@chnum
  \if \@nextchar m\thr@@\else
   \if \@nextchar p4 \else
    \if \@nextchar b5 \else
   \z@ \@chclass \z@ \@preamerr \z@ \fi \fi \fi \fi
   \fi \fi  \fi  \fi  \fi  \fi  \fi \fi \fi \fi \fi \fi}
\gdef\arraybackslash{\let\\=\@arraycr}
\def\@textsubscript#1{{\m@th\ensuremath{_{\mbox{\fontsize\sf@size\z@#1}}}}}
\def\Panel#1#2#3#4{\multicolumn{#3}{){\columncolor{#2}}#4}{#1}}
\def\abbr{}
\def\corr{}
\def\expan{}
\def\gap{}
\def\orig{}
\def\reg{}
\def\ref{}
\def\sic{}
\def\persName{}\def\name{}
\def\placeName{}
\def\orgName{}
\def\textcal#1{{\fontspec{Lucida Calligraphy}#1}}
\def\textgothic#1{{\fontspec{Lucida Blackletter}#1}}
\def\textlarge#1{{\large #1}}
\def\textoverbar#1{\ensuremath{\overline{#1}}}
\def\textquoted#1{‘#1’}
\def\textsmall#1{{\small #1}}
\def\textsubscript#1{\@textsubscript{\selectfont#1}}
\def\textxi{\ensuremath{\xi}}
\def\titlem{\itshape}
\newenvironment{biblfree}{}{\ifvmode\par\fi }
\newenvironment{bibl}{}{}
\newenvironment{byline}{\vskip6pt\itshape\fontsize{16pt}{18pt}\selectfont}{\par }
\newenvironment{citbibl}{}{\ifvmode\par\fi }
\newenvironment{docAuthor}{\ifvmode\vskip4pt\fontsize{16pt}{18pt}\selectfont\fi\itshape}{\ifvmode\par\fi }
\newenvironment{docDate}{}{\ifvmode\par\fi }
\newenvironment{docImprint}{\vskip 6pt}{\ifvmode\par\fi }
\newenvironment{docTitle}{\vskip6pt\bfseries\fontsize{22pt}{25pt}\selectfont}{\par }
\newenvironment{msHead}{\vskip 6pt}{\par}
\newenvironment{msItem}{\vskip 6pt}{\par}
\newenvironment{rubric}{}{}
\newenvironment{titlePart}{}{\par }

\newcolumntype{L}[1]{){\raggedright\arraybackslash}p{#1}}
\newcolumntype{C}[1]{){\centering\arraybackslash}p{#1}}
\newcolumntype{R}[1]{){\raggedleft\arraybackslash}p{#1}}
\newcolumntype{P}[1]{){\arraybackslash}p{#1}}
\newcolumntype{B}[1]{){\arraybackslash}b{#1}}
\newcolumntype{M}[1]{){\arraybackslash}m{#1}}
\definecolor{label}{gray}{0.75}
\def\unusedattribute#1{\sout{\textcolor{label}{#1}}}
\DeclareRobustCommand*{\xref}{\hyper@normalise\xref@}
\def\xref@#1#2{\hyper@linkurl{#2}{#1}}
\begingroup
\catcode`\_=\active
\gdef_#1{\ensuremath{\sb{\mathrm{#1}}}}
\endgroup
\mathcode`\_=\string"8000
\catcode`\_=12\relax

\usepackage[a4paper,twoside,lmargin=1in,rmargin=1in,tmargin=1in,bmargin=1in,marginparwidth=0.75in]{geometry}
\usepackage{framed}

\definecolor{shadecolor}{gray}{0.95}
\usepackage{longtable}
\usepackage[normalem]{ulem}
\usepackage{fancyvrb}
\usepackage{fancyhdr}
\usepackage{graphicx}
\usepackage{marginnote}

\renewcommand{\@cite}[1]{#1}


\renewcommand*{\marginfont}{\itshape\footnotesize}

\def\Gin@extensions{.pdf,.png,.jpg,.mps,.tif}

  \pagestyle{fancy}

\usepackage[pdftitle={A Comparison between Agile and Traditional Software Development Methodologies},
 pdfauthor={}]{hyperref}
\hyperbaseurl{}

	 \paperwidth210mm
	 \paperheight297mm
              
\def\@pnumwidth{1.55em}
\def\@tocrmarg {2.55em}
\def\@dotsep{4.5}
\setcounter{tocdepth}{3}
\clubpenalty=8000
\emergencystretch 3em
\hbadness=4000
\hyphenpenalty=400
\pretolerance=750
\tolerance=2000
\vbadness=4000
\widowpenalty=10000

\renewcommand\section{\@startsection {section}{1}{\z@}%
     {-1.75ex \@plus -0.5ex \@minus -.2ex}%
     {0.5ex \@plus .2ex}%
     {\reset@font\Large\bfseries}}
\renewcommand\subsection{\@startsection{subsection}{2}{\z@}%
     {-1.75ex\@plus -0.5ex \@minus- .2ex}%
     {0.5ex \@plus .2ex}%
     {\reset@font\Large}}
\renewcommand\subsubsection{\@startsection{subsubsection}{3}{\z@}%
     {-1.5ex\@plus -0.35ex \@minus -.2ex}%
     {0.5ex \@plus .2ex}%
     {\reset@font\large}}
\renewcommand\paragraph{\@startsection{paragraph}{4}{\z@}%
     {-1ex \@plus-0.35ex \@minus -0.2ex}%
     {0.5ex \@plus .2ex}%
     {\reset@font\normalsize}}
\renewcommand\subparagraph{\@startsection{subparagraph}{5}{\parindent}%
     {1.5ex \@plus1ex \@minus .2ex}%
     {-1em}%
     {\reset@font\normalsize\bfseries}}


\def\l@section#1#2{\addpenalty{\@secpenalty} \addvspace{1.0em plus 1pt}
 \@tempdima 1.5em \begingroup
 \parindent \z@ \rightskip \@pnumwidth 
 \parfillskip -\@pnumwidth 
 \bfseries \leavevmode #1\hfil \hbox to\@pnumwidth{\hss #2}\par
 \endgroup}
\def\l@subsection{\@dottedtocline{2}{1.5em}{2.3em}}
\def\l@subsubsection{\@dottedtocline{3}{3.8em}{3.2em}}
\def\l@paragraph{\@dottedtocline{4}{7.0em}{4.1em}}
\def\l@subparagraph{\@dottedtocline{5}{10em}{5em}}
\@ifundefined{c@section}{\newcounter{section}}{}
\@ifundefined{c@chapter}{\newcounter{chapter}}{}
\newif\if@mainmatter 
\@mainmattertrue
\def\chaptername{Chapter}
\def\frontmatter{%
  \pagenumbering{roman}
  \def\thechapter{\@roman\c@chapter}
  \def\theHchapter{\roman{chapter}}
  \def\thesection{\@roman\c@section}
  \def\theHsection{\roman{section}}
  \def\@chapapp{}%
}
\def\mainmatter{%
  \cleardoublepage
  \def\thechapter{\@arabic\c@chapter}
  \setcounter{chapter}{0}
  \setcounter{section}{0}
  \pagenumbering{arabic}
  \setcounter{secnumdepth}{6}
  \def\@chapapp{\chaptername}%
  \def\theHchapter{\arabic{chapter}}
  \def\thesection{\@arabic\c@section}
  \def\theHsection{\arabic{section}}
}
\def\backmatter{%
  \cleardoublepage
  \setcounter{chapter}{0}
  \setcounter{section}{0}
  \setcounter{secnumdepth}{2}
  \def\@chapapp{\appendixname}%
  \def\thechapter{\@Alph\c@chapter}
  \def\theHchapter{\Alph{chapter}}
  \appendix
}
\newenvironment{bibitemlist}[1]{%
   \list{\@biblabel{\@arabic\c@enumiv}}%
       {\settowidth\labelwidth{\@biblabel{#1}}%
        \leftmargin\labelwidth
        \advance\leftmargin\labelsep
        \@openbib@code
        \usecounter{enumiv}%
        \let\p@enumiv\@empty
        \renewcommand\theenumiv{\@arabic\c@enumiv}%
	}%
  \sloppy
  \clubpenalty4000
  \@clubpenalty \clubpenalty
  \widowpenalty4000%
  \sfcode`\.\@m}%
  {\def\@noitemerr
    {\@latex@warning{Empty `bibitemlist' environment}}%
    \endlist}

\def\tableofcontents{\section*{\contentsname}\@starttoc{toc}}
\parskip0pt
\parindent1em
\def\Panel#1#2#3#4{\multicolumn{#3}{){\columncolor{#2}}#4}{#1}}
\newenvironment{reflist}{%
  \begin{raggedright}\begin{list}{}
  {%
   \setlength{\topsep}{0pt}%
   \setlength{\rightmargin}{0.25in}%
   \setlength{\itemsep}{0pt}%
   \setlength{\itemindent}{0pt}%
   \setlength{\parskip}{0pt}%
   \setlength{\parsep}{2pt}%
   \def\makelabel##1{\itshape ##1}}%
  }
  {\end{list}\end{raggedright}}
\newenvironment{sansreflist}{%
  \begin{raggedright}\begin{list}{}
  {%
   \setlength{\topsep}{0pt}%
   \setlength{\rightmargin}{0.25in}%
   \setlength{\itemindent}{0pt}%
   \setlength{\parskip}{0pt}%
   \setlength{\itemsep}{0pt}%
   \setlength{\parsep}{2pt}%
   \def\makelabel##1{\upshape ##1}}%
  }
  {\end{list}\end{raggedright}}
\newenvironment{specHead}[2]%
 {\vspace{20pt}\hrule\vspace{10pt}%
  \phantomsection\label{#1}\markright{#2}%

  \pdfbookmark[2]{#2}{#1}%
  \hspace{-0.75in}{\bfseries\fontsize{16pt}{18pt}\selectfont#2}%
  }{}
      \def\TheFullDate{2020-01-15 (revised: 15 January 2020)}
\def\TheID{10.34257/GJCSTCVOL20IS2PG7\makeatother }
\def\TheDate{2020-01-15}
\title{A Comparison between Agile and Traditional Software Development Methodologies}
\author{}\makeatletter 
\makeatletter
\newcommand*{\cleartoleftpage}{%
  \clearpage
    \if@twoside
    \ifodd\c@page
      \hbox{}\newpage
      \if@twocolumn
        \hbox{}\newpage
      \fi
    \fi
  \fi
}
\makeatother
\makeatletter
\thispagestyle{empty}
\markright{\@title}\markboth{\@title}{\@author}
\renewcommand\small{\@setfontsize\small{9pt}{11pt}\abovedisplayskip 8.5\p@ plus3\p@ minus4\p@
\belowdisplayskip \abovedisplayskip
\abovedisplayshortskip \z@ plus2\p@
\belowdisplayshortskip 4\p@ plus2\p@ minus2\p@
\def\@listi{\leftmargin\leftmargini
               \topsep 2\p@ plus1\p@ minus1\p@
               \parsep 2\p@ plus\p@ minus\p@
               \itemsep 1pt}
}
\makeatother
\fvset{frame=single,numberblanklines=false,xleftmargin=5mm,xrightmargin=5mm}
\fancyhf{} 
\setlength{\headheight}{14pt}
\fancyhead[LE]{\bfseries\leftmark} 
\fancyhead[RO]{\bfseries\rightmark} 
\fancyfoot[RO]{}
\fancyfoot[CO]{\thepage}
\fancyfoot[LO]{\TheID}
\fancyfoot[LE]{}
\fancyfoot[CE]{\thepage}
\fancyfoot[RE]{\TheID}
\hypersetup{citebordercolor=0.75 0.75 0.75,linkbordercolor=0.75 0.75 0.75,urlbordercolor=0.75 0.75 0.75,bookmarksnumbered=true}
\fancypagestyle{plain}{\fancyhead{}\renewcommand{\headrulewidth}{0pt}}

\date{}
\usepackage{authblk}

\providecommand{\keywords}[1]
{
\footnotesize
  \textbf{\textit{Index terms---}} #1
}

\usepackage{graphicx,xcolor}
\definecolor{GJBlue}{HTML}{273B81}
\definecolor{GJLightBlue}{HTML}{0A9DD9}
\definecolor{GJMediumGrey}{HTML}{6D6E70}
\definecolor{GJLightGrey}{HTML}{929497} 

\renewenvironment{abstract}{%
   \setlength{\parindent}{0pt}\raggedright
   \textcolor{GJMediumGrey}{\rule{\textwidth}{2pt}}
   \vskip16pt
   \textcolor{GJBlue}{\large\bfseries\abstractname\space}
}{%   
   \vskip8pt
   \textcolor{GJMediumGrey}{\rule{\textwidth}{2pt}}
   \vskip16pt
}

\usepackage[absolute,overlay]{textpos}

\makeatother 
      \usepackage{lineno}
      \linenumbers
      
\begin{document}

             \author[1]{A.K.M Zahidul  Islam}

             \author[2]{Dr. Alex  Ferworn}

             \affil[1]{  Ryerson University, Toronto, Canada}

\renewcommand\Authands{ and }

\date{\small \em Received: 10 December 2019 Accepted: 31 December 2019 Published: 15 January 2020}

\maketitle


\begin{abstract}
        


Agile and Traditional software development methodologies, both are being used in different projects of software development industry. Agile software development technology is an incremental software development process. On the other hand, Traditional software development methodologies or plan-driven software can be explained as a more formal approach to software development. These methodologies come with a fully completed set of systems requirements followed by an architectural and high leveldesign development and inspiration.This research focuses on the software development life cycle, role and responsibilities of agile and traditional software development methodologies and their technical practices. It performs a comparison between both the software development methodologies. Here a questionnaire is used to collect data from the various experts of different IT related organizations of Bangladesh. In the questionnaire, there are three sections to bring out the individual knowledge from different organization, methodology knowledge of the respondents and software development experience of the respondents. The respondents are mainly software engineer, system analyst, software developer etc. A comparison is also performed between this survey result and a survey done by Ambler.

\end{abstract}


\keywords{}

\begin{textblock*}{18cm}(1cm,1cm) % {block width} (coords) 
\textcolor{GJBlue}{\LARGE Global Journals \LaTeX\ JournalKaleidoscope\texttrademark}
\end{textblock*}

\begin{textblock*}{18cm}(1.4cm,1.5cm) % {block width} (coords) 
\textcolor{GJBlue}{\footnotesize \\ Artificial Intelligence formulated this projection for compatibility purposes from the original article published at Global Journals. However, this technology is currently in beta. \emph{Therefore, kindly ignore odd layouts, missed formulae, text, tables, or figures.}}
\end{textblock*}


\begin{textblock*}{10cm}(1.05cm,3cm)
{{\textit{CrossRef DOI of original article:}} \underline{10.34257/GJCSTCVOL20IS2PG7}}
\end{textblock*}\let\tabcellsep& 	 	 		 \par
On the other hand, Traditional software development methodologies or plan-driven software can be explained as a more formal approach to software development. These methodologies come with a fully completed set of systems requirements followed by an architectural and high leveldesign development and inspiration. This research focuses on the software development life cycle, role and responsibilities of agile and traditional software development methodologies and their technical practices. It performs a comparison between both the software development methodologies. Here a questionnaire is used to collect data from the various experts of different IT related organizations of Bangladesh. In the questionnaire, there are three sections to bring out the individual knowledge from different organization, methodology knowledge of the respondents and software development experience of the respondents. The respondents are mainly software engineer, system analyst, software developer etc. A comparison is also performed between this survey result and a survey done by Ambler.\par
The analysis demonstrates the effect on software quality and cost from agile methodology and compares it with ambler (2007) survey and tries to find out correlation between the cost and quality of both the surveys. According to the respondents of the survey (Questionnaire) it is clear that what are the facilities and drawbacks of the traditional and agile software development methodologies for different size of the projects of an organization. At the end of the analysis part of this research it shows that for small scale projects more than 90\% respondent response for agile methodologies and less than 10\% responds for the mix software development technologies which are specific for a organization. For medium scales projects about 50\% responds for agile software developments methodologies, more than 40\% responds for the traditional software development methodologies and less than 10\% responds for the other mix technologies for an organization. For the large scale project less than 10\% responds for agile methodologies, more than 80\% responds for traditional methodologies and slightly more than 10\% responds for the other mix technologies for a specific organization.\par
The findings of this project research study also confirm the appropriateness of the use of agile methodologies for small scale projects, traditional and agile methodologies for medium scale projects and traditional methodologies for large scale projects of an organization. 
\section[{Introduction}]{Introduction}\par
he software development industry is one of the fastest growing industries in the world. By analyzing previous 20 years history of software development it is evident that a lot of brilliant ideas and methods born repeatedly. However, there was no guarantee whether those methods will last long or not though there are a good number of examples to prove this.\par
The concept of "Agile" is new. When it was introduced there was no agreement or explanation on what precisely it refers to. Despite this doubt agile methods became very popular among the industry within a very limited period. Agile was born after introducing extreme programming also known as XP. There are different methodologies comes under agile such as Dynamic Systems Development Method, FDD, TDD, SCRUM and etc.\par
"Agile" has the high reputation and interest in the industry but still there is no clear agreement on how "Agile" can be distinguish from more "Plan-driven" methods which are also known as the traditional methods. So it cannot identify any boundaries or limitations  {\ref (Boehm and Turner)}.There is no any systematic check on agile methods. However, there are some studies to identify the suitability of agile methods for different software project natures. Due to that there are no current events or guidelines for practitioners to select the best method to bring the maximum benefits to their projects.\par
"Agile" is becoming more renowned in the software industry. Agile methods are overtaking tradition methods in projects where requirements are changing frequently. In agile software development there is a series of software behaviors which is conventional as well as controversial. As a result, in the near future the software development industry will find ways to carefully use either the traditional or the agile methods or a hybrid of these two methods.\par
To get highest result and to achieve the goals, a software development team needs to understand and select the most suitable methodologies and techniques for their project. When acquiring the understanding that they can find answers to these questions:\par
"What natures of project they have in hand the possibility of changes while the project in progress?" "What is an appropriate balance of effort between documenting the work and getting the product implemented?" \hyperref[b39]{(Lindvall et al., 2002)} "When does it pay to spend major effort on planning in advance and avoid change, and when is it more beneficial to plan less rigorously and embrace change?" \hyperref[b39]{(Lindvall et al., 2002)} In order to answer properly to above questions and to make the correct decision proper knowledge should be implemented and should be disseminated within the industry. This research aims to develop a set of guidelines to help an organization in their decision making, when selecting the best software development methodology to a given nature of a project or projects, by doing a review on the different traditional and agile methods. 
\section[{a) Aims of the Research}]{a) Aims of the Research}\par
The aims of the research project are:\par
1. Review a number of different software development methods, both traditional and Agile. 2. "Can agile methods be used in any type of software development project?" find out the answer of this question. 3. Come up with a set of guidelines for a software organization to select the most suitable software development methodology for their software projects. 
\section[{b) Objectives of the Research}]{b) Objectives of the Research}\par
The objectives are:\par
1. Carry out a literature survey on different software development methodologies. 2. Understand the lifecycles, roles and practices of these development methodologies. 3. A comparison for agile and traditional development methodologies to understand the similarities and differences. 4. Carry out a survey in the software industry with practitioners and professional in software engineering. \hyperref[b3]{5}. Analyze the gathered data from the survey and summaries them to fulfill the final aim with the help of the knowledge from the literature. 
\section[{c) Research Question}]{c) Research Question}\par
What are the significant factors for a project to consider the most appropriate type of process model, after comparing agile and traditional software development methods? 
\section[{d) Structure of this Research}]{d) Structure of this Research}\par
The first chapter introduces what is the aim and objective of this research and what is the research question of this research. The second chapter introduces the literature review of this research to answer the research question. The third chapter introduces the research design and makes a questioner for the target audience of this research. After a survey from the audience the result of this research is discussed in chapter four. Basically this questioner helps to collect data for this research. Chapter five analyzes the research result and tries to bring out proper methodology for specific software. The final chapter tries to bring out limitation of this study and future aspect of this research. 
\section[{II.}]{II.} 
\section[{Literature Review a) Outline}]{Literature Review a) Outline}\par
The Manifesto for Agile Software Development (MAD) was published in 2001 by a group of seventeen methodologists. This group of experts agreed on a common set of guiding principles and practices around effective software development. The focus was for modeling and documentation of software development projects. The methodologists introduce the guidelines which are: (Fowler and \hyperref[b1]{Highsmith, 2001)} ? Individuals and interactions over processes and tools\par
The main concern in this section is the relationship and communication between the software developers and any other persons involve in the software development process. The dependency on just tools and processes will be minimal.\par
? Working software over comprehensive documentation\par
The main purpose here is to keep the documentation as small as possible and thus concentrating more on building and delivering tested and quality products. Different teams can handle the deliveries differently. Some may deliver hourly or per week while others releases product every two weeks or once a month. 
\section[{? Customer collaboration over contract negotiation}]{? Customer collaboration over contract negotiation}\par
The main concern of this section is the relationship between the development team and the client. The relationship has to be very high. However, the importance of having a contract and changing it accordingly is important as well. Agile starts to release functional program modules as soon as the development process starts and thus it effectively minimizes the risk and disappointment of not meeting the actual requirement at the far end of the project.\par
? Responding to change over following a plan The people who are involved in the software development like programmers, clients and any other should be well knowledgeable about the progress and any changes. Any party have the authority to consider possible changes to the product When it is been developed.\par
The founders of MAD say "while we value the items on the right, we value the items on the left more" (Fowler and \hyperref[b1]{Highsmith, 2001)}, so there are different debates on these values. There are other practitioners including Steven \hyperref[b18]{Rakitin (2001)} who thinks that items on the left are just an excuse for hackers with no regard for engineering discipline.\par
Traditional software development methodologies or plan-driven software can be explained as a more formal approach to software development. These methodologies come with a fully completed set of systems requirements followed by an architectural and high level-design development and inspiration. However, during mid 1990's some practitioners found some steps such as full documentation frustrating and unnecessary time wasting \hyperref[b1]{(Highsmith, 2002)}. Due to these heavy aspects, this methodology is known as heavyweight development methods.\par
Traditional development methodologies all include with the following  {\ref (Williams \& Heckman, 2008}):\par
? Repeatability and predictability ? A defined incremental process The Personal Software Process (PSP), Team Software Process (TSP), and Rational Unified Process (RUP) are the three of the most popular and widely used plan-driven methodologies. Among these plan driven methodologies waterfall model and spiral model are well-known.\par
According to \hyperref[b34]{Davis and Sitaram (1994)} waterfall model have the ability to capture the gross state of the project. Using this model therefore a project manager can track the progress through all major phases of development of major intermediate products. On the other hand spiral model captures the iterative nature of software versions and helps the project manager to isolate the key decision points to select a development strategy. They further argue "Neither of these two models, nor any other published model, provides a project manager with a picture of the true state of the project. Project managers who track project status in terms of the major phases have no idea of the status of their projects."\par
The following table which was published by Abrahamsson et al.,  {\ref (2002)} demonstrates the differences of privileged and marginalized methodological information systems development process. These were a collection of views from different authors in the field. The marginalized methods have much more things in familiar with the original agile development methods. The privileged method projects use more of a process oriented software development methods. These methods also called plan-driven methods.\par
McCauley  {\ref (2001)} argues that the underlying philosophy of Traditional methods which is referred to as process-oriented methods in the article, is that the functional requirements of a project is utterly frozen or in other words sealed before move in to the next phases such as the design and development. The article also states that this approach is not feasible for most of the software projects. So the need of a flexible and agile development methods is necessary for developers to make changes or amendments to the specifications while it is been built. Further according to \hyperref[b13]{McCauley (2001)} there is no software model that suits any nature of software project. It is the project management who should be able to select the best suitable methodology according to the project in hand. There are different other experts in the field who support this argument.\par
The origin of Agile methods go back a long way even though they were properly introduced and started to gain interest in the software industry during the last few years. As mentioned earlier, as a result of built up frustration within the software developers on structured and planed methods in the mid-1990s, development teams started to use early versions of some of the agile methodologies such as Extreme Programming (XP), SCRUM and Dynamic Systems Development Method (DSDM).\par
The Agile methodologies describe a number of principles which in summary put the human factor (customers and developers) first over processes and plans. The highest priority principle is to satisfy the customer through early and continuous delivery of software. According to \hyperref[b14]{Miller (2001)} there are a number of characteristics of agile methods from a fast delivery view, which ultimately shortens the software project lifecycle:\par
1. Modularity -This is on the process level of development 2. Iterative -Consider short development cycles which enables to clear error faster and more accurate 3. Time bound -iterative cycles ranging from one to six weeks 4. Parsimony -remove all the unnecessary activities in the development 5. Adaptive -Take faster action against possible new emerging risks 6. Incremental -A functioning application software, build up in smaller steps 7. Convergent -Minimizes risks 8. People-oriented -Agile favour people who are involved over the process and technology 9. Collaborative -Active communication.\par
In  {\ref Barry Boehm's IEEE computer article (2002)} it is mentioned that according to  there are several critical people-factors which agile highlights, such as amicability, talent, skill, and communication.  further describes, what is new in agile is not the behaviors or practices they use but the recognition of users or any other people involved as the primary sources which drive the project to a success.\par
Agile does not require highly-capable people to execute its practices in a software project environment. However, it requires tacit knowledge and lot of expertise to function successfully. Due to this reason agile has a minimum use of fully completed documents. Boehm warned that there is a possible risk that this situation may lead to architectural mistakes, which are hard to find and correct by any external party. 
\section[{c) Definition of Agile}]{c) Definition of Agile}\par
Agile cannot be given with a constant definition. Different practitioners have different wordings according to their experience and understanding. But agile can be explained in few characteristics that are considered as the core characteristics.\par
? Iterative and incremental process ? Simple and easily adoptable ? Collaboration of all the parties such as users, customers, developers, project managers, etc. ? Produce high quality software within the requirements, budgets and the time scale.\par
Following are different definitions from different expert practitioners.\par
"Agile is an iterative and incremental (evolutionary) approach to software development which is performed in a highly collaborative manner by selforganizing teams with 'just enough' ceremony that produces high quality software in a cost effective and timely manner which meets the changing needs of its stakeholders."  {\ref (Ambler, 2001)} "Agile is a conceptual framework generally centred on iterative and incremental delivery of working software, driven by the customer. The iterative part suggests that we are repeating, or iterating, a complete lifecycle of development over a short, fixed span of time. With each of these iterations, we ship some working subset, or increment, of features." \hyperref[b17]{(Langr, 2006)}  
\section[{d) SDLC for Agile}]{d) SDLC for Agile}\par
According to Ambler agile SDLC composed of four phases Iteration0, Development, Release and production.\par
Iteration 0:\par
1. Initial time of the agile project.\par
2. Modeling and initial architecture of the project. 3. Setting up the environment of the project. 
\section[{Development Phase:}]{Development Phase:}\par
Incrementally deliver high quality software which meets the changing needs of the use. 
\section[{Release Phase:}]{Release Phase:}\par
In this phase agile practitioners transition the system into production. 
\section[{Production Phase:}]{Production Phase:}\par
The fundamental goal of this phase is to keep the system running and help users to use the software. Year 2020 
\section[{( ) C}]{( ) C}\par
© 2020 Global Journals 
\section[{e) Agile Methodologies}]{e) Agile Methodologies}\par
Agile manifesto provides an ideological environment to modern so called "agile" software development with its defined values and principles. A survey conducted by Cutter Consortium with regard to the methods been used in the software development field revealed that 54\% of the users use their own inhouse development methods, which can be explained within the agile boundaries. Among the defined methodologies in agile the most popular methods were Extreme programming, Feature Driven Development and Adaptive Software Development. The purpose of this section is to introduce few of the widely used agile methodologies identifying the roles, process, responsibilities and practices. The following methods will be included for discussion: Extreme Programming (XP), Dynamic Systems Development Method (DSDM) and SCRUM.\par
i. Extreme Programming a. Outline Extreme programming (XP) evolved from the frustrations and the problems caused from traditional plan-driven methods, which were the only development solutions in the software industry for a long time \hyperref[b5]{(Beck, 1999)}. XP was developed and brought in to practice in the mid 1990's by Kent Beck, Ward Cunningham and Ron Jeffries \hyperref[b33]{(Paulk, 2001)} as a result of a project they been working. The main features which XP emphasizes are those that they identify as the prerequisite for effective software development which are improving communication, getting feedback, simplicity and proceeding with courage \hyperref[b21]{(Cockburn, 2001)}. Even though these practices started as just a better ways of development rather than traditional methods with time they showed success. This was the root for XP. XP has widely influence on the principles in the agile manifesto \hyperref[b35]{(Kalermo \& Rissanen, 2002)}.\par
There are different theories and arguments about XP whether it is actually a method and how extreme this methods is. \hyperref[b33]{Paulk (2001)} argues that these practices are actually just commonsense practices that any discipline method would have and not something extreme. \hyperref[b5]{Beck (1999)} who is one of the founders of XP states that XP is a fresh and new methodology and the term "Extreme" comes from taking these commonsense practices to extreme levels.\par
XP is based on the following five important values.\par
? Communication -"Problems with projects can invariably be traced back to somebody not talking to somebody else about something important." \hyperref[b4]{(Beck, 2000)}. XP focuses lot on face to face or oral communication and its techniques encourages in maximizing interaction. This is valued on the observation that most project difficulties occur because individuals or teams have not spoken with other parties to clarify questions, to collaborate, or to obtain help. ? Simplicity -Rather than try to capture all features and complicate, Design the project in the simplest way to meets the customer's needs. The value highly stresses on the point, only design and code the current requirements obtained rather than to anticipate and plan for unstated requirements. ? Feedback -The development team(s) obtain feedback from the customers at the end of each iteration and release. The next iteration drives with the consideration of this feedback. There are very short design and implementation feedback loops built into the methodology via pair programming and test-driven development \hyperref[b46]{(Williams, 2003}). ? Courage -The best thing about XP is that the other three values give the team to have courage in their actions and decision making. The team decides which parts will be done at which stages. Further, this encourages the team to avoid any pressure for unrealistic deadlines or requirements.   ? Exploration phase -Story cards are used by customers to express the features they want in the system. In each story card they have to write a feature they wish to have in the system. Mean while the technical teams focus on the tools and technologies they are going to use in the project. They get familiar with those tools as well. They test the technologies and the proposed architecture possibilities by building a prototype of the system. Depending on the project scope and the teams' familiarity with the technologies this phase spans from few weeks to few months. ? Planning phase -Considering all the stories, prioritize the features to be delivered in the first set of the release of the system. The development teams estimate the time required for different features and then agree upon the deliveries for the first release. The first release of the system can take up to two months and the planning phase may take few days. ? Iteration to release phase -The schedule set up for the first release is divided into small iterations before the actual first release. The first iteration builds system architecture for the whole system by selecting and analyzing the stories which includes the features. The customers decide which story to include in each of the iterations. Further the customers can create functional test for the system. These will be used to check the accuracy of the system and may use in the future. Iteration is around one to four weeks each for implement. Once the iterations are done the system is ready for production. ? Product ionized phase -This phase runs faster than the others, which means that the iterations can be reduced to one week instead of three weeks. The system has to be extra tested for performance before release to the customers. New changes found here has to be decided before start working on them. Postponed ideas will be documented to build later. ? Maintenance phase -After the product is product ionized and released for customer use, teams have to make sure that system in the production running and also produces new iterations. This phase need an effort for customer support tasks In order to maintain these operations. Thus, the maintenance phase may require new people into the team and also changes in the development structure. ? Death phase -The project comes to this phase when there are no more requirements from the customers. But there are other concerns such as reliability and performance before reaching this point. Since there are no more requirements to be added to the system all the documents been written at this stage. On the other hand when the project does meet the requirements and it is expensive for further development, it can reach death phase. 
\section[{c. Responsibilities and Roles of XP}]{c. Responsibilities and Roles of XP}\par
There are specific roles in XP for different tasks. This makes work much easier to handle as they are divided with clear roles. The following describes these roles according to \hyperref[b4]{Beck (2000)} and  {\ref Abrahamsson et al. (2002)}.\par
? Manager -Makes all the decisions and is responsible for the team and its issues. He or she has the right to form the team, obtain and allocate resources, manage people and problems. In order to do all above, he or she communicates with the team to understand the present situation. The manager interfaces with external groups as well including the customers. Selects stories for a release and for an iteration.\par
One individual from the customer organization or a group of customers can be involved in the sections, or a customer representative can be chosen from within the development organization that is external to the development team. 
\section[{d. Technical Practices}]{d. Technical Practices}\par
The initial version of XP had defined programmer-centric technical practices. This was published in 2000 by Beck.\par
? Planning game? Short releases ? Metaphor ? Simple design ? Testing ? Refactoring ? Pair programming ? Collective ownership ? Continues integration ? 40 hour week ? On-site customer ? Coding standards ? Open workspace ? Just rules\par
XP practices were changed to include 13 primary practices and 11 corollary practices in 2005 \hyperref[b6]{(Beck, 2005)}. The primary practices are intended to be useful independent of each other and the other practices used, though the interactions between the practices may amplify their effect  {\ref (Williams, 2007)}.\par
ii. SCRUM a. Outline "The relay race approach to product development may conflict with the goals of maximum speed and flexibility. Instead, a holistic or 'rugby' approach -where a team tries to go the distance as a unit, passing the ball back and forth -may better serve today's competitive requirements." \hyperref[b30]{(Takeuchi and Nonaka, 1986)} SCRUM is also a member from the agile development processes family. Scrum is a process skeleton that includes a set of practices and predefined roles. It provides you a set of guidelines to develop software from its design stage to its completion. Scrum is best suited for the projects with rapidly changing or highly emergent requirements. It is a Simple and scalable method which means easily combined with other methods and doesn't prescribe engineering practices. According to the article on scrum by \hyperref[b50]{Clifton and Dunlap (2003b)} there are few software development issues scrum addresses for a better software production.\par
? Chaos due to changing requirements -The real or perceived requirements of a project usually change drastically from the time the product is designed to when it is released. Under most product development methods, all design is done at the beginning of the project, and then no changes are allowed for or made when the requirements change. ? Unrealistic estimates of time, cost, and quality of the product -The project management and the developers tend to underestimate how much time and resources a project will take, and how much functionality can be produced within those constraints. In actuality, this usually cannot be accurately predicted at the beginning of the development cycle. ? Developers are forced to lie about how the project is progressing -When management underestimates the time and cost needed to reach a certain level of quality, the developers must either lie about how much progress has been made on the product, or face the indignation of the management. 
\section[{b. SCRUM Lifecycle}]{b. SCRUM Lifecycle}\par
Scrum has a process which has to be followed by any organization or team that adopt this methodology. As figure \hyperref[fig_2]{2} illustrates the projects Year 2020 
\section[{( ) C}]{( ) C}\par
© 2020 Global Journals development happens via a series of month-long iterations called Sprints. Scrum is ideally suited for projects with frequently changing or highly emergent requirements. The Product Backlog lists the work to be done on a Scrum project. It lists all desired changes to the product. A Sprint Planning Meeting is held at the start of each sprint during which the Product Owner prioritizes the Product Backlog and the Scrum Team selects the tasks they can complete during the coming Sprint. These tasks are then moved from the Product Backlog to the Sprint Backlog.  
\section[{c. Responsibilities and Roles of SCRUM}]{c. Responsibilities and Roles of SCRUM}\par
Scrum implements its iterative and incremental process through three roles. All management responsibilities are divided between these three roles \hyperref[b28]{(Schwaber, 2007)}.\par
? Product Owner -The product owner is responsible for the project, managing, controlling and creating and prioritizing the Product Backlog. He or she is selected from the other parties such as management, customers and the scrum master. The Dynamic Systems Development Method (DSDM) was first developed in the United Kingdom around the mid to late 1990s by a group of people from a business background. It was totally not related with technical perspective. This can be said as one of the heavier Agile approaches available \hyperref[b22]{(Coffin and Lane, 2007)}. It was initially developed as an addition to Rapid Application Development (RAD), incorporating best practices from the business-oriented environments.\par
DSDM is a well ordered, commonsensical process focused on delivering business solutions quickly and efficiently. It has similarities to SCRUM and XP in many ways, but it has its best uses where the time requirement is fixed (CliftonandDunlap, 2003a). DSDM focuses on delivery of the business solution, rather than just team activity. It ensures the feasibility and business sense of a project before it is created. The cooperation and collaboration between all interested parties is an important fact in DSDM. This method makes heavy use of prototyping to ensure all the involved parties have a clear picture of all aspects of the system.\par
Unlike in traditional development methodologies where functionality is fixed, and time and resources are variable, in DSDM, time is fixed, and functionality is variable (CliftonandDunlap, 2003a). The following figure best illustrates this scenario.  ? Ambassador -The person who acts as intermediate between the users and the development team. He manages the development team, and usually has a good overall understanding of how the system will work.\par
? Visionary -This role is the driving force behind the project. This role keeps the project steered on course towards the business goals. Often is the person who started/thought of the project. ? Advisers -People who have practical knowledge in areas of the business that need to be automated, and/or in the technologies needed to automate these areas. 
\section[{d. Technical Practices}]{d. Technical Practices}\par
There are nine principles at the core of the DSDM methodology. Some clearly overlap with XP and similar approaches. However, DSDM's principles are sufficiently robust to minimize damage to schedules and resources when a business process radically changes or a major component's design is faulty-problems that could cripple an XP project \hyperref[b27]{(Robinson, 2002}).\par
? Active user involvement is a must.\par
? Design groups are empowered to make system development decisions. ? Frequent and regular delivery of components is a priority. ? The primary acceptance criterion for a system or component is its fitness for business purposes-the design driver is business benefit. ? The business solution is the goal, and iterative and incremental development is necessary to converge on that solution.  © 2020 Global Journals methods used in the engineering world in the software development world."  {\ref (Georgiadou, 2001)}.\par
Traditional software development methodologies are the first methods of software development. They are also known as heavyweight methodologies. They are considered to be the classic way of developing software. These methodologies are mostly based on a series of sequential steps, such as requirements definition, solution building, testing and deployment.\par
Traditional software development methodologies require defining and documenting a stable set of requirements at the beginning of a project.\par
ii. Waterfall Model a. Outline The Waterfall model is known as the classic model of software development. The Waterfall model also known as the "top down" approach, was proposed by  {\ref Royce (1970)}. Until the mid 80's it was the only model with a level of general acceptance. It was derived from models used in traditional engineering activities with the objective of establishing an order in the development of large software products. It is more rigid and less manageable compared with other software development models.\par
The Waterfall Model is one of the most important models ever published. It is a reference to others, and serves as the basis for many modern projects as well. Its original version was improved over time and is still frequently used today \hyperref[b44]{(Peters and Pedrycz, 2000)}. A great part of the success of the Waterfall Model is due to the baseline management, which identifies a fixed group of documents produced as a result of each phase of the life cycle \hyperref[b44]{(Peters and Pedrycz, 2000)}. The produced documentation includes more than text files, it has graphical representations of the software and even simulations. 
\section[{b. Waterfall Model Life Cycle}]{b. Waterfall Model Life Cycle}\par
Waterfall model phases are executed systematically in a sequential order. The model usually has the following phases: Analysis, Design, Implementation, Testing, Deployment and Maintenance. Requirement gathering and Analysis -This is the phase where all the requirements to be developed are captured. This is done by conducting consultations, interviews, observation and so on. A document called requirement specification is created including all the gathered requirements at the end of this phase \hyperref[b42]{(Parekh, 2005a)}.\par
System design -Looks at the overall system in a design and architectural level before starting actual coding. This is to get an idea how the system look like at the end of the project. All hardware, software and resource requirements are considered here and finally create the system design specification to start the next phase. Year 2020( ) C © 2020 Global Journals\par
Implementation and unit testing -The actual coding begins in this phase. According to the system design spec system is built in small units. Each of these units are tested to ensure that it servers the purpose that unit is built \hyperref[b42]{(Parekh, 2005a)}.\par
Integration and system testing -In the previous phase the system is built in units. This phase focuses on getting these units together. The system is build by putting the units together. Units are tested with each other to ensure that they work and communicate with each other and give the final outputs which are expected from the whole system \hyperref[b42]{(Parekh, 2005a)}.\par
Operations and maintenance -This phase is normally considered the longest of all. Issues and errors of the system which were not found during the development stages come alive once the system starts to operate in a live environment. This will normally happen time to time. So this phase is called maintenance \hyperref[b42]{(Parekh, 2005a)}.\par
iii. Spiral Model a. Outline The spiral model was introduced by Barry Boehm in 1980s, based on experience with various refinements of the waterfall model as applied to large software projects. This method combines elements of both design and prototyping-in-stages, in an effort to combine advantages of top-down and bottom-up concepts \hyperref[b8]{(Boehm, 1988)}. There are four main phases of the spiral model \hyperref[b8]{(Boehm, 1988}):\par
? Objective setting -Specific objectives for the project phase are identified. ? Risk assessment and reduction -Key risks are identified, analyzed and to reduce these risks information is obtained. ? Development and Validation -For the next phase of development an appropriate model is chosen. ? Planning -For the next round of spiral the project is reviewed and plans are drawn up. 
\section[{b. Spiral Model Lifecycle}]{b. Spiral Model Lifecycle}\par
As shown in figure \hyperref[fig_9]{6} there are four main phases in spiral model. They are Planning, Evaluation, Risk Analysis and Engineering. These phases follow one after another in an iterative manner. The objective is to eliminate the problems occurred in the waterfall model. In an article by \hyperref[b43]{Parekh (2005b)} mentions that even though the iterative approach became a solution to waterfall model issues, spiral model requires people with high skills in the area of planning, evaluation, risk and customer relations. The project becomes more costly than planned due to the demand for more than one iteration cycle. Following describes the main phase in spiral model. Year 2020  Plan phase -This phase gather and finalize the objectives and constraints of the project and documented. These are kept locked in order to decide on the approaches and strategies of the project. Risk analysis -This is considered as the most important phase of the model. All the approaches and strategies are analyzed for risk factors. Prototyping is used to find solutions and to develop a low cost and quality system if there are any indications of risk. Engineering -This is the development phase. Development outputs are carried through all the phases iteratively for improvements. Customer evaluation -The built product is passed on to the customer in order to receive feedback. This phase is expected to come across possible errors and/ or changes. This is similar to system testing. iv. Unified Process a. Outline Unified process is actually not a process rather it can be called as an extensible process which can be customized according to the nature of different projects or organisations. Every approach such as modeling is organized into workflows in the Unified Process (UP). UP is performed in an iterative and incremental manner and some of the key features of the UP are described below \hyperref[b7]{(Booch, 1994}):\par
? UP consists with an architecture based on components which creates a system that is easily extensible, supports software reuse and intuitively understandable. The component commonly being used to coordinate object oriented programming projects. ? It uses modeling software such as UML to represent its code graphically as a diagrammatic notation to allow less technically capable individuals, but with a better understanding of the problem to come up with a greater input. ? The use of use-cases and scenarios to manage requirements seems to be very effective at both capturing functional requirements and help in keeping sight of the anticipated behaviors of the system. ? Since the design is done in an iterative and incremental manner it helps reduce project risk profile. Further it allows greater customer feedback and help developers stay focused. Year 2020 
\section[{( ) C}]{( ) C}\par
© 2020 Global Journals\par
? Verifying software quality is very important in a software project. UP assists in planning quality control and assessment built into the entire process involving all member of the team.\par
b. UP Lifecycle The above diagram indicates the four phases in UP lifecycle. These four phases are described below (devdaily).\par
? Inception -This phase creates a business case at the end of the process. The feasibility of the system is measured and the scope of the system is defined. ? Elaboration -The basic architecture of the system have been produced and a construction plan is agreed. Furthermore a risk analysis takes place and major risks are addressed. ? Construction -The system is produced and released for testing. This is not a full functioning system. A working system should be available and sufficient enough for testing under realistic conditions. ? Transition -The system is finally up to the standard to go in a live environment. So it is introduced to the stakeholders and intended users. Once the customers and the project team agreed that the intended target is met and the user is satisfied the system is completed.\par
There are approximately 50 work steps that has to be completed in UP during the process \hyperref[b15]{(Larman, 2004)}. All this documentation and this rigid approach add a lot of complexity to UP. UP has predefined roles to the project team making it less flexible in working. 
\section[{g) Comparison of Agile and Traditional Methods.}]{g) Comparison of Agile and Traditional Methods.}\par
In the previous section some discussions were there on both agile and traditional methods to identify the characteristics of these methods. It is important to do a comparison on these two methods in order to understand the differences that will affect different projects. Year 2020 
\section[{( ) C}]{( ) C}\par
© 2020 Global Journals It is mentioned in the early sections that traditional methodologies were ruling the software industry for a long time until practitioners begin to understand some of the drawbacks largely affecting the software projects. Extreme programming became popular in the industry when it was introduced in late 90's by Kent Beck. Then agile was introduced based on the concepts used in XP. Agile handle projects mostly in a volatile and uncertain environments. But with the passage of time practitioners came to realize that agile cannot handle all types of software projects as it has some limitations as well. Both of these methodologies have their strengths and weakness. Now the organizations tend to use the strengths of both together in their projects. There are three main factors which need to be considered when selecting a methodology. They are people, project size and risk. 
\section[{i. People}]{i. People}\par
This is one of the main important factors considered in software development. Especially agile methodologies strongly believe in human factor. Bohem and Turner (2003) believe that "In essence, software engineering is done 'of the people, by the people, and for the people.'" The agile manifesto stresses about the importance of the human interactions and customer collaboration in their basic values of agile methodologies (Fowler and \hyperref[b1]{Highsmith, 2001)}.\par
Developers and customers are the most important categories in people needed for software development. When using agile methodologies the people factors for developers were identified as skill, talent, communication and amicability (Bohem and Turner, 2003). Agile unlike traditional methodologies encourage working closely with the customers. This is important for a successful development environment.\par
The organization's culture has an impact on the people factor. If the developers are under the tight rules of the organization, it is hard to adopt agile since the developers will not get the maximum out of agile methodologies. 
\section[{ii. Project Size}]{ii. Project Size}\par
Project size of software is another major factor and considered as a challenging factor. In the early stages of project size estimation it was measured by predicting the number of lines of code the project may need \hyperref[b16]{(Dekkers, 2005)}. This is one of the limitations agile is facing today. For most of the large scale projects which involve more than 50 software developers agile seems to be working in a negative manner. This was shown in a study conducted by ambler (2008). \hyperref[b20]{Cockburn (2008)}   iii. Software Risk Software project risk may result in lots of problems. Budget and plan overruns and unable to meet the expectations of the uses and many more \hyperref[b26]{(Renhui and Fengyong, 2007)}. There are few categories of risk according to \hyperref[b26]{Renhui and Fengyong (2007)}, and there are;? Team risk ? Environmental risk of organization ? Demand risk ? Plan and control risk ? User risk ? Complexity risk\par
An organization should be careful when handling these risks. Traditional methodologies are used for large critical systems with security and reliability such as military systems. However, for the systems that can be made quickly and have lots of uncertainty, Agile is the most appropriate methodology. For example a system expected lots of change of requirement during the development phase through customer involvement agile is the best methodology as it can respond to changes faster. 
\section[{III.}]{III.} 
\section[{Research Methods}]{Research Methods} 
\section[{a) Introduction}]{a) Introduction}\par
This chapter discuss about the methodology used by the researcher to present a research into the statement of aim. The main purpose of this section is to evidently define the specific guidelines which will make possible the researcher to substantiate the achieved hypothesis. In brief, this section discusses about the ideas, which are used in the course of primary and secondary. 
\section[{b) Research Philosophy}]{b) Research Philosophy}\par
Research philosophy depends on the way a researcher thinks about his/ her development of knowledge \hyperref[b51]{(Saunders et. al., 2003)}. The major research philosophy theories are Positive, Phenomenology and Realism \hyperref[b52]{(Maylor \& Blackmon, 2005)}.\par
Positive or scientific method affirms that there is just one truth about the world. It is understood that such truth is objective and does not entail any value judgments. Finding this truth requires a process based on a deductive method for which data must be collected. In this sense positivist researchers stand that the data is not affected by the researcher opinion and that the more objective the data collection the better.  {\ref (McNeill, 1985)} Usually the data is collected, interpreted and analyzed following the quantitative method and according to a statistical approach. Data collection might be achieved through surveys. The survey aim is to test the original hypothesis and therefore, to establish the truth of a specific phenomenon. The relevance of this kind of approach resides in its objectivity, since the results obtained are independent of the subjectivity of those involved in that process.  {\ref ( McNeill, 1985)} Phenomenology (ethno methodology), has as main principle that there is not a unique truth. According, the explanation of a phenomenon emerges Year 2020 
\section[{( ) C}]{( ) C}\par
© 2020 Global Journals from different points of view people affected and involved have in relation to the phenomena analyzed. This is an action-reaction process. Every single person has his own interpretation of the world and phenomenon. In this sense, there are different truths and realities, and sharing meanings and interpretations vary depending on the context.  {\ref (McNeill, 1985)} Realism shares some philosophical views with positivism, since it is based on the impression that there is an intention reality, which is self-governing of human beings' thoughts and beliefs. However, realism also recognizes that humans are not substance to be considered in the style of natural science. On the other hand it takes social influences into account. Realism recognizes the importance of the fact that those social influences, although are independent of individuals, affect the way people make sense of their world, whether they are conscious of these forces or not. \hyperref[b51]{(Saunders et. al., 2003)} The comparison between the characteristics of each research philosophy is summarized in the following Table \hyperref[tab_7]{3}. In this research, researcher uses realism philosophy because it helps to find out the research questions more efficiently. 
\section[{c) Research Design}]{c) Research Design}\par
According to Kerlinger (1994) "A research design is the plan, strategy and structure of exploration conceived so as to achieve answers to research questions and to control variance."\par
Sekaran (1992) states, research has been defined as:\par
"An organized, data based critical, systematic, scientific enquiry and exploration into a particular difficulty, undertaken with the intention of finding answers or solutions to it."\par
According to \hyperref[b51]{Saunders et. al.(2003)}, there are three different types of research design, which are; 1) Exploratory 2) Descriptive 3) Explanatory.\par
The concept of each is discussed below. 
\section[{i. Exploratory}]{i. Exploratory}\par
Exploratory research is a kind of investigate conducted because a problem has not been evidently defined. Exploratory research helps decide the best research design, data collection process and variety of subjects. Investigative research relies on Secondary research. Though, research that is conducted with a desire to discover are called an exploratory research. 
\section[{ii. Descriptive}]{ii. Descriptive}\par
Descriptive analysis describes data and characteristics about the society or phenomenon being studied. If the function of the study is to describe, the study is measured to be descriptive in character. It mainly gives the researcher a choice of aspects, perspective, levels, terms and concepts, as well as to observe, register, systemize, classify and interpret. 
\section[{iii. Explanatory}]{iii. Explanatory}\par
Explanatory research is useful when the issue is previously known and has a explanation of it. The ambition to know "why" to provide details is the point of explanatory research. It builds on descriptive and exploratory research and goes on to identify the cause for something that occurs. Explanatory research looks for reasons and causes.\par
The different between exploratory, descriptive and explanatory research design In this research, the researcher has explored "Marketing strategy in fast food restaurant" in particular through his own literature view. The researcher has tried to explore the relationship between the impacts of marketing strategy in fast food restaurants and consumer intentions of coming back to the restaurant. On the beginning of this correlation the researcher has been capable to explore the various features of the marketing strategy. Consequently, the researcher has coined his research as an exploratory research. 
\section[{d) Data collection Method}]{d) Data collection Method}\par
Data collection method is an important stage of a research and must be well planned to ensure that researchers will not face the problem of being overwhelmed by the data, which become a barrier rather than an aid to the research project. In order to be able to plan and organize data collection systematically, an understanding of the various types of data depending on different approaches to, methods of, and techniques of data collection is significantly required.\par
According to \hyperref[b51]{Saunders et. al. (2003)}, data comes in various shapes and forms, but can be distinguished between two main categories: 1. Secondary data, and 2. Primary data.\par
i. Secondary Data Secondary data is data which has been composed by agencies or individuals for purposes other than those of our meticulous research study. For example, if a management has carried out a review of, say, expenditures of family food, and then a food producer might apply this information in the organization's assessments of the whole probable market for a fresh product. Similarly, statistics arranged by a ministry on agricultural production will demonstrate useful to whole lots of people and organizations, including those marketing agricultural supplies.\par
The most frequent exercise of secondary data in marketing research is to achieve familiarity and to create a background in which primary data are composed, reported and analyzed, the problem is defined, and the research is planned. This approach is a literature search -an assessment of exiting material, penetrating for information pertinent to the present marketing research project. Materials are typically scholarly magazines, journals, books, newspapers, and company records (accessed through computer data bases).  {\ref (Patzer L. Gordon, 1995)} Secondary data can give information about performance and procedures for conducting marketing research. For example, these data can help learn language for communication with the research sample members, questions and topics to avoid, problems likely to be encountered, and statistical techniques to engage.  {\ref (Patzer L. Gordon, 1995)} Secondary data are potentially misleading term for people not experienced with marketing research. For example, it is misleading to think of secondary data as being of second importance, minor importance, inferior value, or in any way not necessary. Their worth, like that of all data, depends instead on the marketing research project. However, it is reasonable to conclude that secondary data play a significant role in almost all marketing research projects. Another misconception is to think of secondary data as coming second in a sequence. The sequential order is just the opposite: secondary data typically are collected and analyzed first, before primary data.  {\ref (Patzer L. Gordon, 1995)} ii. Secondary data sources Book reviews: The external research will be carried out through the reading and understanding of published material. This includes books and articles written on online shopping, catalogue shopping and consumer perception and satisfaction. Book and journal reviews are a very good source of collecting data as can get a wide variety of theories and authors references.\par
Internet Research: Internet research is another source of secondary data. This will be used to gather historical and present information about online shopping, catalogue shopping and consumer perception and satisfaction. This will also help to get contact details about the bottom level consumer as a whole. Helps to gather and analyses articles and journals about catalogue shopping and consumer perception and satisfaction. Collecting data from internet search is widely used now a days and is very quick and also you can get a wide variety of data through internet search.\par
Documents: Documents can be treated as a source of data in their own rights. In effect it can be an alternative to questionnaires, interviews or observation. This includes published materials of company details, like annual and financial reports of the proposed banks as well as other banks. 
\section[{iii. Primary Data}]{iii. Primary Data}\par
Primary data means the data that are to be collected by the researchers themselves through a variety of data collection methods and techniques, for example, interviews, questionnaires, experiments, observations etc. Although the process of collecting primary data may have more requirements than secondary data in terms of time , effort and resources, the result is likely more relevant for answering the research question.\par
Regarding collecting data primarily, we can distinguish the type of data collected into two subcategories; 1.quantitative data and 2. Qualitative data 
\section[{Quantitative Data}]{Quantitative Data}\par
Quantitative data means data which is number based or can expressed numerically as well as classified by some numerical value. In contrast, qualitative data means data which is in the form of Year 2020 Quantitative data is more objective and scientific than qualitative data. It involves the implication that what is being researched can be quantified, and, therefore, is only applicable to incidence that can be quantified and measured. 
\section[{Qualitative Data}]{Qualitative Data}\par
Qualitative data explained items in terms of some feature or category that possibly informal or may use comparatively imprecise characteristics such as benevolence and flavor. However, qualitative data can contain well-defined aspects such as gender, nationality or object type.\par
Qualitative Analysis conducted through the use of conceptualization iv. Primary Data Sources Interviews: Direct Interview is one of the major sources of primary data today. This method is would be used for the internal research. The internal research will focus on a few semis structured interviews with a few senior and top managers. The intention is to ascertain a true picture of the perceptions and satisfactions that a consumer feels when they eat in a fast food restaurant. These interviews will help to find out the secrets of their success or reasons for failure.\par
Interviews are a good source of collecting data. Also it is relatively cheap and quick to collect data through conducting interviews. But also there are some disadvantages in conducting an interview: -1. As the nature of topic suggests it will be highly impossible to contact top level officials of the company and to ask them to give information about their company. 2. The second disadvantage is that the nature of the topic is so complex that there is a chance of getting biased opinion and it will be highly risky to rely on these answers.\par
Questionnaires: Another methodology that is the questionnaires. In this research, researcher uses seventeen relevant questions to find out the findings of this research which are given in APPENDIX 1.\par
Questionnaires are more economical, easier to arrange, the answers will be standardized. In situations of difficulty to get appointments with the top-level managers this method would be used to. Postal questionnaires will be sendingto top managers of the banks and the responses can be analyses.\par
Collecting data from questionnaires is often for getting information and also it is relatively cheap. But it also has got some disadvantages like: -1. Collecting data from questionnaires is a long procedure and takes long time to collect and analyze such data. 2. The second disadvantage is that people generally don't like to spend time in giving answers in writing. 
\section[{e) Data Analysis}]{e) Data Analysis}\par
After the data have been composed, the researcher turns to the responsibility of analyzing them. Analysis of this data needs a number of closely connected operations such as creation of category, the importance of these categories to unprocessed data through tabulation, coding and then sketch arithmetical inferences. Scrutiny work after tabulation is mainly based on the calculation of various coefficients, percentages, etc. in brief the researcher can analyse the collected data with the assist of various numerical equipment. 
\section[{f) Reliability}]{f) Reliability}\par
According to Joppe  {\ref (2000)} "The extent to which results are consistent over time and an accurate representation of the total population under study is referred to as reliability and if the results of a study can be reproduced under a similar Year 2020 
\section[{( ) C}]{( ) C}\par
© 2020 Global Journals methodology, then the research instrument is considered to be reliable."\par
In this study, the researcher used the method of qualitative research in order to explore and understand the implementation of marketing strategies in the fast food restaurants, so that the researcher was then able to compare and contrast the findings with the literature, and eventually, was able to give suggestions about the issue. The case to be explored is dynamic and complex, and, therefore, it cannot be ensured that the research can be replicated and will give the consistent result when the time and circumstances have changed. 
\section[{g) Validity}]{g) Validity}\par
According to Winter (2000) "The traditional criteria for validity find their roots in a positivist tradition, and to an extent, positivism has been defined by a systematic theory of validity. Within the positivist terminology, validity resided amongst, and was the result and culmination of other empirical conceptions: universal laws, evidence, objectivity, truth, actuality, deduction, reason, fact and mathematical data to name just a few."\par
Researcher built the validity by establishing correct operational measures for the concepts of study. Researcher used the structured questionnaire as the mean to obtain the data.\par
The questions were designed and pre-tested in order to minimize as much as possible the misunderstanding and problems for the respondents; meanwhile it also increased the internal validity and reliability of the data. 
\section[{h) Limitations of the research project}]{h) Limitations of the research project}\par
Researcher found some limitation at the time o research work. These are: a) Extent of research will provide a general overview of the entire outsourcing operations rather than complete audit. b) Limited amount of time available for completing the study. c) May not be possible to conduct interview with all of the firm's clients. d) Some of the data gathered may not be totally relevant to the research topic. e) Research needs to be conducted on a very low budget. f) There could also be a problem with translating the questionnaires and interviews as the company is located in a region where English not the main language in use. So there are chances that some data corruption might occur. 
\section[{i) Methods for this Research}]{i) Methods for this Research}\par
The chapter describes the methodologies used in the research. The project used both qualitative and quantitative methods. Using the following methods, a detailed study of the software development methodologies were carried out. The research is in two sections. Primary research carried out with a questionnaire. It consists of a survey. The Secondary research comprises of Literature survey from various sources. 
\section[{i. Completing the Questionnaire}]{i. Completing the Questionnaire}\par
The questionnaire has been created in a way so that responders can answer quickly and easily. It is divided in to three main sections and contains all closeended questions. The time taken to complete the questionnaire was approximately 15 minutes to 17 minutes.\par
Individual and organizational questions -This section contains questions on respondent's position in the industry as well as the position of the organization. It also contains question on the size of the organization including the number of employees, the projects they adopt and the likeness of adopting new technologies.\par
Methodology knowledge questions -This section focused on the knowledge of the respondent on the methodologies Software development questions -This section contains questions on the different agile and traditional methodologies used on different projects. This is scaled on the project sizes measured in person months. The scales are selected as small scale, medium scale and large scale projects. There are questions to capture the opinion of the respondents on how effective the used methodologies were with regard to cost and quality of the software. Finally questions were included to capture their opinion on the preferred characteristics of both development methodologies from their point of view. The questionnaire is included in Appendix 1. 
\section[{ii. Target Audience}]{ii. Target Audience}\par
The questions were distributed among software companies of various sizes and types. The respondents involved were mainly software architects, software engineers, and project managers. However, there were some other roles involved in software development as well. 
\section[{j) Research Audit}]{j) Research Audit}\par
Different resources were used for the research. The resources include various books on software engineering and development methodologies from different authors including Cockburn, journals related with software industry, white papers on agile and traditional methods, and websites from the internet which are related with the subject area.\par
IV. 
\section[{Research}]{Research}\par
The following are based on the data that were collected from various companies in the software industry. A questionnaire was prepared and provided in order to collect these data. 
\section[{a) Data Collection}]{a) Data Collection}\par
Most of the respondent was from Bangladeshi 21 different organizations. Among the organization 15 organizations were Information technology related organizations, 3 organizations were from Year 2020 ( ) C\par
© 2020 Global Journals\par
Telecommunication, 2 organizations were from the Engineering and 1 was other organization. 
\section[{i. Organizational Characteristics}]{i. Organizational Characteristics}\par
When analyze the results from the sample question it was discovered that about 70\% of the respondents were from organizations with an Information Technology background. There were other respondents from telecommunication, engineering and medical organizations as well. There were some cases that projects were outsourced to information technology organizations. It is shown in the table below in a ratio of 100  ii. Individual Knowledge Gathering from Different Organization Among the organization the number of the respondent was 21 and majority of the respondents to the questionnaire were software developers. The other respondent were System Analysts, software engineer and software architects. It is shown in table below in a ratio of 100.   When it comes to the knowledge rating for different methodologies more than 90\% of the respondents have an understanding about agile and traditional methodologies in an average or higher level. 12 out of the 15 respondents have rated their knowledge of agile methodologies as average or broader, out of that 6 of the respondents rated their knowledge as broad or very broad. For traditional methodologies the rating was broad or very broad for 12 respondents. When compare the experience they have in the software industry it was revealed that with less experience in the field or in other words people who have experience less than four years have less practical knowledge in traditional methodologies. Figure \hyperref[fig_16]{12} presents the results below.  According to a survey results published by Ambler in early 2006 he has found that even though more than 60\% were fully or partially using agile, there is a considerably a large number of organizations who are still have no idea of adopting agile. In that survey result shown below In this survey about 75 \% of the respondents are either leader or follower to adopt agile methodologies, on the other hand in Ambler survey 65\% of the respondent said yes for adopting agile methodology.\par
So with the result of this survey, it proves that other than the organizations who adopted agile at the beginning, the potential of organizations adopting agile at a later stage without any assurance is minimal. A possible reason could be that these organizations are just waiting to see how agile projects will result in the future. 
\section[{b) Methodologies used in Organizations}]{b) Methodologies used in Organizations}\par
In this section focus on which type of agile and traditional methodology used on different organizations. If the organization is small which types of agile and traditional development methodologies they are using. In similar way it is focused for the medium and large scale organizations. 
\section[{i. Use of Agile Methodologies}]{i. Use of Agile Methodologies}\par
According to the respondents of the different types of organization indicate that Extreme programming (XP) is the most popular method used in the industry. But SCRUM also maintains a good position within the industry even though it is not up to XP level. There was a remark about XP stating that it sometimes gives bit of a fear because of the steps it includes and also the "Name itself". There is an interesting point that was found during the analysis. The next most popular was in-house build methods by organizations for their own use. In an article published by \hyperref[b29]{Sliwa (2002)} mentions that agile methods can be mixed for different organizations purposes. The article further stated that; "Schwaber, a Scrum co-creator, said it makes sense to combine Scrum and XP because Scrum focuses on management practices and XP centers on engineering practices for building object-oriented software."\par
The result proves this point as organizations are already using combined methods according to their needs for a better result. Another point was that some organizations tend to mix other new techniques built for specific tasks in software development with their development methodology. For example they use scheduling techniques such as planning porker for estimating time for development tasks. Planning poker is a technique which is used in Scrum in most cases to estimate time for development tasks. It has a deck of cards with different estimates which the developers can use \hyperref[b23]{(Cohn, 2005)} cited by planningpoker). Figure \hyperref[fig_18]{14} represent the results of respondent.  In figure \hyperref[fig_20]{15} it is indicate that for small, medium and large scale organizations Extreme programming (XP) is most popular among the agile methodologies and SCRUM is in second position. Other methodologies are using in a very small scale in different organizations. 
\section[{ii. Use of Traditional Software development Methodologies}]{ii. Use of Traditional Software development Methodologies}\par
According to the respondents of the questionnaire, for traditional methodologies more than 50\% respondents use the waterfall model, 23\% of respondents were interested in unified process and the rest was on in-house build methods for different type and sized projects. Figure \hyperref[fig_21]{16} represent the results.  
\section[{Analysis}]{Analysis}\par
In this chapter the discussion will be focused on analyzing these collected data and find out the responses from the software industry professionals. When consider the small scale software projects more than 30\% of the respondents think that working software is more important. People interactions and responding to change come after respectively. All the respondents' believe that human interaction is an important fact for better software development regardless of the project size. \hyperref[b21]{Cockburn (2001)} point out that; 
\section[{a) Most Appealing Agile Values over Traditional Characteristics}]{a) Most Appealing Agile Values over Traditional Characteristics}\par
"Core to agile software development is the use of light-but sufficient rules of project behaviour and the use of human and communication-oriented rules" proving the point made out from the survey results.\par
Respondents' have a different view about Medium and large projects. For both of these project types, customer collaboration have obtain the highest votes. This means that when the system is getting bigger more customer collaboration helps to keep the development on the track. Medium projects have a higher percentage of votes for people interaction than large projects. Even though this is outside the expected result for large projects, it may be due to the reasons that respondents think it is hard to communicate within large projects. Figure \hyperref[fig_22]{17represents} the results obtained. 
\section[{b) Factors that Influence to use Agile Methods over Traditional Methods}]{b) Factors that Influence to use Agile Methods over Traditional Methods}\par
Cost and quality of software products are the main concerns in the industry when it comes to software engineering. It is important for both software organization as well as the customers \hyperref[b40]{(Krasner, 1998)}.\par
Due to this in the questionnaire, it was necessary to include questions regarding the cost and software quality. The reason was to find out how agile methodologies have affected on these two features of a software project compared with traditional methodologies.\par
The questions were targeted to capture the opinions of the respondents, whether they believe by adopting agile methodologies will affect the software cost and quality of a project than the traditional methodologies. Since agile is making a huge entrance to software industry I was expecting a very higher positive feedback. Even though the result was rather different from what I was expecting.\par
When it comes to cost of the software project 50\% of the respondents agreed that there were no change in cost at all by using agile methodologies but according to Ambler (2007) it was 47 \% (in Figure \hyperref[fig_25]{19}). Surprisingly 22\% of the respondents have voted as the affect of the cost has slightly decreased than the traditional methodologies but according to  {\ref Ambler (2007)}. Only about 18\% of the respondents believe that agile methodologies have made a slight increase affect on cost. The rest of the respondents falls both sides to the far end of the ratings.  But with regard to software quality the result I obtain was different than the cost. Overly respondents have a positive feedback on the quality. More than 30\% of the respondents believe that adopting agile methodologies have slightly increased the affect on quality compared with traditional methodologies. 13\% of the votes were even higher. They believed that the affect was in a very higher state. But again there were huge number respondents who really did not believe in agile methodologies as 39\% was on the no change state. The rest was in the low side of the rating.\par
Figure \hyperref[fig_24]{18} and figure \hyperref[fig_25]{19} show the results for the software cost and quality I discovered. So comparatively organizations believe that there is a higher effect to quality from agile than the effect to cost. In the survey done by Ambler in early 2008 the results on quality was noticeably different. In his survey 67\% of the votes said that they experienced better or significantly better affect on the quality of software projects with the adaptation of agile methodologies. The difference to my results is that considerably a large number of respondents voted for no change. Since the results I got mentioned about medium size projects than other two there can be issues occur when practicing agile values such as team communication and customer feedback. Due to these reasons there may be problems when try to capture the quality of the project. The cost affect was slightly tally with the results from the Ambler's survey. Figure \hyperref[fig_24]{18} and figure \hyperref[fig_25]{19} show the results for the software cost and quality I discovered.  This two survey result on software cost are closely similar and their correlation coefficient is 0.991039.\par
ii. Comparison of software quality from agile methodologies between Ambler and this survey This two survey result on software quality are closely similar and their correlation coefficient is 0.87579. 
\section[{c) Preferences for Agile and Traditional Methodologies}]{c) Preferences for Agile and Traditional Methodologies}\par
When an organization uses a methodology, there are processes and techniques they have to follow regardless of the type of the methodology. From the past experiences in the industry I had the understanding that there were some processes which development teams think is useless for the success of the project objectives. To have a broader view in these aspects questions were included in the questionnaire to find out respondents opinion on certain characteristics in both methodologies.\par
According to the results shown in figure 22 more than 50\% of the respondents' believe that low management control is a drawback for small scale and medium scale projects. In fact they believed that low management affects all sizes of projects in a considerable amount. The other major aspect was the project structure. Again all the respondents' believed   "Documentation should be assigned a cost and its extent be determined by the customer.\par
Many organizations demand more than is needed. The goal should be to communicate effectively and documentation should be the last option." 
\section[{d) Methodology preferred}]{d) Methodology preferred}\par
When analyzing data to find out which development methodology is preferred by the respondents I have realized that agile has come a long way during the past few years after it was properly published. But on the other hand it still has to go further to take over the whole software market. 
\section[{i. Methodology selection for different project sizes}]{i. Methodology selection for different project sizes}\par
The results discover that almost all the respondents have agreed that agile methodologies are the best for small scale projects. This means that software organizations getting to know how to get their hands on agile methodologies to manage the tasks in small scale project environments. For medium scale projects both methodologies were voted. The gap between the results for the two methodologies was very less. This shows that agile is adopted by organizations than before for medium scale projects. But respondents had a different idea about large scale projects. Nearly © 2020 Global 90\% of the responds were bias to traditional methodologies. Only the remaining was for the agile and other methodologies.\par
The interesting fact was that organizations are using a mix of both methodologies when it comes to medium and large scale projects. Medium size projects are in this process more than the large size projects but it seems within the next few years large scale projects may also start to use a mix of both methodologies. Figure \hyperref[fig_32]{24} below represents the methodology selection. The other fact was that some organizations mix other techniques also into their methodologies. Some respondents have rated for Scrum or Scrums and also planning poker which are new techniques to make the development processes more efficient. Figure \hyperref[fig_33]{25} represents the total results.  
\section[{Use of agile methodologies}]{Use of agile methodologies}\par
Around 40\% to 50\% of the respondents' agree that for medium and large scale projects autocratic management is not necessary. This type of a management would keep the teams stick to the standard work and have no agility leaving the teams work without any innovation or creativity. Only for small scale projects some organizations use 100\% of the agile methodologies. Other than that for both small and medium scale projects majority of the respondents' agree only up to 50\% of agile methodologies are used. There was a comment from a respondent saying that "It is hard to stick to agile methods especially when it comes to large projects. There are other techniques been used mixing with the practices in both agile and traditional methods?" This means that organizations are tend to use their own in house methodologies created to suits the projects they handle.\par
The findings of this project research study also confirm the appropriateness of the use of agile methodologies for small scale projects, traditional and agile methodologies for medium scale projects and traditional methodologies for large scale projects of an organization. 
\section[{VI.}]{VI.} 
\section[{Conclusion}]{Conclusion}\par
The purpose of this research is to present a set of guide lines for a software organization to help choose the most appropriate development methodology according to most of the software projects they have in hand. The thesis starts with an overview of the software industry and explanation of the problem domain which is focused in the research. Through traditional and agile development methodologies, this discusses the different software development approaches used in the software industry. Further a discussion about the life cycles of selected approaches from both traditional and agile methodologies were carried out with identifying the roles, responsibilities and practices of each development approach. This would give the reader clear idea about the two methodologies and also the differences they have. Chapter 2 briefly presents a comparison on the methodologies and focuses on the problems in both methodologies. Finally, in order to get the professional opinions, the document presents the analyzed results from the survey conducted.\par
Throughout the research it was understood that the traditional methodologies were apparently handling a considerable portion in software industry. The basis was the complete planning, heavy documentation and extensive designs. Traditional approaches will still be useful in large, long lived projects that require special safety, reliability or security requirements. The military and defense industry gives a perfect example to prove this point. \hyperref[b41]{Lijek (2007)} in a presentation discusses the reasons why agile methodologies are not adopted in the military and defense industry.\par
? Defense Contractor Mentality regarding change ? Safety Critical Systems ? Long development cycles ? Large teams ? Customer Relations But in the near future with the improvements agile will be able to be adopted in these industries.\par
Agile methodologies cannot be defined by a small set of rules and practices. From the literature review and the survey results it became obvious that agile methods have the capability to respond to change faster, the ability to extract the hidden creativity and innovations out of the teams, the capability in balancing the structure and flexibility and to drive the organization through rough situations and uncertainty. Agile is more likely to dominate volatile environments with uncertainty and unpredictability where the exact customer needs are not clear. Organizations tend to respond to the market changes quickly with the customer needs. They make plans for the system but do not tie their view to it. Rather than making models they want to focus more on the working software. They focus on interaction within the team members, customers and management and individual skills as well. With all the readings and findings it is clear that there is no "one-size-fits-all" solution.\par
a) Limitations There were some obstacles on the way to the success of this thesis. At first, Gathering the information from the professionals and practitioners in the industry was a problem as it takes long time for most of them to respond to the questionnaire. There were some returned questionnaires half-completed which had to be discarded. Another barrier was the time factor. Even though there are lots of areas that can be focused under this topic it was not possible since the allocated time was limited. But within the time period a good and original piece of work was produced with great attention. 
\section[{b) The Guidelines}]{b) The Guidelines}\par
The guide lines presented are to support an organization to select the most appropriate software development methodology for software projects they undertake. For an organization, it is hard to have more than single software methodologies operating. Generally the top management and human resources would prefer all projects to use the same method for ease of handling.\par
However, software developing is a complex and uncertain process. To cater for specific needs, Project requirements and different teams may have to produce different results. Therefore, it is important to consider adopting different methodologies or a mix and match of several techniques from different methodologies at least between two departments or two different project sections which operate independently in the same organization.\par
The following guidelines are created with the knowledge obtained from the research on the literature and the analysis and understanding gained from the survey results which involved the real software development organizations.\par
? Flexibility -Everybody involved with software development needs to be flexible, starting from the top management. They should understand different projects have different needs and there are different ways to make them successful. ? Priority on the needs -Different projects need Different techniques and artifacts. Therefore, it is important to identify them and prioritize them. For an example the use of other techniques and artifacts outside the working methodology (e.g. planning poker) for certain types of projects may lead the project to greater success. But the management has to remember that, this may need some training to the team members as a person may have to deal with a range of methods and/or artifacts.\par
? Cater according to the team -For different projects, Development teams may be different in size. So it is important to use suitable methodology or mix of methodology to cater for that requirement. As an example, XP and scrum are suitable for projects with small-scale to medium-scale development teams with 4 to 20 members. However, for large and medium scale teams Unified Process can be used. ? Define targets -There are specified artifacts for each approach in traditional development. So organizations rely on these artifacts and always try to stick to them. Rather defining the targets with the help of the customers on what to build may be more productive. The artifacts will be decided along with the targets which is more useful for all the parties involved in that specific project. ? The use of methods -Organizations with large or medium scale projects can combine subsets of different methods. SCRUM is a methodology which can be mixed with different other methodologies including XP and waterfall. However, for organizations, who handle small scale projects can settle with a single methodology.\par
Come up with a specific set of rules is not that easy in a rapidly changing field with uncertainty like software engineering. For different organizations, these guidelines can be used in different ways. With time and experience these can be improved more. The best way is to experiment these in a real time environment and observe the validity and the success, which will give an understanding on how to improve them for better results. Year 2020  \begin{figure}[htbp]
\noindent\textbf{1}\includegraphics[]{image-2.png}
\caption{\label{fig_1}Figure 1 :}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{2}\includegraphics[]{image-3.png}
\caption{\label{fig_2}Figure 2 :}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{}\includegraphics[]{image-4.png}
\caption{\label{fig_3}}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{3}\includegraphics[]{image-5.png}
\caption{\label{fig_4}Figure 3 :}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{4}\includegraphics[]{image-6.png}
\caption{\label{fig_5}Figure 4 :}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{5}\includegraphics[]{image-7.png}
\caption{\label{fig_7}Figure 5 :}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{6}\includegraphics[]{image-8.png}
\caption{\label{fig_9}Figure 6 :}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{7}\includegraphics[]{image-9.png}
\caption{\label{fig_10}Figure 7 :}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{}\includegraphics[]{image-10.png}
\caption{\label{fig_11}}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{8}\includegraphics[]{image-11.png}
\caption{\label{fig_12}Figure 8 :}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{}\includegraphics[]{image-12.png}
\caption{\label{fig_13}}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{9}\includegraphics[]{image-13.png}
\caption{\label{fig_14}Figure 9 represent the resultsFigure 9 :}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{10}\includegraphics[]{image-14.png}
\caption{\label{fig_15}Figure 10}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{12}\includegraphics[]{image-15.png}
\caption{\label{fig_16}Figure 12 :}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{13}\includegraphics[]{image-16.png}
\caption{\label{fig_17}Figure 13 :}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{14}\includegraphics[]{image-17.png}
\caption{\label{fig_18}Figure 14 :}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{15}\includegraphics[]{image-18.png}
\caption{\label{fig_20}Figure 15 :}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{16}\includegraphics[]{image-19.png}
\caption{\label{fig_21}Figure 16 :}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{17}\includegraphics[]{image-20.png}
\caption{\label{fig_22}Figure 17 :}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{18}\includegraphics[]{image-21.png}
\caption{\label{fig_24}Figure 18 :}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{19}\includegraphics[]{image-22.png}
\caption{\label{fig_25}Figure 19 :}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{20}\includegraphics[]{image-23.png}
\caption{\label{fig_26}Figure 20 :}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{21}\includegraphics[]{image-24.png}
\caption{\label{fig_27}Figure 21 :}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{}\includegraphics[]{image-25.png}
\caption{\label{fig_28}}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{22}\includegraphics[]{image-26.png}
\caption{\label{fig_29}Figure 22 :}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{23}\includegraphics[]{image-27.png}
\caption{\label{fig_30}Figure 23 :}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{24}\includegraphics[]{image-28.png}
\caption{\label{fig_32}Figure 24 :}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{25}\includegraphics[]{image-29.png}
\caption{\label{fig_33}Figure 25 :}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{26}\includegraphics[]{image-30.png}
\caption{\label{fig_34}26 :}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{26}\includegraphics[]{image-31.png}
\caption{\label{fig_35}Figure 26}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{} \par 
\begin{longtable}{P{0.85\textwidth}}
Abstract-Agile and Traditional software development\\
methodologies, both are being used in different projects of\\
software development industry. Agile software development\\
technology is an incremental software development process.\end{longtable} \par
 
\caption{\label{tab_0}}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{1} \par 
\begin{longtable}{P{0.3784246575342466\textwidth}P{0.4715753424657534\textwidth}}
Privileged methodological text\tabcellsep Marginalized methodological text\\
\multicolumn{2}{l}{Information systems development is}\\
A managed controlled process\tabcellsep Random, opportunistic process driven by accident\\
A linier sequential process\tabcellsep Processes are simultaneous and overlapping and there are gaps in the between\\
A replicable universal process\tabcellsep Occurs in completely unique and idiographic forms\\
A rational, determined and goal driven process\tabcellsep Negotiated, compromised and capricious\end{longtable} \par
 
\caption{\label{tab_2}Table 1 :}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{} \par 
\begin{longtable}{}
\end{longtable} \par
  {\small\itshape [Note: and gives feedback on how accurate they are to make better future estimates. Further tracker traces the progress of iterations and evaluate if the project goals are reachable within the allocated time with the current resources. The tracker is a programmer, not a manager or customer.? Programmer -Writes tests, design, and code and try to keep them simple and definite as possible. They refactor code identify and estimates tasks and stories. ? Tester -Helps customers write and develop functional tests. They run functional test often to broadcast results and they maintain the test tools. ? Customer -Writes stories and acceptance tests.]} 
\caption{\label{tab_4}}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{} \par 
\begin{longtable}{P{0.85\textwidth}}
f) Traditional Software Development\\
i. Outline\\
"By applying a methodology to the\\
development of software\end{longtable} \par
 
\caption{\label{tab_5}?}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{2} \par 
\begin{longtable}{}
\end{longtable} \par
 
\caption{\label{tab_6}Table 2 :}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{3} \par 
\begin{longtable}{P{0.2636231884057971\textwidth}P{0.29565217391304344\textwidth}P{0.2907246376811594\textwidth}}
Positivism\tabcellsep Phenomenology\tabcellsep Realism\\
Objective truth analysis Value-free data collection Law-like generalization Quantitative approach\tabcellsep Subjective truth analysis People's account, motives and intentions Complex and dynamic Qualitative approach\tabcellsep Socially constructed environment analysis Independent reality Social influences recognized Qualitative approach\end{longtable} \par
 
\caption{\label{tab_7}Table 3 :}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{4} \par 
\begin{longtable}{P{0.20407098121085593\textwidth}P{0.32828810020876825\textwidth}P{0.3176409185803758\textwidth}}
Exploratory\tabcellsep Descriptive\tabcellsep Explanatory\\
A study to find new insights Useful for clarifying the understanding of the problem Qualitative approach\tabcellsep A study to describe an accurate profile of persons, events or situations Useful for giving details of incidence or phenomena and for predictive findings Quantitative approach\tabcellsep A study to find casual relationship between variables Useful for explaining the relationship of two or more incidents in terms of cause and effect Quantitative approach\end{longtable} \par
 
\caption{\label{tab_8}Table 4 :}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{5} \par 
\begin{longtable}{P{0.49685251798561153\textwidth}P{0.22778776978417264\textwidth}P{0.06573741007194245\textwidth}P{0.02446043165467626\textwidth}P{0.02446043165467626\textwidth}P{0.010701438848920863\textwidth}}
\tabcellsep \multicolumn{4}{l}{people do and say. It reports on the concepts,}\\
\tabcellsep meanings,\tabcellsep \multicolumn{2}{l}{definitions,}\tabcellsep characteristics,\tabcellsep symbols\\
\multicolumn{3}{l}{research apply individual in detail interviews, focus groups or questionnaires to gather examine and interpret information by observing what metaphors, and Quantitative Data}\tabcellsep \multicolumn{2}{l}{Qualitative Data}\\
Based on meaning derived from numbers\tabcellsep \multicolumn{4}{l}{Based on meanings expressed through words}\\
Collection results in numerical and standardized data\tabcellsep \multicolumn{4}{l}{Collection results in non-standardized data requiring}\\
\tabcellsep \tabcellsep \multicolumn{3}{l}{classification into categories.}\\
Analysis carry out throughout the use of statistics and\tabcellsep \tabcellsep \tabcellsep \\
diagram\tabcellsep \tabcellsep \tabcellsep \end{longtable} \par
 
\caption{\label{tab_9}Table 5 :}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{6} \par 
\begin{longtable}{P{0.31126760563380285\textwidth}P{0.25140845070422535\textwidth}P{0.17957746478873238\textwidth}P{0.10774647887323943\textwidth}}
Information technology\tabcellsep Telecommunication\tabcellsep Engineering\tabcellsep Others\\
70\%\tabcellsep 15\%\tabcellsep 10\%\tabcellsep 5\%\end{longtable} \par
 
\caption{\label{tab_10}Table 6 :}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{7} \par 
\begin{longtable}{P{0.677258064516129\textwidth}P{0.13709677419354838\textwidth}P{0.03564516129032258\textwidth}}
5\%\tabcellsep \\
10\%\tabcellsep \\
\tabcellsep Information technology\\
15\%\tabcellsep Telecommunication\\
\tabcellsep Engineering\\
\multicolumn{2}{l}{Developers 53\% Figure 10 represent these results. iii. 70\% Analyst Software engineer 13\% 20\% Respondents' job positions Project manager 7\% Others 53\% 20\% 7\% 7\% Developers Analyst Software engineer Project manager 13\% Executive}\tabcellsep Executive 7\%\end{longtable} \par
 
\caption{\label{tab_11}Table 7 :}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{8} \par 
\begin{longtable}{P{0.31627906976744186\textwidth}P{0.13837209302325582\textwidth}P{0.13837209302325582\textwidth}P{0.1449612403100775\textwidth}P{0.112015503875969\textwidth}}
Less than 10\tabcellsep Between 10 and 20\tabcellsep Between 21 and 50\tabcellsep Between 51 and 100\tabcellsep More than 100\\
7\%\tabcellsep 20\%\tabcellsep 26\%\tabcellsep 27\%\tabcellsep 20\%\\
\multicolumn{2}{l}{Figure 11 represent these results}\tabcellsep \tabcellsep \tabcellsep \end{longtable} \par
  {\small\itshape [Note: Figure 11: Employees' in software development in organizations iv. Agile and Traditional Software methodology Knowledge of the respondents]} 
\caption{\label{tab_12}Table 8 :}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{9} \par 
\begin{longtable}{P{0.3673728813559322\textwidth}P{0.20889830508474577\textwidth}P{0.273728813559322\textwidth}}
Cost\tabcellsep This surver\tabcellsep Ambler (2007) survey\\
Very low\tabcellsep 7\%\tabcellsep 2\%\\
Slight low\tabcellsep 22\%\tabcellsep 20\%\\
No change\tabcellsep 50\%\tabcellsep 54\%\\
Slight High\tabcellsep 18\%\tabcellsep 21\%\\
Very high\tabcellsep 3\%\tabcellsep 3\%\end{longtable} \par
 
\caption{\label{tab_13}Table 9 :}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{10} \par 
\begin{longtable}{P{0.3762295081967213\textwidth}P{0.20901639344262293\textwidth}P{0.2647540983606557\textwidth}}
Quality\tabcellsep This Survey\tabcellsep Ambler (2007) survey\\
Very low\tabcellsep 5\%\tabcellsep 1\%\\
Slight low\tabcellsep 10\%\tabcellsep 2\%\\
No change\tabcellsep 39\%\tabcellsep 31\%\\
Slight High\tabcellsep 33\%\tabcellsep 47\%\\
Very High\tabcellsep 13\%\tabcellsep 19\%\end{longtable} \par
 
\caption{\label{tab_14}Table 10 :}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{} \par 
\begin{longtable}{P{0.7340450771055753\textwidth}P{0.048398576512455514\textwidth}P{0.012099644128113879\textwidth}P{0.04436536180308422\textwidth}P{0.011091340450771056\textwidth}}
Small scale\tabcellsep \multicolumn{2}{l}{Medium scale}\tabcellsep Large scale\\
Heavy Documentation\tabcellsep \tabcellsep \\
Comprehensive Upfront Planning\tabcellsep \tabcellsep \\
Autocratic management Style\tabcellsep \tabcellsep \\
Not able to change\tabcellsep \tabcellsep \\
\multicolumn{4}{l}{17. How would you think the agile approaches affect cost of the three sizes of software projects than traditional}\\
methodologies?\tabcellsep \tabcellsep \\
Small scale\tabcellsep \multicolumn{2}{l}{Medium scale}\tabcellsep Large scale\\
Very high\tabcellsep \tabcellsep \\
Slightly high\tabcellsep \tabcellsep \\
No change\tabcellsep \tabcellsep \\
Slightly low\tabcellsep \tabcellsep \\
Very low\tabcellsep \tabcellsep \\
18. Small scale\tabcellsep \multicolumn{2}{l}{Medium scale}\tabcellsep Large scale\\
Very high\tabcellsep \tabcellsep \\
Slightly high\tabcellsep \tabcellsep \\
No change\tabcellsep \tabcellsep \\
Slightly low\tabcellsep \tabcellsep \\
Very low\tabcellsep \tabcellsep \\
\multicolumn{3}{l}{19. To what extent do you follow agile techniques for the three sizes of projects?}\\
\multicolumn{2}{l}{Small scale}\tabcellsep \multicolumn{2}{l}{Medium scale}\tabcellsep Large scale\\
100\% follow all agile techniques\tabcellsep \tabcellsep \\
75\% follow all agile techniques\tabcellsep \tabcellsep \\
50\% follow all agile techniques\tabcellsep \tabcellsep \\
25\% follow all agile techniques\tabcellsep \tabcellsep \\
\multicolumn{2}{l}{20. Which methodology do you prefer for different software projects?}\tabcellsep \\
Small scale\tabcellsep \multicolumn{2}{l}{Medium scale}\tabcellsep Large scale\\
Agile methodologies\tabcellsep \tabcellsep \\
Traditional methodologies\tabcellsep \tabcellsep \\
Other (Please specify):\tabcellsep \tabcellsep \end{longtable} \par
  {\small\itshape [Note: OptionalIf you would like to have a summary of the survey results, please provide contact details Name: \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore  Email: \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore  Organisation: \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore  Thank you for all your valuable time in completing this questionnaire.]} 
\caption{\label{tab_15}}\end{figure}
 		 		\backmatter   			 
\subsection[{Acknowledgement}]{Acknowledgement}\par
I would like to acknowledge and state my total pleasure to those whose efforts and support in one way or the other contributed to the successful completion of this research study. I particularly wish to convey profound gratitude to my supervisor, Dr. Nigel Kermode, for his invaluable support, encouragement, useful suggestions and supervision throughout this research work. I also wish to thank my friend Mr. Khondker Razeeb-us-Saleheen, my class mates and my brother, Mr. Channa punchihewa for his support during my study. I am as ever, especially indebted to my parents, Mr. and Mrs. Rahman for their love and support throughout my life. Moreover, to my Almighty who made all the things possible. 			  			 \par
Appendix 1: Questionnaire The objective of this survey is to find out various methods been used in the software industry for software development. The data collected will be strictly confidential and will only be used for this academic research. Please share your views about your experiences and your personal opinions. If you require a summary of the findings please complete the optional section at the end of this questionnaire.\par
The questionnaire is divided in to three sections. The questions contained are all close end questions. But if you have any comments for any of the questions please include them with the questions.\par
For any questions or clarifications please contact me, A.K.M Zahidul Islam akmzahidulislam102@gmail.com 			 			  				\begin{bibitemlist}{1}
\bibitem[Mcneil and Chapman ()]{b53}\label{b53} 	 		\textit{},  		 			P Mcneil 		,  		 			S Chapman 		.  		1985.  	 	 (Research Methods) 
\bibitem[Kerlinger and Lee ()]{b54}\label{b54} 	 		\textit{},  		 			F Kerlinger 		,  		 			H Lee 		.  	 	 		\textit{Foundations of Behavioral Research}  		2000. International Thomson Publishing.  	 
\bibitem[Lindvall et al. (ed.) ()]{b39}\label{b39} 	 		\textit{},  		 			M Lindvall 		,  		 			V Basili 		,  		 			B Boehm 		,  		 			P Costa 		,  		 			K Dangle 		,  		 			F Shull 		,  		 			R Tesoriero 		,  		 			L Williams 		,  		 			M Zelkowitz1 		.  		Agile Methods, D. Wells and L. Williams (ed.)  		2002. p. .  		 			XP/Agile Universe 		 	 
\bibitem[Saunders et al. ()]{b51}\label{b51} 	 		\textit{},  		 			M Saunders 		,  		 			P Lewis 		,  		 			A Thornhill 		.  		2003. Prentice Hall.  	 	 (3rd. Research Methods for Business Students) 
\bibitem[Dekkers ()]{b16}\label{b16} 	 		\textit{},  		 			R Dekkers 		.  	 	 		\textit{International Journal of Networking and Virtual Organizations}  		2005. 3 p. .  	 
\bibitem[Davis and Sitaram ()]{b34}\label{b34} 	 		‘A concurrent process model of software development’.  		 			A Davis 		,  		 			P Sitaram 		.  	 	 		\textit{ACM sigsoft. Software Engineering Notes}  		1994. 19  (2) .  	 
\bibitem[Cockburn ()]{b20}\label{b20} 	 		\textit{A Methodology Per Project},  		 			A Cockburn 		.  		 \url{http://alistair.cockburn.us/Methodology+per+project}  		2008.  	 
\bibitem[Heckman and Williams]{b3}\label{b3} 	 		‘A Model Building Process for Identifying Actionable Static Analysis Alerts’.  		 			S Heckman 		,  		 			L Williams 		.  	 	 		\textit{2nd IEEE International Conference on Software Testing, Verification, and Validation},  				 (Denver, CO, USA)  		 	 	 (to appear) 
\bibitem[Coffin and Lane ()]{b22}\label{b22} 	 		\textit{A Practical Guide to Seven Agile Methodologies},  		 			R Coffin 		,  		 			D Lane 		.  		 \url{http://www.devx.com/architect/Article/32836/1954}  		2007.  	 
\bibitem[Boehm ()]{b8}\label{b8} 	 		‘A Spiral Model of Software Development and Enhancement’.  		 			B W Boehm 		.  	 	 		\textit{Computer}  		1988.  	 	 (IEEE software) 
\bibitem[Khan and Balbo]{b38}\label{b38} 	 		\textit{A Tale of two Methodologies: Heavyweight versus Agile},  		 			A Khan 		,  		 			S Balbo 		.  		 \url{http://ausweb.scu.edu.au/aw04/papers/edited/balbo/}  		 	 
\bibitem[Ambler ()]{b2}\label{b2} 	 		\textit{Agile Adoption Survey},  		 			S Ambler 		.  		 \url{http://www.ambysoft.com/surveys/agileFebruary2008.html}  		2008.  	 
\bibitem[Larman ()]{b15}\label{b15} 	 		\textit{Agile and iterative development: a manager's guide},  		 			C Larman 		.  		2004. Addison-Wesley.  	 
\bibitem[Mccauley ()]{b13}\label{b13} 	 		‘Agile Development Methods, Poised to Upset Status Quo’.  		 			R Mccauley 		.  	 	 		\textit{SIGCSE Bullentin}  		2001. 33  (4)  p. .  	 
\bibitem[Langr ()]{b17}\label{b17} 	 		\textit{Agile Java?: Crafting Code with Test-Driven Development},  		 			J Langr 		.  		2006.  	 
\bibitem[Agile Mainfesto ()]{b0}\label{b0} 	 		\textit{Agile Mainfesto},  		 \url{http://www.agilealliance.org/}  		2002.  	 	 (Agile Alliance) 
\bibitem[Rakitin (2005)]{b19}\label{b19} 	 		\textit{Agile Methods -Beyond the Hype. Food for Thought newsletter from Software Quality 22. Consulting},  		 			S Rakitin 		.  		 \url{http://www.swqual.com/newsletter/vol2/no7/vol2no7.html\#article}  		2005. July/August 2005. 04/05/2007. 2.  	 
\bibitem[Cockburn ()]{b21}\label{b21} 	 		\textit{Agile software development},  		 			A Cockburn 		.  		2001. Boston, MA: Addison-Wesley.  	 
\bibitem[Highsmith ()]{b25}\label{b25} 	 		\textit{Agile software development},  		 			Cockburn Highsmith 		,  		 			A 		.  		2001. Boston, MA: Addison-Wesley.  	 
\bibitem[Kalermo and Rissanen ()]{b35}\label{b35} 	 		\textit{Agile software development in theory and practice},  		 			J Kalermo 		,  		 			J Rissanen 		.  		2002.  	 
\bibitem[
			Abrahamson
		 (2001)]{b1}\label{b1} 	 		\textit{Agile software development methods -review and analysis},  		 			Abrahamson 		.  		 \url{http://www.sdmagazine.com/documents/s=844/sdm0108a/0108a.htm}  		2002. 2001. August.  	 	 (The Agile Manifesto. Software Development Magazine) 
\bibitem[Schwaber and Beedle ()]{b11}\label{b11} 	 		\textit{Agile Software Development with SCRUM},  		 			K Schwaber 		,  		 			A Beedle 		.  		2002. UpperSaddle River, NJ: Prentice-Hall.  	 
\bibitem[Highsmith and Cockburn ()]{b10}\label{b10} 	 		‘Agile Software Development: the Business of Innovation’.  		 			J Highsmith 		,  		 			A Cockburn 		.  	 	 		\textit{IEEEComputer}  		2001. 34  (9)  p. .  	 
\bibitem[Boehm and Turner ()]{b9}\label{b9} 	 		 			B Boehm 		,  		 			R Turner 		.  		\textit{People Factors in Software Management: Lessons From Comparing Agile and Plan-Driven Methods. CROSSTALK; the Journal of Defense Software Engineering},  				2003.  	 
\bibitem[Cohn ()]{b23}\label{b23} 	 		\textit{Cited by Planning Poker in Detail},  		 			M Cohn 		.  		 \url{http://www.planningpoker.com/detail.html}  		2005.  	 
\bibitem[Robinson ()]{b27}\label{b27} 	 		\textit{Consider DSDM as an XP alternative},  		 			S Robinson 		.  		 \url{http://articles.techrepublic.com.com/5100-10878\textunderscore 11-1049982.html}  		2002.  	 
\bibitem[Charette ()]{b48}\label{b48} 	 		\textit{Cutter consortium e-Project management Advisory service},  		 			R Charette 		.  		2001. 2 p. 19.  	 	 (The decision is in: Agile versus heavy methodologies) 
\bibitem[Ashford and Ehn ()]{b12}\label{b12} 	 		\textit{Dynamic Systems Development Method, version 3},  		 			Eng Ashford 			\mbox{}\\  				DSDM Consoritum. 			 		,  		 			P Ehn 			\mbox{}\\  				DSDM Consoritum. 			 		.  		2008. 1989. Lawrence Erlbaum, Hillsdale, NJ.  	 	 (Work-oriented design of computer artifacts) 
\bibitem[Beck ()]{b5}\label{b5} 	 		‘Embracing change with Extreme Programming’.  		 			K Beck 		.  	 	 		\textit{IEEE Computer}  		1999. 13 p. .  	 
\bibitem[Beck ()]{b6}\label{b6} 	 		\textit{Extreme Programming Explained: Embrace Change},  		 			K Beck 		.  		2005. Addison-Wesley.  	 	 (Second ed. Reading) 
\bibitem[Beck ()]{b4}\label{b4} 	 		\textit{Extreme Programming Explained: Embrace Change. Reading},  		 			K Beck 		.  		2000. Addison-Wesley.  	 
\bibitem[Paulk ()]{b33}\label{b33} 	 		\textit{Extreme programming from a CMM perspective. Software, 18, 6},  		 			M C Paulk 		.  		2001. p. .  	 
\bibitem[Ghosh and Chopra ()]{b37}\label{b37} 	 		 			B N Ghosh 		,  		 			P K Chopra 		.  		\textit{Dictionary of Research Method},  				 (Leeds, UK)  		2003.  	 
\bibitem[Vaihansky et al. ()]{b31}\label{b31} 	 		\textit{Hyperproductivity In Large Projects Though Distributed Scrum. Agile journal},  		 			P Vaihansky 		,  		 			J Sutherland 		,  		 			A Victorov 		.  		 \url{http://www.offshoreagile.com/news/?doc=205}  		2006.  	 
\bibitem[Avison and Fitzgerald ()]{b47}\label{b47} 	 		\textit{Information Systems Development: Methodologies, Techniques and Tools},  		 			D E Avison 		,  		 			G Fitzgerald 		.  		1995. McGraw-Hill.  	 
\bibitem[Royce]{b45}\label{b45} 	 		‘Managing the Development of Large Software Systems’.  		 			W W Royce 		.  	 	 		\textit{IEEE Western Conference (Wescon). Pages},  				p. .  	 
\bibitem[Rakitin ()]{b18}\label{b18} 	 		‘Manifesto Elicits Cynicism’.  		 			S Rakitin 		.  	 	 		\textit{IEEE Computer}  		2001. 34  (12)  p. 4.  	 
\bibitem[Renhui and Fengyong ()]{b26}\label{b26} 	 		‘Multi-Attribute Evaluation for Software Project Risk’.  		 			L Renhui 		,  		 			Z Fengyong 		.  	 	 		\textit{IEEE Xplore}  		2007. p. .  	 
\bibitem[Booch ()]{b7}\label{b7} 	 		\textit{Object Oriented Analysis and Design with Applications},  		 			G Booch 		.  		1994. Addison Wesley Longman.  	 	 (2nd edition) 
\bibitem[Parekh ()]{b43}\label{b43} 	 		 			N Parekh 		.  		 \url{http://www.buzzle.com/editorials/1-13-2005-64082.asp}  		\textit{Spiral Model -A New Approach towards Software Development},  				2005b.  	 
\bibitem[Patzer ()]{b55}\label{b55} 	 		 			Gordon L Patzer 		.  		\textit{Experiment-Research Methodology in Marketing. Types and Applications, Quorum Books},  				 (Westport)  		1996.  	 
\bibitem[Maylor and Blackmon ()]{b52}\label{b52} 	 		\textit{Researching Business and Management. Hampshire and 57},  		 			H Maylor 		,  		 			K Blackmon 		.  		2005. New York: Palgrave MacMillan.  	 
\bibitem[Peters and Pedrycz ()]{b44}\label{b44} 	 		\textit{Software Engineering: An Engineering Approach},  		 			J F Peters 		,  		 			W Pedrycz 		.  		2000. John Wiley \& Sons.  	 
\bibitem[Lijek ()]{b41}\label{b41} 	 		\textit{Software life cycle models in the defense industry},  		 			S Lijek 		.  		2007.  	 
\bibitem[Georgiadou ()]{b36}\label{b36} 	 		‘Software Process and Product Improvement, A Historical Perspective’.  		 			E Georgiadou 		.  	 	 		\textit{Volume1, No1. Pages},  				2003. p. .  	 
\bibitem[Miller ()]{b14}\label{b14} 	 		‘The Characteristics of Agile Software process’.  		 			G G Miller 		.  	 	 		\textit{The 39th International Conference of Object Oriented Languages and Systems},  				2001.  	 
\bibitem[Kim ; Nandhakumar and Avison ()]{b24}\label{b24} 	 		‘The Fiction of Methodological Development: A Field Study of Information Systems Development’.  		 			Moonzoo Kim ; Nandhakumar 		,  		 			J Avison 		,  		 			DE 		.  	 	 		\textit{Information Technology \& People}  		2007. 1999. 12  (2)  p. .  	 	 (Agile development 28) 
\bibitem[Takeuchi and Nonaka ()]{b30}\label{b30} 	 		‘The New New Product Development Game’.  		 			H Takeuchi 		,  		 			I Nonaka 		.  	 	 		\textit{Comptuer. Harvard Business Review}  		1986.  	 
\bibitem[Devdaily]{b32}\label{b32} 	 		\textit{The rational unified process},  		 			Devdaily 		.  		 \url{http://www.devdaily.com/java/java\textunderscore oo/node19.shtml}  		 	 
\bibitem[Parekh ()]{b42}\label{b42} 	 		\textit{The waterfall model explained},  		 			N Parekh 		.  		 \url{http://www.buzzle.com/editorials/1-5-2005-63768.asp}  		2005a.  	 
\bibitem[Williams ()]{b46}\label{b46} 	 		‘The XP Programmer: The Few Minutes Programmer’.  		 			L Williams 		.  	 	 		\textit{IEEE Software}  		2003. 20  (3) .  	 
\bibitem[Krasner ()]{b40}\label{b40} 	 		‘Using the Cost of Quality Approach for Software’.  		 			H Krasner 		.  	 	 		\textit{Computer. CROSSTALK; the Journal of Defence Software Engineering}  		1998.  	 
\bibitem[Clifton and Dunlap ()]{b49}\label{b49} 	 		\textit{What is DSDM},  		 			M Clifton 		,  		 			J Dunlap 		.  		 \url{http://www.codeproject.com}  		2003a.  	 
\bibitem[Clifton and Dunlap ()]{b50}\label{b50} 	 		\textit{What is SCRUM},  		 			M Clifton 		,  		 			J Dunlap 		.  		 \url{http://www.codeproject.com}  		2003b.  	 
\bibitem[Schwaber ()]{b28}\label{b28} 	 		\textit{What is Scrum},  		 			K Schwaber 		.  		 \url{http://www.scrumalliance.org/resources/227}  		2007.  	 
\bibitem[Sliwa ()]{b29}\label{b29} 	 		\textit{XP, Scrum join forces},  		 			C Sliwa 		.  		 \url{http://www.computerworld.com/action/article.do?command=viewArticleBasic\&articleId=69183}  		2002.  	 
\end{bibitemlist}
 			 		 	 
\end{document}
