\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={Requirement Implementation and Defect Removal across Component Versions: A Simulation Based Approach},
 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{2012-01-15 (revised: 15 January 2012)}
\def\TheID{\makeatother }
\def\TheDate{2012-01-15}
\title{Requirement Implementation and Defect Removal across Component Versions: A Simulation Based Approach}
\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]{Sandeep  Kumar}

             \affil[1]{  Galaxy Global Group of Institutions, Dinarpur, Ambala, Haryana, India.}

\renewcommand\Authands{ and }

\date{\small \em Received: 15 December 2011 Accepted: 31 December 2011 Published: 15 January 2012}

\maketitle


\begin{abstract}
        


Competition in component market and short time to market the software components forces the organization to develop and launch the components in an iterative manner. Components are launched in various versions. All gathered requirements cannot be implemented in initial version. So requirements need to be prioritized and implemented in subsequent versions. Similarly defects in one version are taken care of in subsequent versions. In the present work we have proposed a simulation model that can be used to study the operational characteristics of the requirements implementation process and defect removal process in a Component Based Software.

\end{abstract}


\keywords{Component Based Software, COTS, Simulation, Requirements Implementation, Defects Removal, Exponential Distribution, Normal Distribution.}

\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*}


\let\tabcellsep& 	 	 		 
\section[{Introduction}]{Introduction}\par
raditionally, development of software would focus on developing for a particular kind of application only. But Component Based Development is a market driven technology. Here Components are not developed for a specific application. Rather they are developed to be reused in many different kinds of applications. Different organizations in the common marketplace offer different components for the same functionality. Though, competition in the market is not that much high at present, but looking at the growth trends of the component based technology, the day doesn't seem to be far away when there will be a cut throat competition in the COTS market. In such type of scenario, it becomes very important for various market players and stakeholders to develop quality software components in least available time and release them in market. In this market driven environment, Requirement Engineering is getting more and more attention \hyperref[b0]{[1]}, \hyperref[b1]{[2]},  {\ref [3]} It's not only that quality components are to be released in the market as soon as possible; equally important is that the quality of the components is improved gradually. Various organizations throughout geographically dispersed locations improve the components continuously and release their independent versions in the market after the improvements [4], [5],  {\ref [6]}. If we follow Evolutionary development paradigm \hyperref[b6]{[14]} then an organization must deliver first operational version of the software or component as fast as the system architecture is defined. This first version should incorporate a minimum set of requirements in such a way so that the end user can start working with it. That's why this initial version should be called an operational model. One of the reasons for the early release of the first operational version and subsequent versions of a software component is short time to market for components. Once first version of the component has been released in the market and used by the users, remaining system requirements (that were not incorporated in the earlier version) and some new requirements can be added to the component in its future version releases. Not only this, users of the component will come up with certain defects in the earlier version of the component. These defects can also be removed in such a way that they are not present in all future versions. Though it is possible that some new defects may creep-up in the current version release, and they can always be taken care of in the next version.\par
Although it is never possible to freeze the requirements in any software development paradigm, still efforts should be made to gather as much requirements as possible, before the release of first version of that component. Out of these most important features can be implemented in the first version of the component and rest of the features can be implemented in subsequent component versions, along with newly generated requirements between release of any two versions, and defects identified in previous component version removed.\par
For the efficient development of software component, requirements should be properly elicited, analysed and documented at the beginning of a project. Also important is the correct implementation and management of these requirements in the later stages of the component development and integration. This becomes all the more important because all other component development activities are based on how efficiently requirements have been managed. In an ideal software component development environment it is just sufficient to elaborate the requirements into working Year software component designs, code, and tests. But software development in general and component development in particular is not that much a straight forward thing. In practical software development process (component development processes in that sense), the requirements keep changing, new requirements keep coming and sometimes old requirements need to be removed also. So the process of management and implementation of requirements is a complex task. Need to develop and release initial component version as quickly as possible makes the process more complex. Due to this sometimes problems are encountered in maintaining consistency among the various releases of the component versions. These problems generally come into picture when components are integrated in a component based system.\par
The process improvement proposals in an organization can be analysed by carrying out pilot studies or controlled experiments in that organization  {\ref [7]}. But this method is very time consuming and resource crunching. Alternatively, simulations can be used to study the behaviour of such a system [8],  {\ref [9]}. Simulation approach has been applied in many areas of engineering and is suitable for application in evaluation of software development processes also. After analysing the new processes using simulation, they can also be analysed in experiments and case studies to establish the fairness of the results obtained using simulation. In this way simulations can be a natural part of technology transfer [10] and evaluation. If simulation is applied for the evaluation of new technologies and processes then it becomes easy to identify the changes and evaluate them in experiments and pilot projects. Sometimes there are certain changes that do not result in process improvement. Application of simulation reduces the risks associated with such changes. Lot of human resources are often involved in experiments and pilot-studies in an organization, introduction and evaluation of wrong changes can lead to a lot of problems. This can potentially damage the continued process improvement work in the organisation for a long time. Hence simulation is needed in the evaluation of new software process technologies.\par
In the present work, we have proposed application of discrete event simulation \hyperref[b3]{[11]} using queuing network model \hyperref[b4]{[12]}. Objective of the study is to find ways for effective management of the human resources of an organization for requirement management and implementation and defect removal while releasing various versions of a software component one after the other. The motivation for the proposed model has come from REPEAT (Requirement Engineering Process At Telelogic) \hyperref[b7]{[15]}.\par
Basic idea is to have a database of all the requirements to be implemented in a software component. But it is not possible to implement all the requirements in first (or few subsequent versions for that matter) version of the component due to many factors. Most influential of these factors being the competition from other market players and very short time to market. Due to this reason requirements need to be prioritized on some basis and implemented according to their priorities. The steps of the REPEAT lifecycle model for requirement implementation are given as follow \hyperref[b5]{[13]}: 
\section[{New}]{New}\par
This state represents the initial state of a requirement, and every requirement is defined as new immediately after it has been issued and given an initial priority. 
\section[{Assigned}]{Assigned}\par
A requirement is elevated to the assigned state when an expert team has been assigned to investigate the requirement and determine the value of a number of attributes. 
\section[{Classified}]{Classified}\par
When reaching this state, an expert team has assigned values to attributes representing a rough estimate of cost and architectural impact. Comments and implementation ideas may also be stated. 
\section[{Selected}]{Selected}\par
All requirements in this state are selected for implementation for the coming release. They are sorted in priority order on two list: a must-list for mandatory requirements and a wish-list for "nice-to-have" requirements. They also have attributes assigned concerning detailed cost and impact estimations. There is also a more detailed textual specification of the requirement. A selected requirement may be deselected, due to changed circumstances, and then re-enters the classification state or gets rejected. 
\section[{Applied}]{Applied}\par
This is an end-state indicating that the requirement has been implemented and verified. The requirement is now incorporated in a component release that can be marketed to customers.  
\section[{Rejected}]{Rejected}\par
This is an end-state indicating that the requirement has been rejected, e.g. because it is a duplicate, already implemented, or it does not comply with the long-term product strategy. 
\section[{II.}]{II.} 
\section[{Proposed model}]{Proposed model}\par
For the proposed model, we assume that first operational version of the component has been released in the market. Model can be implemented from second version onwards. Once, the first component version (with bare minimum requirements) becomes operational, process for the release of second and subsequent versions start. More requirements may be added to the requirement database between the releases of any two versions. So this set of requirements to be implemented in a version of software component form a queue. These requirements are to be implemented by a team of developers. Once a component has been released in the market, it is used by various end users in their applications and feedback from the users is received. Certain defects may also be reported by the users. These defects may have crept in due to implementation errors or discrepancies. These defects need to be removed so that they are not part of any future version of the component. So these defects form another set of inputs to the system. We assume that requirements to be implemented in the future component version and defects reported from the previous component version form a common queue.\par
System is modelled as "two parallel servers" queuing system. It is the job of Software Component project manager, modelled as team T, to decide which of the inputs are new requirements, and which of the inputs are defects. Depending upon the nature of input, it is assigned to a different team. Requirement implementation is performed by team TR and defect removal process is performed by team TD.  
\section[{New}]{New} 
\section[{TERMS and notations}]{TERMS and notations}\par
Following terms and notations have been used for the proposed queuing model of the system as far as arrival patterns and service patterns are concerned: IV. 
\section[{Algorithm}]{Algorithm}\par
Formally, algorithm for the model is described as follows: 1. Read Input Data. ii. Generate stR's using normal distribution with mean mR and standard deviation sdR.\par
iii. sR:= clock+stR. ii. Generate stD's using normal distribution with mean mD and standard deviation sdD.\par
iii. sD:= clock+stD. V. 
\section[{Results and discussion}]{Results and discussion}\par
Simulator was executed for various values of SRUNS. If we assume that on an average 1 requirement or defect arrives at team T every 7 time units, with exponential distribution, requirements are implemented by team TR at a service rate that is normally distributed with value of mR=6.0 and sdR=2.0; and defects are removed by team TD at a service rate that is again normally distributed with value of mD=12.0 and sdD=6.0, then results for various values of SRUNS are shown in table \hyperref[tab_0]{1}.\par
Graph in figure  {\ref 3} shows that values of various operational characteristics have larger variation if simulator is run less than 10000 times. Values of btR, itR, btD and itD tend to stabilize after 10000 simulation runs. Same is true for the results depicted in figure  {\ref 4}. Hence it can be said that 10000 simulation runs are sufficient to get the accurate results. Relationships between number of simulation runs v/s N, R and D is shown in figure 5.\par
Table \hyperref[tab_1]{2} shows the results obtained from 50000 simulation runs where value of ? varies from 5 to 10 in steps of 1. Table contains values of idle times of teams TR (itR) and TD (iTD), waiting times of teams TR (wtR) and team TD (wtD) and maximum queue lengths at TR and TD for various values of ?. It is clear from figure  {\ref 4} that idle times of team TR (itR) and team TD (itD) increase with the increase in the value of ?. waiting times of the requirements and defects decrease with increase in the values of ?. There is variation in maximum queue lengths initially, but as the value of ? increases, maximum queue lengths for both the teams tend to get stabilize.    In the presented work, a simulator has been proposed that can be helpful in implementation of user requirements and removal of defects across various versions of a software component in such a way so that size of the requirements implementation team and defects removal team can be optimized. Simulator has been modelled as a two parallel server queuing model, where requirements and defects initially form a common queue and then they are categorized as requirements or defects depending upon their characteristics. Requirements and defects are then handled by different teams. Busy and idle times of both the teams can be studied and depending upon that team size can be decided. Simulator can also be used to study other operational characteristics like the time a requirement or defect has to spend waiting before it is implemented/ removed and maximum length of the queues formed by requirements and defects at each team.   
\section[{Yeh}]{Yeh}\begin{figure}[htbp]
\noindent\textbf{}\includegraphics[]{image-2.png}
\caption{\label{fig_0}T}\end{figure}
         \begin{figure}[htbp]
