CS504 Software Engineering GDB Solution Fall 2012

Your company has got a project for developing a software system. A similar software system was developed in your previous company. You discover that your company’s interpretation of requirements is different from the interpretation taken by your previous company. Cost of project will tremendously increase if ambiguities in requirements are not resolved. You have also an ethical responsibility of confidentiality to your previous company. Discuss what you should do in such a situation?
Note that GDB will remain open for 2 days only (from 11th Feb to 12th Feb, 2013) and no extra time will be given for posting the answer. Therefore, make sure that you submit your answer within the given time.


Software projects are notoriously difficult to manage. Stories of projects delivered late, over-budget and/or defect-ridden abound. You have likely been involved in a few such projects yourself.

Many trainers and coaches claim to offer a solution to software delivery problems. However, before diving into the latest project management fad, it’s important to understand the underlying reasons why software is so difficult to manage.

The problems begin with requirements. There is a persistent myth that software requirements can be fully determined at the outset of a project. Despite repeated project failures traced to faulty requirements, we continue to believe that requirements must be fully documented before software development can begin.

The underlying rational is that we need to do a better job of defining requirements. If we can just get the requirements right, the rest of the project will be easy.

The next fallacy involves change. Changes are to be expected. You will need a rigorous change management system to define, track and control change requests. Unfortunately, most change management systems are really change prevention systems. They only cause more problems.

Where Does Change Come From?

Any project lasting for more than a few weeks is likely to encounter technology changes. Operating systems, security systems, APIs, development tools, etc. will change and require that the team make adjustments. The alternative is to not upgrade the underlying software and risk deploying to the end user with old, possibly unsupported, code.

Competitive changes are a constant threat. If a competitor announces or ships something unexpected, you will be left scrambling to catch up. The only thing you can do is revise the requirements.

Business process changes are always looming. As management strives to improve productivity, reduce costs, react to new regulations, and deal with organizational changes, the software will need to adapt.

Resisting such changes is futile. Even if you succeed in preventing changes to the project plan, you will end up delivering software that is outdated before it arrives.

Another big trouble spot for software development teams is estimation. Any estimate is only as good as the data available and the assumptions made. Faced with changing data and questionable assumptions, project managers will often do their best to hold to the initial estimate. Bad idea.

As changes occur, estimates become less accurate. Even seemingly small changes can have a dramatic impact on an estimate. Force fitting the new information into the original estimate will result in late delivery, defective code or both.