\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={Maintenance vs. Reengineering Software Systems},
 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{2011-12-20 (revised: 20 December 2011)}
\def\TheID{\makeatother }
\def\TheDate{2011-12-20}
\title{Maintenance vs. Reengineering Software Systems}
\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]{Bakhshsish Singh  Gill}

             \affil[1]{  Guru Nanak Dev University}

\renewcommand\Authands{ and }

\date{\small \em Received: 7 November 2011 Accepted: 5 December 2011 Published: 20 December 2011}

\maketitle


\begin{abstract}
        


Maintenance and reengineering terms are closely coupled with each other. These terms came from the world of hardware objects. Now these entered the world of software and are well suitable for software systems. It is difficult to draw a clear cut line between these two terms. Many a times these are used interchangeably. Reengineering of software systems is a topic of importance and in coming time it will be gaining more attention in the world of software systems. Software managers are often confused over maintenance and reengineering. These two terms should be separated to promote the subject matter because one is problem for the other. I will try to put them in different non overlapping regions. Maintenance and reengineering are two different areas in software engineering. Maintenance is for running the system till the age of the system where as the reengineering make the system new to work for another life span. Scope of reengineering is vast and challenging as compared to maintenance. Reengineering is to reduce the expenses on software systems in the organizations. Reengineering has more scope in the world of software than in the world of hard ware objects. Software systems and software objects do not wear and tear out like hardware objects in the real world. Maintenance is close to repair/mend where as reengineering is very close to new development.

\end{abstract}


\keywords{Object, reengineering zone, maintenance zone, transition state, reverse engineering}

