PDA

View Full Version : Software Development Lifecycle



suityou01
29th November 2011, 11:15
Just checking that for a waterfall project :

It is Design, Build, Test, Deliver isn't it?

Not Design, Build, Quible about minor trivia on the design all day long so we miss our deadlines, never deliver in a month of Sundays?

:rolleyes:

DimPrawn
29th November 2011, 11:20
Stick these on

http://4.bp.blogspot.com/_xU21_zOX8j4/TFftsnX8j3I/AAAAAAAAAac/dBbIE6IzwMo/s400/allin1+classic.jpg

Stop whining.


And keep on invoicing.


HTH BIDI

Basil Fawlty
29th November 2011, 11:21
Current thinking on at our place is :

Build, design, deliver, test then blame....

MarillionFan
29th November 2011, 11:22
Current thinking on at our place is :

Build, design, deliver, test then blame....

That's what Im used to.

tractor
29th November 2011, 11:24
That's what Im used to.

Better to Design, Build, Deliver, don't renew - move on

Mich the Tester
29th November 2011, 11:25
Just checking that for a waterfall project :

It is Design, Build, Test, Rebuild, Test, Invoice, Argue with Bob about whether issues are defects or change requests, Invoice, Rebuild, Test, Invoice, Argue with Bob about whether issues are defects or change requests, Invoice,Rebuild, Test, Invoice, Argue with Bob about whether issues are defects or change requests, Invoice,Rebuild, Test, Invoice, Argue with Bob about whether issues are defects or change requests, Invoice,Rebuild, Test, Invoice, Argue with Bob about whether issues are defects or change requests, Invoice,Rebuild, Test, Invoice, Argue with Bob about whether issues are defects or change requests, Invoice,Rebuild, Test, Invoice, Argue with Bob about whether issues are defects or change requests, Invoice,Rebuild, Test, Invoice, Argue with Bob about whether issues are defects or change requests, Invoice,Rebuild, Test, Invoice, Argue with Bob about whether issues are defects or change requests, Invoice,Rebuild, Test, Invoice, Argue with Bob about whether issues are defects or change requests, Invoice,
Brush up CV, Argue with Bob about whether issues are defects or change requests, Invoice, Clear desk and cookies, Invoice, Holiday


ftfy

Troll
29th November 2011, 11:27
Usual practice

Design
Offshore dev
Offshore test
Deliver
Point finger
Offshore Remediation
Re deliver
Point fingers
Engage UK test resources
On shore test
Point lots of fingers
On shore rework
Retest
Delivery

Usual sticking plaster is to call 1st delivery Phase I and then get it corrected for Phase II

HTH

Mich the Tester
29th November 2011, 11:29
Usual practice

Design
Offshore dev
Offshore test
Deliver
Point finger
Offshore Remediation
Re deliver
Point fingers
Engage UK test resources
On shore test
Point lots of fingers
On shore rework
Retest
Delivery

Usual sticking plaster is to call 1st delivery Phase I and then get it corrected for Phase II

HTH
You haven't sent any invoices, so by the end of this cycle you will be living under a bridge in a cardboard box drinking methylated spirit.

Troll
29th November 2011, 11:29
Current thinking on at our place is :

Build, design, deliver, test then blame.... wot is it that you build before you design?

Pondlife
29th November 2011, 11:34
Maybe if you included a requirements analysis phase at the start then you wouldn't consta... aww forgetit

:tongue

Mich the Tester
29th November 2011, 11:36
Maybe if you included a requirements analysis phase at the start then you wouldn't consta... aww forgetit

:tongue

STOP IT! You'll put contractors out of work if you say that!

Troll
29th November 2011, 11:36
You haven't sent any invoices, so by the end of this cycle you will be living under a bridge in a cardboard box drinking methylated spirit.I usually gat parachuted in about midpoint in that list to turn it around

One of the pleasures of which is bringing it back onshore, making certain the idiots who signed up to the original approach are gone and the Steering Group knows the errors that have been made
Replace key positions with people I know will deliver
Mega invoice for the duration

Drive it through to a successful delivery and sign off

The great thing is its actually so easy to do and the work never stops coming

suityou01
29th November 2011, 11:36
Phew I'm glad it's not just me then. :rolleyes:

I worked with Bobs on the last gig and they were extremely good.

