http://www.scs.carleton.ca/~courses/304 * ''(BrokenLink 2006-01-12)'' 95.304 of CarletonUniversity's computer science department. Purports to teach how to program large scale systems currently using RationalRoseRealTime and the UnifiedModelingLanguage. Previously it was taught using ObjectTimeDeveloper 5.2. Previously on this page was a public journal of one team. The journal has been deleted halfway through the course, at the beginning of the second and last iteration, for unspecified reasons. According to many different teams in the Fall 2001 semester, this course requires at least 400 hours of work per team, spent in the crowded, uncomfortable Carleton SCS labs. Even a small model developed in RationalRoseRealTime seems to turn into a CrystalBicycle See also: * RationalRose * ScenarioTextualDescriptions * ScenarioCluster * CritiqueOfUseCases * UseCaseMap * MessageSequenceChart * CrcCard''''''s * NoKeening ---- The only advice I have for those people taking this class or those like it is ''never listen to the professor.'' That should be a big '''duh''', as you can't afford an 18 month project cycle, but oddly some people actually attempt to WaterFall themselves in only four months. I don't like the 95% failure rate of WaterFall, so instead we did the documentation ''last'' and the code ''first.'' I heard that our team's documentation is actually being used as one of the examples. No, it is! See * http://www.scs.carleton.ca/~courses/304/projectReports/ATM2.doc ** ''(BrokenLink 2006-01-12)'' For what it's worth, our interim doc got 75% because we did it the ROOM way. The final doc got 95% because we just gave up, coded it, and then documented it at the end. There just isn't enough time to maintain the documentation and the code. Dr. Bordeleau and I had a large disagreement over that. Feel free to ignore my opinion, but I saw so many teams twist and die taking this course because they sat around the use cases arguing for weeks without getting anything done. Those were the groups who at the last minute had to write the code ''and'' change the documentation to match. We also "cheated" and put most of the logic into the Java GUI and very little (<30 states) in ObjectTimeDeveloper. Cheated insomuch as that was the obviously right architecture. WikiAddict''''''s will also notice the CrcCard''''''s in Chapter 10. That was the first time I'd have ever played with them. Fun stuff. Ok, enough arrogance for one day. It's fun to brag, but the course is still brutal. It has ended many friendships in the past. -- SunirShah Ahh, my mistake, I was under the impression that ATM2.doc was the second iteration of ATM1.doc... sorry=) This year we had to implement a multi-terminal Blackjack system, with a simpler ATM built in so you could play with 'real' money. For all the work we did we could have had something much more useful than a semi-working BlackJack system. Oh well, after that course, I'm ready to read up on XP. Anyways, I didn't attend that course much, it was just too boring (I say that about almost all my courses). I'm glad it's over, there were plenty of screaming matches over design decisions, and they eventually got changed anyways. I don't think Dr. Bordeleau has marked my exam yet, so I guess I should be careful what I say ;) Oh, BTW our midterm was open book, and I took a copy of your document along, it helped a lot! -- RyanDoupe ---- CategoryCodingConventions