\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
oftware engineering is a topic of importance in the age of software and is gaining attention. It is developing fast area and not existing from centuries. Software maintenance and software reengineering both fall in the ambit of software engineering. Both terms came from the real hard ware objects. These are more suited to software systems and software objects as these do not wear or tear out like real world physical objects.\par
These two terms are yet young and developing. There is not clear cut line between them. These terms are mingled and the people are using them interchangeably. One is the problem in the developing the subject matter of the other. Now software is gaining importance in every sphere of life and these two are very closely associated to software system life cycle. It is time to differentiate the two and promote the subject matter of these two concepts. 
\section[{II.}]{II.} 
\section[{SOFTWARE MAINTENANCE}]{SOFTWARE MAINTENANCE}\par
Software maintenance is one of the stages in the software development life cycle. It starts after the deployment of software in the working field. It is to remove the defects and deficiencies which encounters while starts actually working in the field.\par
According to IEEE Std. 610.12  {\ref [7]} 'Software maintenance is the process of modifying a software system or component after delivery to correct faults, improve performances or other attributes, or adapt to a changed environment'. a) Nature and Scope of Maintenance Software maintenance has good scope in future times. In the world of fast changes, maintenance expertise will gain more importance which can sustain the working of software systems. Maintenance means modifying software system or a component of the software system to make it working on the platform and adapt to the minor changes in the requirements, environment or technology. Every system needs maintenance for the whole life period. Maintenance is preservation of the legacy software system.\par
Many surveys have shown that software maintenance can account for 60 to 80 percent of the cost of total life cycle of software product. According to Erlikh more than 90 \% of the total cost of software goes to maintenance and evolution of the software product  {\ref [1]}. According to Lientz and Swanson many organizations were spending 20\% to 70\% of their computing efforts on maintenance  {\ref [8]}.\par
Software maintenance is of following four types 
\section[{Corrective maintenance:}]{Corrective maintenance:}\par
As its name implies, activities of correcting bugs in the software are included in this type of maintenance. It is for making the software system to conform to the real situation. 
\section[{Adaptive Maintenance}]{Adaptive Maintenance}\par
It deals with making the software adjustable to the changed environment 
\section[{Preventive Maintenance}]{Preventive Maintenance}\par
Modification of the software to detect and correct hidden faults (bugs) before becoming active. This paper will help the software managers to recognize and make the best use of these two terminologies for right treatment of software systems. 
\section[{Perfective maintenance}]{Perfective maintenance}\par
It is modification of the software for better performance, maintenance and reliability. The activities related to updating the software are included in this type of maintenance.\par
The efforts (cost) distributions for these four types of maintenance are as under? Corrective maintenance 21\% ? Adaptive Maintenance 25\% ? Preventive Maintenance 4\% ? Perfective maintenance 50\% [6].\par
It is suggested from the above figure that perfective maintenance consumes major part of cost estimation. Preventive maintenance is not taken to any significant level in software industry.\par
Software maintenance and reengineering are hot topics in theses days. Software managers use these two interchangeably. It is time to differentiate maintenance and reengineering in software industry. Software maintenance is last stage in the software development life cycle. Maintenance starts after the delivery of the software. The ability to accurately estimate the time and cost of software maintenance is the key factor for successful of maintenance project.\par
Software maintenance starts after delivery of the software system. It goes on increasing with the increasing age of software as depicted in the following figure  {\ref 1}.\par
Figure  {\ref 1} Accumulated affects of maintenance makes the system complex and deteriorate the system's architecture. Software system goes on aging with time and maintenance cost increases. When maintenance cost is too much high or difficult to maintain, it means system is to retire. Then reengineering is solution at this point. Reengineered software starts working with normal maintenance for another life span. Reengineering should be done at right time. If we overlook this time, reengineering will be costly or even not feasible and then we have to throw the costly legacy software under utilized.\par
III. 
\section[{REENGINEERING}]{REENGINEERING}\par
Reengineering is the analysis of existing software system and modifying it to constitute into a new form. Chikofsky and Cross define reengineering as 'the examination and alteration of a subject system to reconstitute it in a new form and subsequent implementation of that form' \hyperref[b8]{[9]}.\par
According to IEEE Std. 1998 'A systemchanging activity that results in creating a new system that either retains or does not retain the individuality of the initial system' \hyperref[b9]{[10]}. a) Nature and Scope of Reengineering When maintenance cost is not feasible, we go for reengineering the software system. Reengineering makes the software system new. Reengineering has the following three stages. 
\section[{Reverse engineering 2. Architecture transformations 3. Forward engineering}]{Reverse engineering 2. Architecture transformations 3. Forward engineering} 
\section[{Reverse engineering}]{Reverse engineering}\par
In this stage software is thoroughly understood. It is untied and underlying technology is perceived. Business process is improved and requirements are updated. Objects are added or deleted according to the new system planned. In this stage we go from code level to higher level abstraction.  
\section[{Forward engineering}]{Forward engineering}\par
In this stage, we move from higher level of abstraction to code level. In this stage software integrated according to new design. It is vertically downward step as shown in the fig. \hyperref[fig_2]{2}.\par
Figure \hyperref[fig_2]{2} In the above figure, updation of user's requirements and improvement in architecture of software is done in transformation phase.\par
We can express reengineering by the following equation. 
\section[{Reengineering = Reverse engineering + ? + forward engineering}]{Reengineering = Reverse engineering + ? + forward engineering}\par
The symbol in the above equation represents the enhancement and design change. In the coming future, reengineering can solve the problem of software backlogs and it can lower the software investment in organizations. Reengineering can increase the software age. Point T is the transition state from maintenance to reengineering zone. Transition state is new term defined by the author of this paper. It is the state in the life of software when reengineering is best possible with optimal cost. Software system is candidate for maintenance in the first zone and candidate for reengineering in the second zone. Maintenance phase is always first and reengineering phase starts after maintenance phase. When maintenance exhausts, reengineering phase is ready to serve the software system. Both zones are separated by red point T and must not overlap each other. Figure  {\ref 3} Maintenance increases the age of the software and reengineering gave a fresh age period to software system. T is the transition point, beyond point T; it is not feasible to maintain the system. System should be reengineered at the point T. Reengineering cost will be optimal at the critical point T. If we do not reengineering the System at T and go on maintaining the software with high cost, reengineering zone will be exhausted and reengineering is not possible with feasible cost. Then there is no other option than to throw the legacy software and purchase costly new one. Legacy software will be added to the backlog of wasted software.\par
Maintenance phase keeps the software up to date with environment changes and changing user requirements. Reengineering will give another life span to software with normal maintenance. 
\section[{b) Cost based Model}]{b) Cost based Model}\par
Following figure  {\ref 4} depicts the graph of maintenance cost and reengineering cost of Software system. Maintenance cost starts from the point O (Origin) and goes on increasing with time. It starts increasing rapidly from point T because software completes ten years, the normal age of the software. According to literature, software age is seven years for structured systems and ten years for object-oriented software systems. Reengineering cost is all most same up to point T because software is within age at the point T. After point T reengineering cost also starts increasing but with normal rate but maintenance cost increases at high rate. This happens because maintenance zone is over and the software is in reengineering zone beyond point T. Maintenance cost and reengineering cost are equal at the point T as depicted in the figure  {\ref 4}. If both the costs are equal then we must go for reengineer. Reengineering will make the system new on the new platform with new design. Reengineering of the system is needed to bring down the maintenance cost. At this point we think of reengineering or retiring the software. If we retire the system then we have to bear the cost of new software. Cost of new software is much high than the cost of reengineering.\par
Figure  {\ref 4} If we do not reengineering the software system at point T, maintenance cost will increase sharply (as shown in the figure  {\ref 4}) it will be difficult to maintain the system at such a high cost. Maintenance after the point T increases the complexity of the system and decreases the quality of software where as reengineering improves the quality of the software, controls the maintenance cost and increases the life span of the software system.\par
The software system is old at the point T and high maintenance cost is required. It is difficult to maintain the system with such a high maintenance cost. At this point system should be reengineered or retired. If we reengineer the software at this point, Reengineering cost will be lowest (optimal). Reengineered Software will be new one with another life span and Maintenance cost will be ordinary. 
\section[{c) Object based Model}]{c) Object based Model}\par
This is object based model for differentiation of maintenance and reengineering. Maintenance is done to make the faulty object fine. As the system ages, software architecture deteriorate with ripple effects of maintenance. System object becomes faulty and maintenance makes it fine. The number of faulty objects increases with time and maintenance becomes difficult. Then what to Do? Software should be reengineered but when? This is the question. It is to be determined on the basis of the faulty objects. In this work, object is seen at a higher level of abstraction and is taken as conceptual module that can be plugged in and plugged out from the software system. Reengineering identifies reusable components (objects) and analyzes the changes that would be needed to regenerate them for reuse within new software architecture. The use of a repeatable, clearly defined and well understood software objects, has make reengineering more effective and reduced the cost of reengineering. Maintenance and reengineering will be separated on the basis of faulty objects.\par
The object oriented approach attempts to manage the complexity inherent in the real world problems by abstracting out knowledge and encapsulating it  {\ref [2]}. Object is an instance of a class and has an identity and stores attribute values  {\ref [3]}.\par
All objects of the candidate software system are untied (Reverse engineering). Faulty objects are indentified and modified. Then redesigning of the structure (transformation of the architecture) of the system according to new modern design is done. Then according to new design objects are integrated (Forward Engineering).\par
Abstraction is good tool for reengineering object oriented design as it helps in reducing complexity. Large systems are complex having more objects as each additional object increases the complexity of the system  {\ref [4]}. Reengineering of software system is accomplished by reengineering the faulty objects in the system. Software system is untied, objects are identified for reengineering. Identified objects for reengineering are called faulty objects. Faulty objects are reengineered independently and made Fine objects, software architecture is changed, and all the objects (now all objects are fine) are integrated according to the new architecture.\par
Fine object is an object which conforms to our requirements and functions well in the system. As software ages some objects becomes faulty. Faulty object is an object which does not conform to our requirements and does not function well with in the system. We go on maintaining the faulty objects to maintain the software system. With maintenance of the faulty objects again and again, architecture of the software deteriorates. We reach at a point where reengineering of the system is needed. But what is that point? Let us suppose there are N objects in system which is our candidate system. Let it be O1, O 2 , O 3 ,?????..O N .\par
Go on maintaining the software till half of the objects are not faulty. When half of the objects (N/2) are faulty in your application go for reengineering the software. The reengineering cost of the candidate system with N/2 faulty objects will be one forth (25\%) of the new development cost  {\ref [5]}. This is the optimal cost according to the research paper 'Cost of Reengineering (Object-Oriented Software Systems) versus Developing new One-A Comparison' by the same author. Hence you reach the stage where reengineering starts.\par
When N/2 or more objects are faulty (System with N objects) stop maintenance and reengineer software system. When N/2 objects become faulty; it is a transitional state from maintenance to reengineering. This is vital stage in the software life span for transition from maintenance to reengineering. If the software managers pay no heed to this transitional stage and go V. 
\section[{SUMMARY AND CONCLUSIONS}]{SUMMARY AND CONCLUSIONS}\par
In this piece of work four models are presented for differentiation in maintenance and reengineering as under These models are valuable to software managers for reengineering the software systems at the right time. Reengineering is not feasible before and after the transition state. These models will help to reengineering the software and escape the burden of purchasing costly new software. Software investment expenditure curve will fall in the organizations. There will be full utilization of the software and software backlog will be decreased.\begin{figure}[htbp]
\noindent\textbf{}\includegraphics[]{image-2.png}
\caption{\label{fig_0}}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{}\includegraphics[]{image-3.png}
\caption{\label{fig_1}}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{2}\includegraphics[]{image-4.png}
\caption{\label{fig_2}1. Thoroughfare differentiation model 2 .}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{1} \par 
\begin{longtable}{P{0.85\textwidth}}
Maintenance vs. Reengineering Software Systems\\
2011\\
December\\
62\\
on maintaining with high cost, it means they are\\
overlapping the reengineering zone. It this way, they will\\
strike in a situation when reengineering is not feasible.\\
The cost of reengineering is very much high or equal to\\
the new development. Then they will have to retire the\\
legacy software. It will be financial loss to the\\
organization as more investment on software is needed\\
to purchase new software.\end{longtable} \par
  {\small\itshape [Note: © 2011 Global Journals Inc. (US)]} 
