Re: To CASE or not to CASE

From: Richard D Holowczak <holowcza_at_andromeda.rutgers.edu>
Date: 10 Apr 94 21:33:20 GMT
Message-ID: <Apr.10.17.33.20.1994.7249_at_andromeda.rutgers.edu>


nickt_at_ewd.dsto.gov.au (Nick Taransky) writes:

>I am seeking advice on whether to pursue a CASE or non-CASE solution for a
>proposed database design project soon to be undertaken at my place of
>employment.
 

>ORACLE (V7) has been purchased and relevant training is being organised for
>the proposed development team of four staff. These staff will be each
>working on the project part time (10%-40% of work time each until
>completion). All staff in the team have knowledge of basic db design issues

     What is nice about case, if done correctly, is that you have
     very good documentation at all stages of the project so 
     as people "peel off" for a bit and then come back, it
     should not be much of a problem to get them updated with
     and changes.

>from University courses etc, but none have taken part in such a project before.
 

>The database will be used to test algorithms/software being developed to
>process the information stored in it. In the future it may be developed into

     If you are planning to use SQL*Forms as the interface, then
     CASE Generator would help you out quite a bit here.  It sounds
     as if you are going to be creating custom (non-FOrms) apps to run 
     against an Oracle DB so perhaps Oracle CASE would only be used
     for Analysis and Design of the database.

>an externally available package. ORACLE has been purchased for the sole
>purpose of this single application and while extensions may be made to it in
>the future, it is not expected to be a highly dynamic system. There is not a
>fixed deadline for completion of the project but prospective users and
>management would obviously like to see results sooner rather than later.
 

>The two schools of thought here regarding CASE (excluding financial issues)
>are:
 

>1) Use CASE as it will help the inexperienced team produce a usable DB in a
>shorter amount of time.

      This is the school of thought that almost killed CASE (in general)
      in the 1980's.   Just to repeat the blatantly obvious: CASE,
      no matter which vendor's, will not turn your IS staff into
      relational database design mavens.  I understand your people
      have some formal relational instruction, but without hands
      on design experience where you have to sit and "live" with
      your design decisions (sometimes as users are preparing to
      burn you at the stake :), the CASE tools would do little
      more than allow them to make a bad database more quickly.

      As mentioned before, this is not so much a reflection of
      Oracle's CASE.  It is true of all CASE tools on the
      market.


>2) Don't use CASE as the manual work will give the team a better
>understanding of underlying design/development skills.

         I think this is the way to go.  Let these guys roll
         up their sleeves and get real dirty doing it by hand.
         When the CASE tools come at some future project, they'll
         really put it to good use.

>Has anyone out there had experiences that could help us make the correct
>choice. Any advice would be greatly appreciated.

Rich Holowczak
Rutgers University
holowcza_at_andromeda.rutgers.edu Received on Sun Apr 10 1994 - 23:33:20 CEST

Original text of this message