real benefits of analysis /design in software development

The tradional waterfall model in software development contains foru distinct phases:

1. Business requirements. The first step in the traditional software development process is to identify business requirements as well as the scope of the release. It encompasses those tasks that go into determining the needs or conditions to meet for a new or altered product, taking account of the possibly conflicting requirements of the various stakeholders, such as beneficiaries or users.
2. Architecture and design. The goal of the architecture and design phase is to try to identify an architecture that has a good chance of working. The architecture is often defined using free-form diagrams which explore the technical infrastructure, and the major business entities and their relationships. The design is derived in a modeling session, in which issues are explored, until the team is satisfied that they understand what needs to be delivered.
3. Development. The development phase produces code in an environment that is specific to the culture of the development team and the skills of the individuals. In large projects the tasks are structured and distributed to teams. In small projects, or within smaller teams, the tasks are distributed according to team culture and skills. Development continues until goals or milestones are reached.
4. Testing, delivery, and feedback. Testing is ongoing at the local level and becomes more structured on larger scales and as the project approaches delivery. In large projects, the testing is formalized. The customer is engaged in testing and feedback cycles when the development teams are relatively convinced that the software meets the requirements.

¿What is the real benefits of a analysis and design phase? Consider the second and the third stage, ¿why is considered more important analisys and desgin versus development?

We all know projects that have consumed many hours in analysis, with the consequent reduction in implementation times to obtain and deliver product at the time agreed with the clien t needs. The result of this is too bugs in early versions.

On the other side we have projects that was planned with an insufficient analysis. At the implementation time, we have to repair communication error between components, and do a real analysis. The result of this is too bugs in early versions.

The key in this problem is to mesaure the goals of the analysis and design phases, real goals. For example when you use UML for analysis (yes, could be other techniques) we can define different diagrams: Use cases, activities, sequence collaboration… Many customers and projectmanager think that is important to have all the diagramas to continue at the next stage. That is wrong, because you need only the diagrams that can be useful in then design and implementation stage.

Also, if you have a complex analysis and design phases and in the implementation you need to apply changes, you have to propagate this changes to the analysis products. If you don´t do that, you have spent time in analysis that is useless.

Conclusion

I think that the first thing that you have to define when you are dealing with a analysis of an application is define the goals: only do the things that your teem need. If the team that is going to coding is located in your same office probably the analysis could have done in less time than the coded team was in another country (for example an outsourcing job).

 

 

Tags: analysis, software engineering

Category: Others