\caption{\label{tab_0}Table 1}\end{figure}
 			\footnote{© 2011 Global Journals Inc. (US) Global Journal of Computer Science and Technology Volume XI Issue XXIII Version I 59 2011 December} 			\footnote{© 2011 Global Journals Inc. (US) Global Journal of Computer Science and Technology Volume XI Issue XXIII Version I 60 2011 December Maintenance vs. Reengineering Software Systems} 			\footnote{© 2011 Global Journals Inc. (US)} 			\footnote{DecemberMaintenance vs. Reengineering Software Systems} 			\footnote{© 2011 Global Journals Inc. (US) Global Journal of Computer Science and Technology Volume XI Issue XXIII Version I 63 2011 December Maintenance vs. Reengineering Software Systems} 			\footnote{© 2011 Global Journals Inc. (US) Global Journal of Computer Science and Technology Volume XI Issue XXIII Version I} 			\footnote{DecemberMaintenance vs. Reengineering Software Systems} 		 		\backmatter   			 \par
In this work three new terms 'Transition state', 'Reengineering Zone' and 'Maintenance Zone' are coined and added to reengineering subject matter. 
\subsection[{VI.}]{VI.} 
\subsection[{FUTURE WORKS TO BE DONE}]{FUTURE WORKS TO BE DONE}\par
These given Models are new in the field of Reengineering of object oriented software systems. The future work is to test these models for suitability to fit on the basis of analysis of current and past data. These models can be accepted as it is or improved or rejected. Once fit and fine these models will help in reengineering the legacy software with optimal cost. This work will be beneficial to the both communities, the software managers and the software engineers. Software managers can order for reengineering at transitional point where maintenance zone ends and reengineering zone starts. 			  			  				\begin{bibitemlist}{1}
\bibitem[Jalote ()]{b17}\label{b17} 	 		\textit{An Integrated Approach to Software Engineering},  		 			P Jalote 		.  		1996. New Delhi: Narosa Publishing House.  	 
\bibitem[Bruegge and Allen ()]{b2}\label{b2} 	 		 			Bernd Bruegge 		,  		 			Dutoit Allen 		,  		 			H 		.  		\textit{Object-Oriented Software Engineering Using UML, Patterns, and Java},  				 (Singapore)  		2004. Pearson Education. p. 724.  	 
\bibitem[Bakhshish Singh]{b4}\label{b4} 	 		\textit{Cost of Reengineering (Object-Oriented Software Systems) versus Developing new One-A Comparison' Research paper},  		 			Gill Bakhshish Singh 		.  		New Delhi: Serials Publication. p. .  	 
\bibitem[Brock et al. ()]{b1}\label{b1} 	 		\textit{Designing Object-Oriented Software},  		 			R W Brock 		,  		 			B Wilkerson 		,  		 			L Wiener 		.  		2007. New Delhi: Prentice-Hall of India. p. 5.  	 
\bibitem[Gill Nasib and Singh ()]{b16}\label{b16} 	 		 			Gill Nasib 		,  		 			Singh 		.  		\textit{Software Engineering: software reliability, Testing and Quality Assurance},  				 (New Delhi)  		2002. Khanna Book Publishing Co.(P) Ltd.  	 
\bibitem[IEEE Standards Software Engineering ()]{b9}\label{b9} 	 		 IEEE Std 1219-1998.  	 	 		\textit{IEEE Standards Software Engineering},  				1999. IEEE Press. Two.  	 	 (Process Standards) 
\bibitem[Erlikh (200)]{b0}\label{b0} 	 		\textit{Leveraging legacy system dollars for Ebusiness},  		 			L Erlikh 		.  		 \url{http://users.jyu.fi/\textasciitilde koskinen/smcosts.htm}  		200. p. .  	 	 (IEEE) IT Pro. Retrieved 24-02-2011 from) 
\bibitem[Aggarwal and Singh ()]{b15}\label{b15} 	 		\textit{New age International},  		 			K K Aggarwal 		,  		 			Yogesh Singh 		.  		2002. New Delhi: P) Ltd., Publishers.  	 	 (Software engineering) 
\bibitem[Booch ()]{b13}\label{b13} 	 		\textit{Object Oriented Analysis and Design with Applications},  		 			Grady Booch 		.  		2003. Singapore: Pearson Education.  	 
\bibitem[Halladay and Wiebel]{b3}\label{b3} 	 		\textit{Object-Oriented Software Engineering},  		 			S Halladay 		,  		 			M Wiebel 		.  		New Delhi: BPB Publications. p. 35.  	 
\bibitem[Chikofsky and Cross (1990)]{b8}\label{b8} 	 		‘Reverse Engineering and Design Recovery: A Taxonomy’.  		 			E Chikofsky 		,  		 			J H Cross 		.  	 	 		\textit{IEEE Software Engineering journal}  		Jan. 1990. p. .  	 
\bibitem[Pressman ()]{b12}\label{b12} 	 		\textit{Software engineering},  		 			Roger S Pressman 		.  		1992. New York: McGraw-Hill.  	 	 (3 rd ed.) 
\bibitem[Ian Sommerville ()]{b14}\label{b14} 	 		\textit{Software Engineering},  		 			Ian Sommerville 		.  		1994. Singapore: Addison-Wesley Publishing Company.  	 
\bibitem[Lientz and Swanson ()]{b7}\label{b7} 	 		\textit{Software Maintenance Management},  		 			Lientz 		,  		 			E Swanson 		.  		1980. Addison-Wesley.  	 
\bibitem[Arnold ()]{b5}\label{b5} 	 		\textit{Software Reengineering},  		 			Robert S Arnold 		.  		1993. Alamitos, California: IEEE Computer Society Press Los. p. 60.  	 
\bibitem[Arnold ()]{b11}\label{b11} 	 		\textit{Software Reengineering},  		 			Robert S Arnold 		.  		1994. Los Alamitos, California: IEEE Computer Society Press.  	 
\bibitem[Standard Glossary of Software Engineering Terminology ()]{b6}\label{b6} 	 		\textit{Standard Glossary of Software Engineering Terminology},  		 IEEE Std. 610.12.  		1990. Los Alamitos, CA: IEEE Computer Society Press.  	 
\bibitem[Valenti ()]{b10}\label{b10} 	 		\textit{Successful Software Reengineering},  		 			Sal Valenti 		.  		2002. 1331 E., Chocolate Avenue, Hershey: IRM Press.  	 
\end{bibitemlist}
 			 		 	 
\end{document}
