Software Engineering Best Practices
We have tailored some best practices in the industry at our software engineering process. The practices help us to manage large scale software projects and after sales maintenance. These practices also protect us from falling in the different bottlenecks during software development life cycle (SDCL). Apart from these practices, we follow standard operating procedure (SOP) focusing on the below stated strategies within the practices. We welcome our clients to visit us and to have an idea on our custom process.
1. Development process –
Development life cycle is important for Software to execute smoothly at client end. We follow agile methodologies for development. We initially collect the requirement and set a product owner from our own. During development if any queries which he could not answer, then he contact to the actual product owner for clarification. At the end of each sprint we invite client to our office to see the sprint demo. In many case if product owner wish we deploy the release in incremental way to his premises for partial UAT.
2. Requirements –
Gathering and agreeing on requirements is fundamental to a successful project. This does not necessarily imply that all requirements need to be fixed before any architecture, design, and coding is done, but it is important for the development team to understand what needs to be built. Quality requirements are broken up into two kinds: functional and non-functional. A good way to document functional requirements is using Use Cases. Note that Use Cases are used for non-OO projects. Non-functional requirements describe the performance and system characteristics of the application. It is important to gather them because they have a major impact on the application architecture, design, and performance.
3. Architecture –
Choosing the appropriate architecture for your application is key. Our consultants can work side by side with your team and ensure that the projects get started on the right track. Many projects fail as discussed in the introduction. The study of these failures has given rise to the concept of anti patterns. They are valuable because they provide useful knowledge of what does not work, and why.
4. Design -
Even with a good architecture it is still possible to have a bad design. Many applications are either over-designed or under-designed. The two basic principles here are "Keep it Simple" and information hiding. For many projects, it is important to perform Object-Oriented Analysis and Design using UML. There are many books on UML, but we recommend UML User Guide  and Applying UML and Patterns . Reuse is one of the great promises of OO, but it is often unrealized because of the additional effort required to create reusable assets. Code reuse is but one form of reuse and there are other kinds of reuse that can provide better productivity gains.
6. Construction of the code -
Construction of the code is a fraction of the total project effort, but it is often the most visible. Other work equally important includes requirements, architecture, analysis, design, and test. In projects with no development process (so-called "code and fix"), these tasks are also happening, but under the guise of programming. A best practice for constructing code includes the daily build and smoke test. Martin Fowler goes one step further and suggests continuous integration that also integrates the concept of unit tests and self-testing code.
7. Use Component-Based Architectures -
The process focuses on early development and base lining of a robust executable architecture, prior to committing resources for full-scale development. It describes how to design a resilient architecture that is flexible, accommodates change, is intuitively understandable, and promotes more effective software reuse.
8. Peer reviews -
It is important to review other people's work. Experience has shown that problems are eliminated earlier this way and reviews are as effective as or even more effective than testing. Any artifact from the development process is reviewed, including plans, requirements, architecture, design, code, and test cases.
9. Testing -
Testing is not an afterthought or cutback when the schedule gets tight. It is an integral part of software development that needs to be planned. It is also important that testing is done proactively; meaning that test cases are planned before coding starts and test cases are developed while the application is being designed and coded. There are also a number of testing patterns that have been developed.
10. Performance testing -
Testing is usually the last resort to catch application defects. It is labor intensive and usually only catches coding defects. Architecture and design defects may be missed. One method to catch some architectural defects is to simulate load testing on the application before it is deployed and to deal with performance issues before they become problems.
11. Configuration management -
Configuration management involves knowing the state of all artifacts that make up your system or project, managing the state of those artifacts, and releasing distinct versions of a system. There is more to configuration management than just source control systems.
12. Quality and defects management -
It is important to establish quality priorities and release criteria for the project so that a plan is constructed to help the team achieve quality software. As the project is coded and tested, the defect arrival and fix rate can help measure the maturity of the code. It is important that a defect tracking system is used that is linked to the source control management system.
13. Deployment -
Deployment is the final stage of releasing an application for users. We have plans for deployment and we use a deployment checklist as per our project requirement.
14. System operations and support -
Without the operations department, we cannot deploy and support a new application. The support area is a vital factor to respond and resolve user problems. To ease the flow of problems, the support problem database is hooked into the application defect tracking system.
15. Data migration -
Most applications are not brand new, but are enhancements or rewrites of existing applications. Data migration from the existing data sources is usually a major project by itself. This is not a project for your junior programmers. It is as important as the new application. Usually the new application has better business rules and expects higher quality data.
16. Project management -
Project management is the key to a successful project. Many of the other best practice areas are described is related to project management and a good project manager is already aware of the existence of these best practices. One way to manage a difficult project is through time boxing.