Herryandi wrote:
>
> Why we use SSADM in a project, what type of project that suited with
> SSADM and what type of project that not suited with SSADM.

SSADM is a functional decomposition methodology intended
for use with older languages like Fortran and COBOL.

The problem with functional decomposition (both languages
and methodologies) is high cost of maintenance. As much as
80% of the total cost of software is accrued during the
maintenance phase. Functional decomposed software is
generally expensive to maintain because they use global
data, which creates a spiderweb (or spaghetti web) of
data interdependencies among the subroutines. Thus when
a change is made to one part of a program, it often affects
many other parts of the program, sometimes in non-obvious
ways that are hard to find and fix. This is a big reason
why software maintenance is expensive.

A solution to this was found in the '70s and early '80s.
A technique variously called "information hiding" or
"data encapsulation" eliminates global data that is
the source of many maintenance problems. Instead, all
data is buried, or "encapsulated," inside modules. Each
module is basically a semi-autonomous block of
subroutines with its own local data store. Only the
subroutines of the module can access the module's data
store. Other modules cannot get to the data directly,
but must make a call to the module subroutines to
fetch or store data values in the module data store.

One other very important thing is that the subroutines of
a module must be designed so that their calling syntax
is "stable," meaning the way the module subroutines are
called will _not_ change if the the data store or
algorithms of the module itself ever need to change.
This "stable interface" (unchanging subroutine calling
protocol) prevents other modules that call the module
subroutines from having to change if the module itself
ever changes, because the callers only see the stable
(unchanging) interface to the module. They do not see
"inside" the module where the changes happen. This
eliminates most of the expensive kinds of problems
where a change in one place mysteriously affects other
parts of the program.

Designing the subroutine calling protocols so that
they will not change if module data or algorithms
change is not easy, but requires more careful design.
However, it was found that making the modules represent
"things" or "objects" in the solution space of the
software, rather than functions to be performed, was
helpful in designing interfaces that were more resistant
to change. This kind of design was already being done
in the simulation community, where groups of subroutines
were being used to simulate things such as parts of
aircraft or whatever. So some of the simulation ideas
were borrowed and used to supplement the data encapsulation
idea, and object-oriented programming, or OO, was the
result.

OO does not decompose software into functions (actions)
and subroutines. Instead, it decomposes the program into
objects (nouns) modeled by modules, where modules are
semi-autonomous collections of subroutines with their
own private data store. OO programs have no global data,
because global data is the source of many expensive
maintenance problems.

When an OO program is designed and implemented properly
(and many are not!), it is much easier and less expensive
to maintain than a traditional functional program would
have been. The 80% of cost due to maintenance is greatly
reduced. That is why nearly all new programs should use
OO and not functional decomposition (but the OO has to be
done correctly or there is not much benefit.)

Because OO programs decompose totally different than
functional programs, new methodologies are needed. SSADM
and other functional methodologies are not valid for OO.

Also, new languages were developed to support OO concepts.
Roughly in historical order, these were Smalltalk, Ada,
C++, and Java. The newest of these OO languages, Java,
is good enough were it has effectively replaced COBOL for
most new business programming. (Of course, COBOL and
Fortran will both be around for a long time because of
all the legacy code.)

OO methodologies are lagging behind OO languages. While
Java has become the standard OO language for business,
there is no standard OO methodology. The leading company
in the field is Rational, which was bought by IBM recently.
Rational has the Rational Unified Process (RUP), but it
is not really a methodology. Rather it is more like a set
of for-sale tools which can be used together in different
combinations, making it necessary to create your own OO
methodology. It is almost as if Rational could not decide
on a good OO methodology, and so left it up to the users
to build their own, but do it in a way that works with the
tools Rational sells (of course!) For more information
on RUP see http://www-3.ibm.com/software/awdtools/rup/

The best OO methodology I know of, and so the one I use,
was developed for NASA over 10 years ago. Unlike RUP,
it is a real methodology that should work well on most any
OO project without having to create new customizations for
each project. It also does not require expensive for-sale
tools; simple tools like text editors and spreadsheets are
quite adequate for creating the requirements and design
notations. I found this methodology to be so effective that
I asked NASA if they could release it to the public under
their tech transfer program, and they recently agreed. I
am now in the process of documenting it on my web site.
It is called 'Freedom' after the space station project
that funded its creation. For more info on Freedom see
http://www.jreality.com/freedom

--
Rick Lutowski
Principal, JReality
rick@...
http://www.jreality.com