"RUPitUP!" |
||
'basically' a completely blurred Vision! |
||
RUPitUP! is a blurred vision that has started with a
fixed set of "not to do's" of Software Development. The past 3+ years of
software design and development have been awesome and have been a
tremendously rewarding experience! Mistakes have been made and thanks to
god, a lot has been learnt. As a developer however it has been a heart
breaking experience to see a software project and the construction of a
building starting in the same month - a year later the building is
standing tall and straight - but the software? Well, that's something
any developer will be able to answer... if he's not too busy in fixing
(hiding?) bugs! Turns out, transition of most projects is a nightmare
for all parties involved! Any guesses why?
Thanks to god again, i've had a chance to witness projects that fail, projects that barely scrap through and projects that are successful. After the lessons learnt session of my last project (which thanks to god met the acceptance levels) i kept thinking about a few things:
|
||
That's how software is developed! |
||
The argument seems exiting and could go on forever but
RUPitUP starts on the basic concept that every participant likes the
planned approach to software / project development. A typical
example to give here is excel sheets that are often exchanged between
development and QA teams - at some point of time we as engineers of a
domain that has evolved rapidly start believing that this is how
software is developed! However, exchange of bug reports in excel sheets is not because
participants don't like filing bugs on the bug tracking system - it's
because their bug tracking system doesn't allow them to file bugs which
are sure to get fixed without exposing them to the client.
"Your window of 'y' screen doesn't close when you click the close button." - "Oops i missed implementing the close functionality in the code. thanks!" - Well, the QA team and developers want to avoid these conversations in the bug tracking system which the client has access to - mainly because, well, it's embarrassing! As long as the bug is resolved they are ok with that! so, they end up exchanging excel sheets and breaking up the process completely! |
|
|
So How Does RUPitUP come in? |
||
There needs to be a 'practical' approach to RUP and other processes. It should support process guidelines. in fact, these should be built into the system. Of course, the idea is not to re-invent Rational Rose or Microsoft Project (or the wheel:) ). The idea however, is to bridge gaps and bring tools under one roof! A Document repository that has an option of creating RUP sections by default and sample documentation, A bug tracking system that give internal interface where developers / QA team members can exchange and track bugs without having to involve the client in insignificant details, A Request Tracking System where a developer can advice the PM that the request being asked for by the client will take 'y' man days over and above his work - anything under that will effect his quality of code! To cut a long story short - this is an attempt to make software development fun for everyone involved! | ||
How much of RUPitUP is already complete? |
||
The project is pretty much in it's pre-inception stage where we're trying to freeze on technologies we plan to use. The detail design document (nothing too elaborate / expensive) will be written by the end of January. Technologies will be identified by then. POCs of each technologies identified will be developed and will be hosted in the CVS by the end of January. Substantial Reading / Training material will be developed - so that new developers can read, learn and hop in anytime they want. | ||