This off shore team a just a bunch of recalcitrant retards.

This is a teensy weensy project with a teensy weensy budget. Also a teensy weensy data model. This data model is what they are arguing the toss over.

Suity : So the stored procedures are 90% complete?
Offshore : Yes Suity

Suity : Great news. So completed tomorrow then?
Offshore : Actually suity we need to implement error handling in all procedures.

Suity : <thinking> Ok error handling added as an after thought. Bit of a worry but if you criticise then you are technically a hypocrite. </thinking>
Suity : Err ok. So completed tomorrow then?

Offshore : Yes.
Suity : Great. And did you adjust the insert stored procedures so they all return the new row ID?

Offshore : No. Did you want us to do this?
Suity : As per the meeting on Friday, yes. As per my email of Friday after the meeting, yes.

Offshore : Ok fine.
Suity : So shall I adjust these estimates down to 50%

Offshore : Yes.
Suity : So not tomorrow then?

Offshore : No.
Suity : When then?

Offshore : Actually we have more concerns over the data model.

:suicide:

Fixed price bid my hairy spotty arse.

d000hg
29th November 2011, 11:39
Just checking that for a waterfall project :

It is Design, Build, Test, Deliver isn't it?

Not Design, Build, Quible about minor trivia on the design all day long so we miss our deadlines, never deliver in a month of Sundays?

:rolleyes:Waterfall is fundamentally broken so not actually getting to delivery saves you a lot of bother when the client complain it is "not what they meant at all"

TheFaQQer
29th November 2011, 11:40
<BigBrotherVoice>
It's 34 days since Suity said he'd walk in two weeks if things didn't improve....
</BigBrotherVoice>

Mich the Tester
29th November 2011, 11:40
I usually gat parachuted in about midpoint in that list to turn it around

One of the pleasures of which is bringing it back onshore, making certain the idiots who signed up to the original approach are gone and the Steering Group knows the errors that have been made
Replace key positions with people I know will deliver
Mega invoice for the duration

Drive it through to a successful delivery and sign off

The great thing is its actually so easy to do and the work never stops coming

Me too. Trouble is, when I suggested they bring it back onshore and finish off in an agile approach, knowing that just about nobody can actually write proper requirements nowadays anyway, they explained that it's impossible to change from waterfall to agile mid-project. I can't remember the explanation, which is an indicator of my judgment of the quality of that explanation. So they didn't listen, the cycle continues, and I keep invoicing. Stupid ****whits.

Mich the Tester
29th November 2011, 11:41
Waterfall is fundamentally broken so not actually getting to delivery saves you a lot of bother when the client complain it is "not what they meant at all"

whs

suityou01
29th November 2011, 11:44
whs

Try operating an agile approach over a crackly telephone call with an off shore team with pidgin English.

Sometimes waterfall is the only way. :rolleyes:

Arturo Bassick
29th November 2011, 11:44
Waterfall is fundamentally broken so not actually getting to delivery saves you a lot of bother when the client complain it is "not what they meant at all"Waterfall works. It has limited uses, but does have uses. It has to be a project that is effectively a much repeated project and very well known.

doomage
29th November 2011, 11:46
Are you savvy developers / PMs aware that the whole concept of 'waterfall' in software development was simply an academic misunderstanding?

