• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Use Case Preparation.

 
Ranch Hand
Posts: 1228
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I need to prepare Use cases from a Cobol module for a migration project. I'm a novice in this. Can any one point me to a good Site to learn much better on this. In between i'm also googling for this.
 
Ranch Hand
Posts: 1704
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Try the following link:

http://www.google.com/search?hl=en&q=use+case+preparation+guide&btnG=Google+Search
 
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
This sounds more like a process question - moving...
 
author
Posts: 608
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
You need to have a handle on the challenges involved with legacy analysis. Agile Legacy Integration Modeling and Contract Models may be of interest.

One danger that you might run into is the desire to put all of the migration information into the use cases. Use cases are very good at capturing usage information, they're not so good at capturing legacy analysis information. Use the right technique for the job. See Agile Models Distilled for options.

- Scott
 
Ranch Hand
Posts: 84
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
If you need to document the detailed behaviour of the module for each use case, then it sounds like you are basically reverse engineering the requirements out of the existing Cobol module. If that's the case, don't worry too much about the effort involved in "writing use cases" or any other technique like it. *Most* of your time will be spent carefully reading through and understanding exactly what the Cobol module does. In situations like this, I find it useful to trace paths of execution through the module, on paper, and make careful notes as I go. Once you have a detailed understanding of the module, generating documentation (like use cases) is the easy part.

For more on use cases, take a look at "Writing Effective Use Cases" by Alistair Cockburn. You may also benefit from some the more general advice on requirements from Wieger's book "Software Requirements", such as the importance of having some understanding of the domain you are working in (although much of Wieger's book is geared more towards gathering requirements from the business side more so than from existing implementations).

By the way, you may also want to google "code spelunking", the cool sounding name researchers use to refer to the activity of gaining an understanding of an existing code base.
 
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
If you have a user manual for the legacy system you can mine that for use cases.

How strongly are you wed to use cases? We have found textual use cases (and Rational's ReqPro database) a poor medium for recording some requirements and rules. Plain old spreadsheets are sometimes much better. If you see some requirements that look good in tables, take a serious look at Fitnesse. Expressing requirements in executable tests is way cool.
 
Don Morgan
Ranch Hand
Posts: 84
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
A user manual is a good source, but I have seen things go awry when outdated manuals are blindly referenced. Looking at the source code, or actually executing a use case on the system, is really the ultimate reference. This is one of the clear benefits of migration projects. If you are unsure of how something should be handled, you can usually just try it out on the legacy system and see what happens.

I do agree on using spreadsheets to help manage requirements, sometimes this can work well.

I have two questions:

1.) Are you doing a lot of analysis and redesign when porting the module from Cobol to Java or is it pretty much a straight port and just getting the behaviour right?
2.) It seems to me that in a "straight port" project, the work which needs to be done is quite well defined; the existence of the original system and source code provide a definitive reference. Therefore, providing you are not also making changes, either defect fixes or enhancements, at the same time you are porting the code, it seems to me this type of migration project may be one type of project where there is less value to the Agile ideas like "embrace change" (requirements are fixed), or there may be less of a need for user involvement compared to green field development (since detailed behaviour can be determined from analyzing the existing system). Does anyone else have some actual experience running a project like this following an Agile process?
[ February 20, 2006: Message edited by: Don Morgan ]
 
Srinivasa Raghavan
Ranch Hand
Posts: 1228
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Stan James , Don & Scott Tanks for the reply.

Don, It's going to be a straight port project, no enhancements , no bug fixes , just re-engineer the project to java. I'm now going through, Agile Legacy Integration Modeling pointed out by Scott. I'll keep posted when i'm in trouble
 
Srinivasa Raghavan
Ranch Hand
Posts: 1228
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Ilja, I'm Sorry for posting this in wrong forum. Thanks for moving here.
 
Ranch Hand
Posts: 1491
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Srinivas Raghavan, Are you doing use case anlysis alone or doing migrate the code from cobol to java ? Because some of the porting tools( from cobol to java) are in the market. i never tried those tools.
 
Srinivasa Raghavan
Ranch Hand
Posts: 1228
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Krishan, I'm just preparing the use cases.
 
Stan James
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

A user manual is a good source, but I have seen things go awry when outdated manuals are blindly referenced.



Good catch! I've been burned by that.

Don, It's going to be a straight port project, no enhancements , no bug fixes , just re-engineer the project to java.



Loud alarms going off! I've been burned and then buried by that. "The existing system is the spec" rapidly turned into requests for minor and major enhancements. Copying old bugs into a new system and deliberately ignoring opportunites in the platform change are not very good ideas (we did that, too!) so you really should think about how to manage some amount of improvement as you go.

Don't jump off a bridge or anything drastic just yet. But keep an eye on this thing so it doesn't run you over.
 
Don Morgan
Ranch Hand
Posts: 84
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Managing enhancements and bug fixes during a migration project is a large area of risk (like Stan pointed out). Here are some things to think about, in case things start "slipping in."

1. Modifying an existing system, say to fix a defect, has *roughly* a 30% change of introducing a defect (this is the most recent stat I remember seeing, but I don't have the reference for it). A defect you know, especially if there is a work around for dealing with its consequences, may be better than a new problem.

2. Will you make defects/enhancements to the new AND old system OR just the new system? Applying the change to both systems may be extra work, but helps to ensure the defect/enhancement actually works with the real production system. Also, if the migration project falls behind schedule(not that software projects ever suffer schedule slip...), or if something goes wrong when the java system is put into production and a rollback is required, then at least the new functionality would exist in the old system. For things like a regulatory requirement change with a fixed date, you may have no choice other than to implement in both systems, depending upon how their timelines work out. It is important to keep in mind these systems serve a business purpose, and, at least in the short term, keeping their functionality correct can outweigh reasons for switching to new technology.

3. Pay close attention to configuration management, to make sure when you do the cutover all the required functionality has been put into the new system, including whatever defects/enhancements slipped in.

By the way, another advantage about migration projects is that having a second system can make testing a little easier. For example, you can automate things like: 1.) create a generic test data file to drive testing scripts; 2.) write drivers which read the test file, and run it through the legacy system in your test environment; 3.) copy out the database tables; 4.) write drivers which read the test file and run it through the new system; 5.) copy out the db tables and compare with results of step #3. This is not foolproof, and there are complications with comparing dates and any uniquely generated numbers, but something like this can help with testing.
 
Scott Ambler
author
Posts: 608
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Here's something that should blow your minds: How do you even know that it's a good idea to do the migration. According to the Chaos Report, a large percentage of the delivered functionality isn't used, see Examining the Big Requirements Up Front (BRUF) Approach.

So, if you believe the figures, you wasted your time building it originally, now you're going to do the same thing again if you just blindly rebuild the old functionality.

- Scott
 
Stan James
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

So, if you believe the figures, you wasted your time building it originally, now you're going to do the same thing again if you just blindly rebuild the old functionality.



Yeah, I have the T-Shirt from that trip, too. As you extract requirements from the old system, make the customer put them in business priority order. If you just do all of screen A, then all of screen B and so on you are guaranteed to hit this problem, too.

We're getting a pretty big list of speed-bumps. Are you really worried yet?
 
Don't get me started about those stupid light bulbs.
reply
    Bookmark Topic Watch Topic
  • New Topic