Final Year Software Project

[ITrishGuru]

Hi all,
I'm doing my FYP using csharp and MS Outlook to develope a plugin app.
My question isn't about programming as such, Its more about project
managment.
Does anybody have a good URL that could inform me on how to appraoch a
software development project?
There are two of us on the project, we are not computer science
students but Arts students who took IT as a joint degree along with
psychology.

I think the pure BSc IT class get lecturers in software project
development, we didn't!
This is not a grip though, its just my current context.

Any help would be welcome!!
Thanks in advance,
Kevin.

 

[Liz]

Hi all,
I'm doing my FYP using csharp and MS Outlook to develope a plugin app.
My question isn't about programming as such, Its more about project
managment.
Does anybody have a good URL that could inform me on how to appraoch a
software development project?

this is a pretty wild question; start here:

http://en.wikipedia.org/wiki/Project_management

http://en.wikipedia.org/wiki/Rational_Unified_Process

good luck; you're going to need it ....

 

[ITrishGuru]

this is a pretty wild question; start here:

http://en.wikipedia.org/wiki/Project_management

http://en.wikipedia.org/wiki/Rational_Unified_Process

good luck; you're going to need it ....






- Show quoted text -

Thanks I like the 2nd URL

 

[Liz]

Thanks I like the 2nd URL

it's all kind of intuitive, common-sense stuff ... boring ... but it has its
fans ....

 

[Ian Semmel]

-----Original Message-----
From: Liz [mailto:[email protected]]
Posted At: Sunday, 16 December 2007 12:40 PM
Posted To: microsoft.public.dotnet.languages.csharp
Conversation: Final Year Software Project
Subject: Re: Final Year Software Project


(e-mail address removed)...

Thanks I like the 2nd URL

it's all kind of intuitive, common-sense stuff ... boring ... but it
has its
fans ....

I'll vote for the boring bit. It's probably OK, but I got bpred after
reading about one third of it.

Back in the olden days, there used to be the phrase "Super-programmer or
the Mongolian Hordes" when debating various project development
strategies.

I have always tended to the first approach (to a degree). Non-IT
management often think that the solution to a project which is behind
schedule is to throw more resources, ie programmers, at it, little
realising that they are making things worse.

My basic strategies are :
1. The project should be controlled by a god who makes the rules and
keeps the lid on programmers' egos.
2. A programming team should not exceed 10 people. If it requires more
it needs to be modularised.
3. Good programmers are better than bad programmers.
4. A project takes as long as it takes.

 

[christery]

For a it project approach u can go in different ways, u already got
the tip about RUP (before u read through half of the dok, yoll fall to
sleep and newer wake again), the simple and not used (other than in
school) waterfall model.

Why not look at Prototyping , Agile, XP (not M$ windows, but Extreame
Programming)... google and u will find... nice for scool proj, and
they are nice for 2 programmers, 2 wills with one computer and one
program... but go light on the testing phase on that (agile wants
rigorus testing, automated) - otherwise you get stuck in describing
and writing code for test that this project dosent need, if its not to
be continued.

Just my thoughts. Maybe go with the God solution above, but why do God
need programmers.. Ohh, got it.. as someone said: anyone can make a
misstake but to really f*k it up you need a computer.

//CY

 

[Family Tree Mike]

Hi all,
I'm doing my FYP using csharp and MS Outlook to develope a plugin app.
My question isn't about programming as such, Its more about project
managment.
Does anybody have a good URL that could inform me on how to appraoch a
software development project?
There are two of us on the project, we are not computer science
students but Arts students who took IT as a joint degree along with
psychology.

I think the pure BSc IT class get lecturers in software project
development, we didn't!
This is not a grip though, its just my current context.

Any help would be welcome!!
Thanks in advance,
Kevin.

The other discussion that is going on is well and and good. For just two
people on a project such as this, I think it is simple enough to itemize
targets, define components, divide the components amongst the two of you and
set estimated dates for these items. Divide the components so that they may
be independently developed and tested, and that one of the two of you is not
consistently waiting for the other to finish a component version.

 

[ITrishGuru]

The other discussion that is going on is well and and good. For just two
people on a project such as this, I think it is simple enough to itemize
targets, define components, divide the components amongst the two of you and
set estimated dates for these items. Divide the components so that they may
be independently developed and tested, and that one of the two of you is not
consistently waiting for the other to finish a component version.- Hide quoted text -

- Show quoted text -

Great replys, thanks people.
I'm soaking all this up.

 

[Liz]

Non-IT
management often think that the solution to a project which is behind
schedule is to throw more resources, ie programmers, at it, little
realising that they are making things worse.

so does IT management .. sometimes even after reading "The Mythical Man
Month"

