Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!cis.ohio-state.edu!tut.cis.ohio-state.edu!udecc.engr.udayton.edu!blackbird.afit.af.mil!jcardow
From: jcardow@afit.af.mil (James E. Cardow)
Newsgroups: comp.software-eng
Subject: Re: Modifiability
Message-ID: <1991Jun07.155235.10984@afit.af.mil>
Date: 7 Jun 91 15:52:35 GMT
References: <2192@Terra.cc.brunel.ac.uk> <1991Jun5.201807.13286@netcom.COM>
Distribution: comp.software-eng
Organization: Air Force Institute of Technology
Lines: 58

jls@netcom.COM (Jim Showalter) writes:

>>I would like to initiate a discussion on maintainability! 
>>there are two main positions that people (and literature) take on how to 
>>produce miantainable (and modifiable) software:
>>	- Adopting a software development method and making sure that the
>>	documentation is up to date will insure that the software will
>>	be highly modifiable.

>If one adopts a software development method that is worth anything, then
>one should wind up, as a consequence, with software that is maintainable
>and modifiable. Another way to put this is that one of the criteria for
>selecting a software development method is that the method, properly
>applied, should result in software that is maintainable and modifiable.

>The question then becomes: are there software development methods that
>result in maintainable and modifiable software and, if so, what are
>they? This question, I answer with a resounding yes: a method that stresses
>architecture and design, rapid prototyping, iterative development, incremental
>delivery of functionality and documentation, abstraction, and all the other
>stuff that has been discussed in this group is such a method. I've seen
>such a method followed in real life on real projects of significant scope
>and complexity, and I've seen highly maintainable and modifiable software
>result from it.
>-- 

First off, I'm not willing to accept that this is not maintenance, I believe
this is properly preparing for maintenance (corrective and enhancement).
Second, part of the problem is "all the other stuff."  There are many things
out there that will result in *some aspect* of a more maintainable system, but
what does the compination or net effect cause.  Can I make a selection of 
these methods and still keep the quality?

I have heard about the software process and process modeling for several years.
And, to be honest, considered it to be one more be-all solution to the software
problem.  At first, I thought it was hype.  Then I saw some benefit in that it
provided a way to improve business by structure.  Then I saw it as a way to 
smartly include some things that made sense (SQA, CM, etc).  Now I realize that
it isn't a solution at all, but a good way to address that problem.  A good way
to address that problem in that I am faced with a score of solutions to each
day-to-day occurance.  Many of the solutions solving their own intended 
problem, but at the expense of many new problems.  What a process does is 
generate a framework to explore solutions in, that keeps all the pieces in a 
bundle.  So, when I look at issues like maintainability (primarily, understand-
abilit) I can look at all aspects of the process and what effect new technologies
will have.

I think a more beneficial approach to the discussion might be WHAT is Understand-ability

Or how do I guage Maintainability?

Looking forward to the discussion.

	Jim Cardow, Capt, USAF
	Air Force Institute of Technology
	Instructor in Software Engineering
	Professional Continuing Education Program
		E-mail:  jcardow@blackbird.afit.af.mil