![back](/img/common/back.png)
![Blog image](/img/blog/140920/title.jpg)
![Calendar Image](/img/common/postDate.png)
Best practices are a set of empirically proven approaches to software development. When used in combination they strike at the root causes of software development problems. Lets have a look at some of the important ones.
1. Manage Requirements
![Manage Requirements](/img/blog/140920/manage.jpg)
The user’s own understanding of the requirements will evolve over time. That will then change the requirements. So, a software engineer should always be expecting changes during software development. It is also important to reach an agreement with the user on what the software should do, not how to do it. That is, after all, your job. Also always maintain forward and backward traceability of the requirements.
2. Use Component-based Architecture
![Use Component-based Architecture](/img/blog/140920/components.jpg)
The use of components improves the maintainability and extensibility phenomenally. Almost all of the trending frameworks now allow and promote component-based architecture. This will also help in clean division of work among teams. Also, component-based architecture makes the reuse possible.
3. Develop Iteratively
![Develop Iteratively](/img/blog/140920/iterative.jpg)
Always create objective milestones while creating a software. That will help you concentrate on the small parts. But we also should never lose the context. Critical risks should be resolved before making large investments. Initial iterations will help us get early user feedback and this save the engineer from making drastic changes at last while helping the engineer make sure he/she is on track. Goes without saying that the testing and integration will be and should be continuous.
4. Verify Software Quality
![Verify Software Quality](/img/blog/140920/verify.jpg)
What is quality anyway? It is the characteristic of producing a product which meets or exceeds agreed upon requirements by some agreed upon objective measure. Once deployed, software issues are significantly costly to repair. So, it would be wise to develop functionality, performance and reliability test suites for every iteration.
5. Control Changes to Software
![Control Changes to Software](/img/blog/140920/control.jpg)
Without explicit control while developing as a team, everything becomes chaos. So, while developing as a team the architecture should be decomposed into smaller subsystems and responsibility of each should be assigned to a team. It should be done in such a way that the changes made by one team affect other teams the least or ideally, have none. Control mechanisms should be established for change requests. These mechanisms should make sure the change requests are the priority. The impact of the change request should always be assessed and there should be a plan to handle change requests for every iteration.
They are called "best practices" not because we can precisely quantify their value but rather, they are observed to be commonly used in industry by successful organizations.
Disclaimer : The views and opinions expressed in the article belong solely to the author, and not necessarily to the author's employer, organisation, committee or other group or individual.
All fields are mandatory. Your email id won't be published!