Waterfall Accident (http://pascal.gugenberger.net/thoughts/waterfall-accident.html)

For those too lazy to read this, the relevant paragraph is: What we today know as the waterfall model comes from a paper with the title "Managing the Development of Large Software Systems", written in 1970 by Winston W. Royce. On page 2 it contains the famous diagram with the cascade starting at "System requirements" on the upper left, continuing on through "Program Design" and "Coding" down to "Operations" on the lower right.

But nobody seemed to notice that Royce does not promote this model. On the contrary, directly below he writes “… the implementation described above is risky and invites failure.” He then goes on to promote a different process: He recommends to “do it twice” by building a throw-away “pilot model” first to explore novel elements and unknown factors. Furthermore, in the introduction Royce admits that he has no data to back-up his ideas, he calls them "personal views" and "prejudices".

Somehow the intellectual lightweights of the time (project managers I'd expect) took the simple (but incorrect) solution as promoted it as the way forward and we have all suffered greatly since. Although some of you have invoiced well out of it I'd expect.

As Henry Ford said, thinking is the hardest work of all, which is why so few people do it.

Mich the Tester
29th November 2011, 11:46
Waterfall works. It has limited uses, but does have uses. It has to be a project that is effectively a much repeated project and very well known.

wot? Like something that's already been done and so doesn't need to be done again?

Mich the Tester
29th November 2011, 11:47
Try operating an agile approach over a crackly telephone call with an off shore team with pidgin English.

Sometimes waterfall is the only way. :rolleyes:


I think I've spotted the problem here.

MarillionFan
29th November 2011, 11:47
Try operating an agile approach over a crackly telephone call with an off shore team with pidgin English.

Sometimes waterfall is the only way. :rolleyes:

Doing it now. And what a rivetting call it is.

Mich the Tester
29th November 2011, 11:49
Are you savvy developers / PMs aware that the whole concept of 'waterfall' in software development was simply an academic misunderstanding?

Waterfall Accident (http://pascal.gugenberger.net/thoughts/waterfall-accident.html)

For those too lazy to read this, the relevant paragraph is: What we today know as the waterfall model comes from a paper with the title "Managing the Development of Large Software Systems", written in 1970 by Winston W. Royce. On page 2 it contains the famous diagram with the cascade starting at "System requirements" on the upper left, continuing on through "Program Design" and "Coding" down to "Operations" on the lower right.

But nobody seemed to notice that Royce does not promote this model. On the contrary, directly below he writes “… the implementation described above is risky and invites failure.” He then goes on to promote a different process: He recommends to “do it twice” by building a throw-away “pilot model” first to explore novel elements and unknown factors. Furthermore, in the introduction Royce admits that he has no data to back-up his ideas, he calls them "personal views" and "prejudices".

Somehow the intellectual lightweights of the time (project managers I'd expect) took the simple (but incorrect) solution as promoted it as the way forward and we have all suffered greatly since. Although some of you have invoiced well out of it I'd expect.

As Henry Ford said, thinking is the hardest work of all, which is why so few people do it.

Well done sir, excellent information, confirms everything I ever thought, now put it away and don't tell anyone again in case you stop the gravy train.

Mich the Tester
29th November 2011, 11:49
Doing it now. And what a rivetting call it is.

I am feeling this is being change request; please be changing status!

doodab
29th November 2011, 11:50
Suity : <thinking> Ok error handling added as an after thought. Bit of a worry but if you criticise then you are technically a hypocrite. </thinking>

Why would criticising the adding of error handling as an afterthought make you a hypocrite?

MarillionFan
29th November 2011, 11:50
I am feeling this is being change request; please be changing status!

JIRA call. Jesus christ.

Arturo Bassick
29th November 2011, 11:51
wot? Like something that's already been done and so doesn't need to be done again?Kind of, obviously it needs to be done again or you wouldn't be doing it. If your firm does the same thing over and over again with very little variance then you can use the waterfall as a management tool to show you have followed the well worn procedure.

doodab
29th November 2011, 11:52
Waterfall 2006 - International Conference on Sequential Development (http://waterfall2006.com/)

Mich the Tester
29th November 2011, 11:52
JIRA call. Jesus christ.

We are not being certain that this issue '535 Wrong sum total in price and sales tax calculation' is truly production blocking issue; please to be changing to minor or cosmetic change request.

Mich the Tester
29th November 2011, 11:54
Waterfall 2006 - International Conference on Sequential Development (http://waterfall2006.com/)

:laugh :yay:

original PM
29th November 2011, 11:54
Kind of, obviously it needs to be done again or you wouldn't be doing it. If your firm does the same thing over and over again with very little variance then you can use the waterfall as a management tool to show you have followed the well worn procedure.

Yeah - i often fine that where there is a very rigid process in place people are simply going through the motions (is there a difference between following a rigid process and going through the motions??) simply to ensure that they do not get the blame for when the project goes wrong.

It is in essence everything that is wrong with a lot of projects and project managers right now.

MarillionFan
29th November 2011, 11:55
We are not being certain that this issue '535 Wrong sum total in price and sales tax calculation' is truly production blocking issue; please to be changing to minor or cosmetic change request.

PM - Let's review JIRA 369. MF this is with you.

MF - I failed it last week and the developer says that it is no longer on his priority list as he says he's done the fix. Of course it's a five minute change and of course if the same issue happens again in production the whole datawarehouse load will fail and we're fecked.

Developer - What are my prioritites please?

FFS!!!!

Mich the Tester
29th November 2011, 11:55
Yeah - i often fine that where there is a very rigid process in place people are simply going through the motions (is there a difference between following a rigid process and going through the motions??)

I've never had problems achieving the necessary rigidity to go through the motions with Lady Tester.

original PM
29th November 2011, 11:57
I've never had problems achieving the necessary rigidity to go through the motions with Lady Tester.

Yes but it's much more fun when you can add in a bit of your own initiative....

:happy

Mich the Tester
29th November 2011, 11:57
PM - Let's review JIRA 369. MF this is with you.

MF - I failed it last week and the developer says that it is no longer on his priority list as he says he's done the fix. Of course it's a five minute change and of course if the same issue happens again in production the whole datawarehouse load will fail and we're fecked.

Developer - What are my prioritites please?

FFS!!!!

Ah, just coincidentally I had an argument about HP QC 369 this morning; they've made a temporary workaround which works, in a workaroundy kind of way, and now want the issue closed so that the the agreed solution can only be built as 'being change request'.

suityou01
29th November 2011, 12:02
:yay:

Others are suffering the same crap. :banana2:

CUK as a concept works then. Well done admin. :D

Spacecadet
29th November 2011, 12:35
Are you savvy developers / PMs aware that the whole concept of 'waterfall' in software development was simply an academic misunderstanding?

Waterfall Accident (http://pascal.gugenberger.net/thoughts/waterfall-accident.html)

For those too lazy to read this, the relevant paragraph is: What we today know as the waterfall model comes from a paper with the title "Managing the Development of Large Software Systems", written in 1970 by Winston W. Royce. On page 2 it contains the famous diagram with the cascade starting at "System requirements" on the upper left, continuing on through "Program Design" and "Coding" down to "Operations" on the lower right.

But nobody seemed to notice that Royce does not promote this model. On the contrary, directly below he writes “… the implementation described above is risky and invites failure.” He then goes on to promote a different process: He recommends to “do it twice” by building a throw-away “pilot model” first to explore novel elements and unknown factors. Furthermore, in the introduction Royce admits that he has no data to back-up his ideas, he calls them "personal views" and "prejudices".

Somehow the intellectual lightweights of the time (project managers I'd expect) took the simple (but incorrect) solution as promoted it as the way forward and we have all suffered greatly since. Although some of you have invoiced well out of it I'd expect.

As Henry Ford said, thinking is the hardest work of all, which is why so few people do it.

There is more here as well:
http://www.cs.umd.edu/class/spring2003/cmsc838p/Process/waterfall.pdf

Includes every developers nightmare - Documenting the Design. Somethig which is missing from most projects and something I normally have to remind project managers to put in as it needs to go beyond simply spelling out what the software needs to do.
The design can normally be shaken down at the documentation stage with the end customer removing any silly design mistakes or assumptions

d000hg
29th November 2011, 12:41
Try operating an agile approach over a crackly telephone call with an off shore team with pidgin English.

Sometimes waterfall is the only way. :rolleyes:Strict waterfall is crap. I don't much care for strict, dogmatic Agile either. The general principle of Waterfall is OK as long as you remember it is an ideal, not 100% workable in reality. i.e. fixed specs for you offshore team to work to, less rigid in other areas such as feeding user testing back into development (aka a beta ;))

NotAllThere
29th November 2011, 12:47
I can't understand why an application that'll only be used at year-end must be "live" by July, so that the first time it's used with real data from real users, there will be no IT people on site. Nor why the output documents must be ready for testing by December, when testing them isn't scheduled until March.

But I just keep billing.

Mich the Tester
29th November 2011, 12:50
I just keep billing.

whs

PAH
29th November 2011, 12:51
"Don't piss down my back and tell me it's a waterfall" - The Outsourced Josie Whale

"What we've got here is a perpetual waterfall" - Cool Hand Bob


Some remakes are worth watching. :smokin

Freamon
29th November 2011, 23:02
PM - Let's review JIRA 369. MF this is with you.

MF - I failed it last week and the developer says that it is no longer on his priority list as he says he's done the fix. Of course it's a five minute change and of course if the same issue happens again in production the whole datawarehouse load will fail and we're fecked.

Developer - What are my prioritites please?

FFS!!!!

Problems highlighted above.

MarillionFan
29th November 2011, 23:03
Problems highlighted above.

???

I'm the tester. Not the developer.

russell
29th November 2011, 23:08
Suity you must be an expert in waterfall, especially when the water is piss falling below you?
:tongue

TestMangler
29th November 2011, 23:13
???

I'm the tester. Not the developer.

The defect is with you, the developer says he's fixed it.

Is the grenade not in your hand for retest ?

If not, that's what the quote makes it look like :tumble:

MarillionFan
29th November 2011, 23:17
The defect is with you, the developer says he's fixed it.

Is the grenade not in your hand for retest ?

If not, that's what the quote makes it look like :tumble:

No, the JIRA says 'Failed' and is assigned to the developer, but as BA I hold the JIRA.

It's interesting. I'm not really used to working in 'IT' as such. For years I have always sat on the outside of IT departments bought in by the business as 'shadow IT' because these feckers can't deliver. Now I'm sat on the other side of the fence. I engage directly with internal clients and I have control over the projects I deliver, but not always the resource. As soon as it goes to a shared resource model it doesn't work.

There is something intrinsically f**ked with social makeup of people who work in IT that makes them hide behind emails & computers and just don't do the job. And that's why they get outsourced, because they are ******* hopeless at communicating or managing themselves. Hence go with the cheapest.

TestMangler
29th November 2011, 23:26
No, the JIRA says 'Failed' and is assigned to the developer, but as BA I hold the JIRA.

It's interesting. I'm not really used to working in 'IT' as such. For years I have always sat on the outside of IT departments bought in by the business as 'shadow IT' because these feckers can't deliver. Now I'm sat on the other side of the fence. I engage directly with internal clients and I have control over the projects I deliver, but not always the resource. As soon as it goes to a shared resource model it doesn't work.

There is something intrinsically f**ked with social makeup of people who work in IT that makes them hide behind emails & computers and just don't do the job. And that's why they get outsourced, because they are ******* hopeless at communicating or managing themselves. Hence go with the cheapest.

I have jumped out of Test Management now because I couldn't stand working with remote or outsourced teams. I never did traditional 'management' stuff with presentations and bullshit. I could usually be found prowling the office with a phone in one hand and a pack of fags in the other :happy

It's a lot harder to duck responsibility and play 'asignee tennis' in QC when you've got some mad nicotine deprived jock sitting on your desk :eek

Resources should be within grabbing distance :ladybags:

Freamon
29th November 2011, 23:53
No, the JIRA says 'Failed' and is assigned to the developer, but as BA I hold the JIRA.

This'll be why the PM says the ticket is "with you" then. You should have been clearer when you corrected him.

doodab
29th November 2011, 23:58
No, the JIRA says 'Failed' and is assigned to the developer, but as BA I hold the JIRA.

It's interesting. I'm not really used to working in 'IT' as such. For years I have always sat on the outside of IT departments bought in by the business as 'shadow IT' because these feckers can't deliver. Now I'm sat on the other side of the fence. I engage directly with internal clients and I have control over the projects I deliver, but not always the resource. As soon as it goes to a shared resource model it doesn't work.

There is something intrinsically f**ked with social makeup of people who work in IT that makes them hide behind emails & computers and just don't do the job. And that's why they get outsourced, because they are ******* hopeless at communicating or managing themselves. Hence go with the cheapest.

You've clearly never worked for a happy company with motivated people.

MarillionFan
29th November 2011, 23:59
You've clearly never worked for a happy company with motivated people.

Of course I have. It's when they work for me.:D

Basically though IT people are slightly smarter than normal but still need as much management and help as labourers on a building site. That's why they get outsourced.

alreadypacked
30th November 2011, 07:25
Phew I'm glad it's not just me then. :rolleyes:

This off shore team a just a bunch of recalcitrant retards.

Suity : So the stored procedures are 90% complete?
Offshore : Yes Suity

Offshore : Actually we have more concerns over the data model.


This is Bob speak for "We don't know what a data model is"

Project 1% complete. They may not even have the software installed to open your design.

HTH

TheFaQQer
30th November 2011, 10:43
This is Bob speak for "which cretin designed this shit?"

FTFY