\noindent\textbf{1} \par 
\begin{longtable}{P{0.85\textwidth}}
2012\\
Year\\
33\\
Volume XII Issue XIII Version I\\
D D D D ) C\\
(\end{longtable} \par
 
\caption{\label{tab_0}Table 1 :}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{2} \par 
\begin{longtable}{P{0.85\textwidth}}
:\end{longtable} \par
 
\caption{\label{tab_1}Table 2}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{} \par 
\begin{longtable}{P{0.7549402823018457\textwidth}P{0.00738327904451683\textwidth}P{0.009229098805646036\textwidth}P{0.020304017372421282\textwidth}P{0.023995656894679696\textwidth}P{0.0009229098805646037\textwidth}P{0.03322475570032573\textwidth}}
\multicolumn{7}{l}{4. Szyperski C.(1998), Component Software-Beyond}\\
\multicolumn{3}{l}{Object-Oriented}\tabcellsep \multicolumn{2}{l}{Programming.}\tabcellsep \tabcellsep Addison-\\
\multicolumn{5}{l}{Wesley/ACM Press: Boston, MA, 1998.}\tabcellsep \\
\multicolumn{7}{l}{5. Heineman G.T. and Councill W.T. (2001.),}\\
\multicolumn{7}{l}{Component-Based Software Engineering: Putting}\\
\multicolumn{7}{l}{the Pieces Together. Addison-Wesley: Reading.}\\
\multicolumn{7}{l}{6. Crnkovic I. et al.(2001), Proceedings of the Fourth}\\
\multicolumn{7}{l}{ICSE Workshop on Component-Based Software}\\
\multicolumn{7}{l}{Engineering: Component Certification and System}\\
\multicolumn{2}{l}{Predication.}\tabcellsep \multicolumn{2}{l}{Software}\tabcellsep Engineering\tabcellsep \tabcellsep Institute:\\
\multicolumn{2}{l}{Pittsburgh.}\tabcellsep \tabcellsep \tabcellsep \tabcellsep \\
\multicolumn{7}{l}{7. Software Process Simulation Modeling: Why? What?}\\
\multicolumn{7}{l}{How? Journal of Systems and Software, Vol. 46, No.}\\
\multicolumn{2}{l}{2-3, 91-105.}\tabcellsep \tabcellsep \tabcellsep \tabcellsep \\
\multicolumn{7}{l}{9. Pfahl D. and Lebsanft K.(2000), Using Simulation to}\\
\multicolumn{7}{l}{Analyse the Impact of Software Requirement}\\
\multicolumn{7}{l}{Volatility on Project Performance, Proceedings of}\\
\multicolumn{7}{l}{the combined 11th European Software Control and}\\
\multicolumn{7}{l}{Metrics Conference and the 3rd SCOPE conference}\\
on\tabcellsep \multicolumn{2}{l}{Software}\tabcellsep Product\tabcellsep Quality\tabcellsep ,\tabcellsep Munich,\\
\multicolumn{4}{l}{Germany,267-275.}\tabcellsep \tabcellsep \\
\multicolumn{2}{l}{10. Linkman}\tabcellsep S.\tabcellsep and\tabcellsep Rombach,\tabcellsep \tabcellsep H.D.(1997),\\
\multicolumn{7}{l}{Experimentation as a Vehicle for Software}\end{longtable} \par
 
\caption{\label{tab_2}}\end{figure}
 			\footnote{© 2012 Global Journals Inc. (US)} 			\footnote{© 2012 Global Journals Inc. (US)Global Journal of Computer Science and Technology} 			\footnote{© 2012 Global Journals Inc. (US) 1} 		 		\backmatter  			  				\begin{bibitemlist}{1}
\bibitem[Regnel et al. ()]{b7}\label{b7} 	 		\textit{},  		 			B Regnel 		,  		 			P Beremark 		,  		 			O Eklundh 		.  	 	 		\textit{Journal of Requirements Engineering}  		1998. 3  (2)  p. .  	 	 (-A Market-Driven Requirements Engineering Process -Results from an Industrial Process Improvement Programme?) 
\bibitem[Lubars et al. ()]{b0}\label{b0} 	 		‘A Review of the State of the Practice in Requirements Modeling’.  		 			M Lubars 		,  		 			C Potts 		,  		 			C Richter 		.  	 	 		\textit{Proceedings of First IEEE International Symposium on Requirements Engineering (RE'93)},  				 (First IEEE International Symposium on Requirements Engineering (RE'93)San Diego USA)  		1993. IEEE Computer Society Press.  	 
\bibitem[King ()]{b4}\label{b4} 	 		\textit{Computer and Communication Systems Performance Modelling},  		 			P J B King 		.  		1990. Prentice Hall.  	 
\bibitem[Banks et al. ()]{b3}\label{b3} 	 		\textit{Discrete-Event System Simulation},  		 			J Banks 		,  		 			J S Carson 		,  		 			B L Nelson 		.  		1996. Prentice Hall.  	 	 (2nd Ed) 
\bibitem[Potts ()]{b1}\label{b1} 	 		‘Invented Requirements and Imagined Customers: Requirements Engineering for Off-the Shelf Software’.  		 			C Potts 		.  	 	 		\textit{Proceedings of Second IEEE International Symposium on Requirements Engineering (RE'95)},  				 (Second IEEE International Symposium on Requirements Engineering (RE'95)York UK)  		1995. IEEE Computer Society Press.  	 
\bibitem[Carlshamre and Regnell ()]{b5}\label{b5} 	 		‘Requirements Lifecycle Management and Release Planning in Market-Driven Requirements Engineering Processes?’.  		 			P Carlshamre 		,  		 			B Regnell 		.  	 	 		\textit{the Proceedings of International Workshop on the Requirements Engineering Process: Innovative Techniques, Models, and Tools to support the RE Process},  				 (Greenwich UK)  		2000.  	 	 (Published by IEEE CS press in) 
\bibitem[Sommersville ()]{b6}\label{b6} 	 		 			I Sommersville 		.  	 	 		\textit{Software Process Models?},  				1996. 28 p. .  	 
\bibitem[Technology Transfer -A Family of Software Reading Techniques, Information and Software Technology]{b2}\label{b2} 	 		\textit{Technology Transfer -A Family of Software Reading Techniques, Information and Software Technology},  				39 p. .  	 
\end{bibitemlist}
 			 		 	 
\end{document}
