Virgil Bierschwale wrote: > Nope it is not a waterfall model because it has absolutely nothing to do > with software. >
You are not being consistent here. It it has *absolutely nothing* to do with software, then why are you exposing it as an argument for certain software development models? > That is the department layout for a company I worked at. > > For instance, lets say that the software group was raring to go and they > developed the software before the artwork and the math calculations were > done. > > Then you would end up redoing the software portion. > True, the origins of waterfall model are in construction and other similar activities. You should take some time and read about it, you'll like it. As for redoing the software portion. Are you aware that resources are limited? And that sometimes a system will take several years before being finished? And that business requirements, hardware requirements, back end requirements (that would be databases), will certainly change? Well, there are methodologies that take this into account not as an unwanted event but as a normal and expectable event. To redo a software portion (and notice I don't say *the* software portion, but just one of them) is just normal. It makes no sense arguing about this, there are books written on the subject and you are talking as if it is something no one ever addressed. > The same thing applies to making a 50 story office building. > Until the architect has completed his bluleprint, you would be foolish to > purchase a single door or even a brick. > But you won't be using the building until it is completely built. You *must* know the size of the building before doing it. Specifications won't change along the way. And the terrain in which it stands will not change either. None of these things are true for many software projects. So you see the problem. > See, that is the biggest problem I have in the software business. > Not saying you guys, but software people tend to think the business revolves > around them and they are so wrong on this. > What you say is true. I've seen it oh so many times. Once I heard a developer being told that a series of actions performed by the user in his system would provoke an error, and the answer was "But the user should not do this". But that has nothing to do with the development methodologies. > For instance, at that same manufacturer in vegas, I was able to stop one of > the higher ups from creating his own MIS group because the existing MIS > group was bogged down in their own work and totally unresponsive to the > business side. > I worked several years for an airline's department because they could get no response from the, really large, software department. But that is anecdotal and has nothing to do with the development methodologies. > Even though I can no longer find work in the software business, I still see > those battles being fought daily in the trade journals. > > Bottom line, if you're a software developer and you cannot draw a block > diagram of your companies business process flow from memory, you do not > understand your business and you have some bridges to mend. > I'm currently working (under a full time contract) for a company that manages all the side businesses of the main milk company (that is, trucks, insurance, gas stations, cold providing systems, etc). I only understand some of the software systems involved (some are even developed outside the company, no access to source code), let alone have the company's business process flow, let alone the main milk company's one. I don't think anyone can have in mind the whole data flow model, it's too big. That does not mean I cannot do my job. _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://leafe.com/mailman/listinfo/profox OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech Searchable Archive: http://leafe.com/archives/search/profox This message: http://leafe.com/archives/byMID/profox/[email protected] ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
