home
Home » Requirements Management

Requirements and Bridging the Silos (Part 3 of 3)

Submitted by ahayward on Tue, 2008-03-18 10:59.

by Andrew Hayward

The first and second parts of Mr. Andrew Hayward’s three part series on Requirements and Bridging the Silosdescribed how, in larger development efforts, the division of resources into roles often reduces the effectiveness of communication and hinders understanding of requirements (see part 1 of Requirements and Bridging the Silos) and how to increase the understanding of project requirements within and between the testing and implementation silos (see part 2 of Requirements and Bridging the Silos).

The final installment continues with some examples of how silos have hindered communication and, therefore, understanding of requirements, and the solutions these organizations applied to resolve these problems. Following this is a list of eight best practices to bridge the silos in your organization.

AttachmentSize
Requirements_and_Bridging_the_Silos_(Part_3_of_3).pdf153.38 KB
» login or register to post comments | printer friendly version | 1206 reads

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Debatable

Submitted by dwright on Tue, 2008-03-18 17:39. *

"Software development should not be seen as a set of discrete functions in an assembly line, where one group puts together the
requirements, the next group takes those requirements and builds the solution, and another group then tests the solution."

That's a well-stated position, but I think it is one that can be debated; I would like to think that companies that have truly moved to an assembly-line approach are probably doing very well.

In such a debate, however, I do think you would need different examples than the ones offered in your article, as I don't think they reflect the divisions mentioned above. Any arbitrary division of the development process will produce problems; the divisions are usually organizational, rather than based on a meaningful division of the process into coherent sub-processes.

On the other hand, the opposite side of a debate would need examples of companies successfully using an "assembly line". Would any other readers have any examples to offer? If not, I would think we might have to consider that we don't know enough about software development yet to determine if an assembly line approach can work. People made most everything in their own ways for centuries until Mr. Ford came on the scene; the software "Ford" may not have arrived yet.

So, I am just saying its open for debate and would ask if you have any better examples to offer...

David Wright
Member, IIBA
"As a general rule the most successful man in life is the man who has the best information."
Benjamin Disraeli (1804 - 1881)

» login or register to post comments

How does an assembly line work?

Submitted by Pat Maher on Wed, 2008-03-19 10:17. *

Yes, I know someone inserts the widgets into each item as it floats gently by, but further to that I have no clue about the manufacturing process. The main adverse consequence of silo-based functioning seems to be that what got built is not what was required or even specified - does a classic assembly-line process have some kind of feedback / review built into it? And how would such feedback / review be analogous to what happens in software development?

» login or register to post comments

Assembly Lines produce Products

Submitted by dwright on Mon, 2008-03-31 23:04. *

A manufacturing assembly line assembles already defined/designed products, these days allowing for a lot of variations as well.It does not start with "what are we going to assemble", that is already done. So, a software assembly line already has defined for it what kinds of software it will produce. For example, application software structured as services over SOA, connected by BPM tools and controlled by Business Rule Engines or Enterprise Decision Management. To be assembled, software cannot be just a shapeless blob from which something emerges through use of the latest/greatest methodologies or techniques.

Sure, not all software should be created this way. Studies and famous books have shown that the most brilliant products emerge from talented people working together with passion and not enough time... but that's rare and prone to failure as much as not, and isn't needed for the great majority of useful software.

David Wright

» login or register to post comments

No one designs anything on an assembly line

Submitted by brian.mclean on Tue, 2008-04-01 07:22. *

I'm going out on a limb here a bit, because I'm also no manufacturing guru.

However, I believe the reason the manufacturing analogy fails us in SW dev is because every software building effort is a design project. It doesn't matter how may times you've done something similar, no 2 bespoke developments are the same.

Phil Armour stated this most clearly saying that software is a medium in which business knowledge is stored. And every buiness is different, therefore every deployment carries different knowledge. And knowledge requires a process of discovery before it can be built into the software.

In an assembly line evey worker (or is that robot, these days?) follows EXACTLY the same process to fit the same components together. You can't have someone saying, "Oh, I've done something like this before, let me try it this way!". Those design decisions have been made for him and all he is doing is executing the specification.

Software, on the other hand, requires evey team member to add value by applying some design to the work they do. The only time software is "manufactured" (in my view) is when the compiled code is duplicated on media for packaging.

» login or register to post comments

production method debate

Submitted by azuurbier on Wed, 2008-04-02 09:14. *

A discussion about the production type analogy in software is allways interesting. Is it waterfall, is it assembly line, or R&D? Most people in software prefer to call it R&D, which should explain why projects run out of planning and over budget. Most often only used as an excuse. The assembly line is often disgusted because of the rigid place an operator has in an assembly line and the limited field of operation. Software developers don't want that. But, as stated nicely in the articles, success of a project - however you do it - depends on communication.

I think the assembly line analogy can be implemented in an organization, if only the analogy is well understood and communication is adjusted to it. Even the original paper about the waterfall analogy stated the importance of feedback and communication. That part of the waterfall is often lost in bad communication.

The original paper on the waterfall tries to address the same problems as addressed in these articles. We are about thirty years later than the waterfall paper, but still...

I prefer the contractor analogy, where every sub-contractor knows what to do from a rough drawing under the guidance of the general contractor and every sub-contractor has a specific place in the planning. The general contractor would be the business analyst together with the architect and the sub-contractors would be the developers with specific coding skills such as performance, security or network communication. To implement the contractor analogy, you would need books with building codes and building code inspectors (who do the technical inspection with the interest of the customer in mind). I see a growing awareness and willingness to comply to building codes in software.

Albert Zuurbier

» login or register to post comments

  Sponsored Announcements & Special Offers


FREE Web-based Requirements Management (not just a trial, no time limit)
Lighthouse is a web-based IT project workspace for managing requirements, change requests, project scope, and much more. Lighthouse also automates traceability through the entire life cycle so you will always know the impact of change requests and whether requirements have been built, tested and fulfilled. Free for 5-users, sign-up today.

Download a free trial of ActiveVOS for BPM application development for a chance to win an ultra-portable Lenovo IdeaPad S10 netbook
With the ActiveVOS Business Process Management system (BPMS), the creation of compelling business process applications is compatible, scalable and affordable for everyone from the developer to the business analyst. Download a free, 30-day supported trial of ActiveVOS for the chance to win a Lenovo IdeaPad S10 netbook. No purchase necessary. Download ActiveVOS today at www.wheel-of-function.com.

Writing Use Cases with Word and Excel? Suffered enough?
Create use cases, requirements, diagrams, test cases, and screen prototypes - in one easy-to-use tool. Generate Word and Excel specifications automatically. Consistent, traceable requirements in less time. Try CaseComplete FREE for 30-days.


© 2007 Requirements Networking Group All rights reserved. contact | advertise | privacy
Requirements Networking Group