aspose file tools*
The moose likes Agile and Other Processes and the fly likes Use Case Preparation. Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » Agile and Other Processes
Bookmark "Use Case Preparation." Watch "Use Case Preparation." New topic
Author

Use Case Preparation.

Srinivasa Raghavan
Ranch Hand

Joined: Sep 28, 2004
Posts: 1228
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.


Thanks & regards, Srini
MCP, SCJP-1.4, NCFM (Financial Markets), Oracle 9i - SQL ( 1Z0-007 ), ITIL Certified
Kj Reddy
Ranch Hand

Joined: Sep 20, 2003
Posts: 1704
Try the following link:

http://www.google.com/search?hl=en&q=use+case+preparation+guide&btnG=Google+Search
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
This sounds more like a process question - moving...


The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Scott Ambler
author
Ranch Hand

Joined: Dec 12, 2003
Posts: 608
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


<a href="http://www-306.ibm.com/software/rational/bios/ambler.html" target="_blank" rel="nofollow">Scott W. Ambler</a><br />Practice Leader Agile Development, IBM Rational<br /> <br />Now available: <a href="http://www.ambysoft.com/books/refactoringDatabases.html" target="_blank" rel="nofollow">Refactoring Databases: Evolutionary Database Design</a>
Don Morgan
Ranch Hand

Joined: Jul 24, 2003
Posts: 84
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.


Don Morgan, Founder
www.DeveloperAdvantage.com - FREE Audiobooks for Software Developers
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
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.


A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Don Morgan
Ranch Hand

Joined: Jul 24, 2003
Posts: 84
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

Joined: Sep 28, 2004
Posts: 1228
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

Joined: Sep 28, 2004
Posts: 1228
Ilja, I'm Sorry for posting this in wrong forum. Thanks for moving here.
kri shan
Ranch Hand

Joined: Apr 08, 2004
Posts: 1373
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

Joined: Sep 28, 2004
Posts: 1228
Krishan, I'm just preparing the use cases.
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
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

Joined: Jul 24, 2003
Posts: 84
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
Ranch Hand

Joined: Dec 12, 2003
Posts: 608
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)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
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?
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Use Case Preparation.