In an earlier job I was doing sys support for unix.
I was trying to shutdown a terminal machine so I could move it but inadvertanty typed the shutdown command into a window I had open on the main production server. I was assured that everyone does that at least once:-)
One of the managers was particulally dark at me coz they lost 3 hours of editing on a document. My response was "Don't you save it every ten minutes?" (as people who use Word do)
Their fault really for employing a windows programmer to to unix sys support.:-)
I remember drawing my schools plans and using them for an old style AD&D dungeon bash. (real paper and everything)
Surely this is tantemount to the same thing.
I also remember creating a map for doom using my house (with a cyber deamon in the toilet:-))
I feel sorry for this poor bugger, smart enough to use a map editer and punished for it.
In my last semester we did 2 units like this Minor Project and Major Project
Minor project was working solo on a program that you wanted. Basically you came up with the idea, Ok'ed it with the lecturer then designed and implememted.
Major project was a small (3-4) team project and the college actually organised for us to go and talk to local businesses about something that they needed.
I think these were both great especially the major project because of the outside involvement.
Things I think should be assessed/achieved as part of this kind of unit.
1. Reqirements gathering. Check how thourough they have been bonus marks for spotting and identifying problem areas. 2. Design. How well does the design cover the requirements that have been identified 3. Implementation. Appropriate choice of tool, Architecture 4. User Acceptance. Get the user to validate the software.
If you wanted to you could get the teams to act as the users for another team. Ie get them to think up an idea for someone else to do. Also if you wanted you could also add QA to the mix you could get teams to test each others work.
One problem we had was that the slow kids tended to drag the rest of the team down. All marks need to be scaled by the lecturer to allow for this.
Nothing helps me more when I'm analysing a complex business workflow than a UML Sequence diagram.
Not Sure about object lifetimes? Draw yourself an UML Activity Diagram it will all become clear.
And god knows I'm glad I drew up the UML Sequence diagrams and Class diagrams after the last product release when I get asked to update it 6 months later. A picture is worth a thousand words of spec and analysis.
I recently read "About Face 2.0" I found myself dis-agreeing with some of the details and felt there were a few ommisions but the definitions of software was sound
Also Joel on software has a great book excerpt online to get you in the mood
Slashdot Mirror
In an earlier job I was doing sys support for unix.
:-)
:-)
I was trying to shutdown a terminal machine so I could move it but inadvertanty typed the shutdown command into a window I had open on the main production server. I was assured that everyone does that at least once
One of the managers was particulally dark at me coz they lost 3 hours of editing on a document. My response was "Don't you save it every ten minutes?" (as people who use Word do)
Their fault really for employing a windows programmer to to unix sys support.
I remember drawing my schools plans and using them for an old style AD&D dungeon bash. (real paper and everything) Surely this is tantemount to the same thing. I also remember creating a map for doom using my house (with a cyber deamon in the toilet :-))
I feel sorry for this poor bugger, smart enough to use a map editer and punished for it.
The old coin-op game
:-(
There was one jump near the end (I assume it was, because you had already bought everthing from the shop) that was impossible.
My guess was that you needed an 8-way joystick to do a diagonal jump, but it was only ever installed on 4-way boxes
also I never finished Doom 2 unless I activated the bug that made all of the monsters spawn in the wall in the final level
In my last semester we did 2 units like this Minor Project and Major Project
Minor project was working solo on a program that you wanted. Basically you came up with the idea, Ok'ed it with the lecturer then designed and implememted.
Major project was a small (3-4) team project and the college actually organised for us to go and talk to local businesses about something that they needed.
I think these were both great especially the major project because of the outside involvement.
Things I think should be assessed/achieved as part of this kind of unit.
1. Reqirements gathering. Check how thourough they have been bonus marks for spotting and identifying problem areas.
2. Design. How well does the design cover the requirements that have been identified
3. Implementation. Appropriate choice of tool, Architecture
4. User Acceptance. Get the user to validate the software.
If you wanted to you could get the teams to act as the users for another team. Ie get them to think up an idea for someone else to do. Also if you wanted you could also add QA to the mix you could get teams to test each others work.
One problem we had was that the slow kids tended to drag the rest of the team down. All marks need to be scaled by the lecturer to allow for this.
Not Sure about object lifetimes? Draw yourself an UML Activity Diagram it will all become clear.
And god knows I'm glad I drew up the UML Sequence diagrams and Class diagrams after the last product release when I get asked to update it 6 months later. A picture is worth a thousand words of spec and analysis.
(Use cases "diagrams" are a waste of time though)
I recently read "About Face 2.0" I found myself dis-agreeing with some of the details and felt there were a few ommisions but the definitions of software was sound
Also Joel on software has a great book excerpt online to get you in the mood
About face link
Joel book excerpt