1. The project should be controlled by a god who makes the rules and
keeps the lid on programmers' egos.

I believe in the separation of church and code

3. Good programmers are better than bad programmers.

and ... 2 years of good experience is better than 20 years of bad experience

4. A project takes as long as it takes.

hard to sell that anymore; I just love it when I see these budgets that
say "1264 hrs programming time" ... lol ... not 1263? how can they tell?

 

[Lew]

hard to sell that anymore; I just love it when I see these budgets that
say "1264 hrs programming time" ... lol ... not 1263? how can they tell?

And not a very useful saying. "A project takes as long as it takes"
trivially, but it takes longer if you don't manage it properly, and in the
industry at large never gets there at all more than half the time. There's no
excuse for that.

Time estimates should include a range of uncertainty, e.g., "1300 hours plus
50%, minus 33%"; not including such a range is dishonest. (See Steve
McConnell, /Rapid Development/, Microsoft Press.)

Unless a project treads brand-new algorithmic ground, and there are a tiny
number of those out there, there's no reason to keep a schedule utterly open
ended. Acknowledge the uncertainty, but contain it. Use effective practices
like test-driven development and much of the Agile Programming methodology and
you stand a much better chance of finishing on the quick end of the time.

Bear in mind that development cost is roughly inversely proportional to the
fourth power of the time allowed in the schedule.

Throwing warm bodies at a project is only one of the thirty-six classic
mistakes of software project management outlined by McConnell in /Rapid
Development/.

It is possible to meaningfully schedule a software project, if one is
ruthlessly pragmatic in one's planning and gives up the superstitions that
lead to those thirty-six classic mistakes. It is certainly not necessary to
toss one's hands in the air and sententiously intone, "It takes as long as it
takes," giving up all responsibility.

 

[Liz]

And not a very useful saying. "A project takes as long as it takes"
trivially, but it takes longer if you don't manage it properly, and in the
industry at large never gets there at all more than half the time.
There's no excuse for that.

but that begs the question of what it means to "manage it properly" and I
don't think anyone really has a suitable answer on that, notwithstanding all
the acronyms and verbiage which have appeared asserting the value and
validity of this or that method. It remains an art, to which some people
have added some good pointers and tips

Time estimates should include a range of uncertainty, e.g., "1300 hours
plus 50%, minus 33%"; not including such a range is dishonest. (See Steve
McConnell, /Rapid Development/, Microsoft Press.)

that may be honest (and it may not), but how useful is it? it comes down
to, it'll cost $1M to $2.2M and will take 5 months to a year ... sounds more
like a guess than an estimate; suppose you went down to the Exxon station
and the attendant said it'll cost $40-82 to fill your tank ... all depends
.... or your mortgage payment will be between $2000 and $4000 ... we don't
know

We are not managing projects so much as we are managing expectations ...
there is a HUGE difference

Use effective practices like test-driven development and much of the Agile
Programming methodology and you stand a much better chance of finishing on
the quick end of the time.

that's too late; understand the machine you are building, find the pain
points at the beginning and do POC ... if you can't, halt the work or call
it what it is: R&D

It is certainly not necessary to toss one's hands in the air and
sententiously intone, "It takes as long as it takes," giving up all
responsibility.

you can't do that ... but the other is a more sophisticated version of it
.... and full of "outs" in all cases; "we said 1300 hrs +50% on the upside
but that was before engineering demanded X, Y & Z features (and insisted
they were already in the spec)"

 

[Ian Semmel]

-----Original Message-----
From: Lew [mailto:[email protected]]

hard to sell that anymore; I just love it when I see these budgets that
say "1264 hrs programming time" ... lol ... not 1263? how can they

tell?

And not a very useful saying. "A project takes as long as it takes"
trivially, but it takes longer if you don't manage it properly, and in
the
industry at large never gets there at all more than half the time.
There's no
excuse for that.

I'm not implying that projects should be open-ended, but more along the
lines that after applying all your experience and designing the project,
you come up with an estimate of X, only to be told by some marketing
person that this isn't satisfactory and that the product has been promised
in X / 2. They often won't accept that regardless of what might have been
promised, it is going to take X.

 

[Liz]

I'm not implying that projects should be open-ended, but more along the
lines that after applying all your experience and designing the project,
you come up with an estimate of X, only to be told by some marketing
person that this isn't satisfactory and that the product has been promised
in X / 2. They often won't accept that regardless of what might have been
promised, it is going to take X.

no, they don't .... and they get what they get ... give me a fraction of
the time needed, you get a fraction of the product desired ... all the S&M
team wants is "good enough" anyway; these are the same folks who were
seeking "team players who are passionate about their work" when they hired
you .... lol ....