It is said that communications in the analysis step often breaks down? Could you comment on this? Have you experienced this phenomenon? If not, would you accept this statement, and why?
"The requirements analysis and design phase is believed to be the most critical part of the software development lifecycle " (Catherine, 2007). In a presentation on the topic, John Petlick of De Paul University in Chicago describes one of the deficiencies of the waterfall model as "all requirements must be known upfront" (n.d.), which is never the case when communication does break down as I have experienced.
I work as part of a team of four developers. We are expected to deliver business requirements across a number of platforms. But we are constantly involved in development projects where the analysis phase never happens or is over far too quickly. In the former case, the project becomes technology led. The design and execution is done by the development team who fully understand how to make the application in question output a message or file but fail to understand what the application actually means to the business, its users and its customers. In the latter case the analysis phase often starts and ends in a single meeting, with the output being a very rough specification document that lacks the low - level detail necessary when architecting a system. An exercise of 'fill in the blanks' then begins for the developers while the business customers believe their part in the process is done or are too busy to devote any more time to the analysis. The attitude quickly becomes 'it's now the responsibility of the IT people to deliver' which is ludicrous. Getting developers and business analysts to to communicate with more quality and quantity is one of the fundamentals of the agile / xtreme programming model where a business analyst is part of the development team full time and on hand to answer questions straight away. This would be light years away from the current process where progress is viewed on a weekly or fortnightly basis, and it's only then that the developers get their mistakes pointed out.
I also have experience of where the analysis phase is done properly. This has tended to happen on projects where I am the sole developer and where I have a good enough relationship with the customer to go to them face - to - face every day and ask questions. Communications in the analysis phase of local government IT projects often break down because groups of key people have a 'history' that stops them from working together. But until a level of understanding that sees the business afforded as much responsibility in the software engineering realm as the developers is reached, then software projects will continue to fail.
In the UK central government is trying to roll out Contact Point, an index of child information. It was recently announced that the deadline of April 2008 would be put back until October 2008 - the second time a deadline has been extended. At meetings it is always obvious that the developers of the system - one of the largest IT consultancy firms in the country - and its user base (people like me and my colleagues) are consistently on different wavelengths.
Refs:
Catherine, A (2007) Software Development Life Cycle: Basic Steps to Strong Product [Online] ArticlesBase.com
Available from http://www.articlesbase.com/computers-articles/software-development-life-cycle-basic-steps-to-strong-product-194148.html (Accessed 21 Dec 2007)
Petlick, J (n.d.) Software Development Life Cycle (SDLC) [Online] De Paul University, Chicago, IL
Available from condor.depaul.edu/~jpetlick/extra/394/Session2.ppt (Accessed 21 Dec 2007)
No comments:
Post a Comment