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:

Could we have done any better at planning?

Could we have done any better at committing dates?

Did we compromise quality of code to meet deadlines?

Did we implement RUP (in it's true sprit) to at least try and
ensure that the software developed stands with confidence like the
building standing tall and straight?

Was documentation too much and was it done just for the sake of
doing it?

Was there too much pressure on developers to code @ a rate they
are not comfortable coding at?

Did they have a fair voice in raising problems that might occur or
quality depletion that might take place if they code @ that rate.

And Most importantly, Did all participants enjoy working on the
project and will they like to support / enhance the project in future?

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.