Business process modeling for software development includes different conceptual visions of how to implement projects to create software. A business process is the implementation of a methodology, its individual elements or several methodology elements in a particular organization when carrying out specific projects and creating specific products. Therefore, the creation of a business process for software development based on one of the existing methodologies is the first and most important task of a company that wishes to be engaged in creating software (for external or own customers).
Gravum software development company offers advice based on our own experience in the relationship between business process modeling and software development.
Roles in a Business Process
- makes plans;
- monitors the implementation of plans;
- works with the customers;
- assesses the duration and complexity of tasks in the planning process;
- distributes and controls work within the group;
- creates conceptual architecture of the solution;
- organizes the collection of customer requirements;
- monitors compliance with the business development process.
- responsible for solution architecture and its compliance with solution requirements;
- performs code quality control, monitors the compliance with its design decisions on architecture;
- acts as repository of information on the solution architecture;
- participates in the formation of plans and the assessment of the complexity and duration of tasks;
- participates in complex testing.
- develops a work plan;
- takes care of functionality development;
- performs quality control and correction of errors in the code;
- performs initial testing and participates in complex code testing.
- performs functionality testing;
- writes Unit tests;
- participates in the development of test plans.
- performs assembly and release of the version;
- prepares supporting documents for the version.
Business Process Modeling Software Development Scheme
The scheme involves members of the project team according to the roles above. The business process includes five work circles.
This means the registration of requirements for business process reengineering software development. In this case, a requirement is any formally described condition that the created solution must satisfy.
All requirements are divided into two groups in terms of the approach to their implementation:
- small. The decision on implementation is made by the team leader by assigning a requirement to the appropriate developer;
- medium and large – made on the basis of ready-made solutions or analysis of work within the framework of a technical project.
Medium Term Planning
A decision is made on the implementation of reasonable requirements. They are prioritized, and it is decided which version the requirements should fall into depending on the priority.
The distribution of requirements takes place over several versions with a time interval of up to six months. As a result, a medium-term plan is drawn up, which is a list of requirements to be implemented in future versions.
According to the work plan, the Analyst performs an analytical study of the requirement and draws up a technical project with a description of the logic for the requirement implementation.
After the preparation and approval of the technical project, the requirement is marked as ready to be included in the development plan version.
Version Development Stage
It includes iteration of development: from planning to release.
- When planning work, the project team reviews the requirements, choosing those that:
- should be implemented in the framework of this version in accordance with the medium-term plan;
- for which the analytical study has been completed.
2. After the requirements have been identified, a detailed development plan for this version is drawn up, which includes all types of work.
3. Then, according to the plan, the Developer and the Architect create the working draft on the basis of the technical project. After approval, the Developer proceeds with its implementation, and the Architect updates the architectural model of the solution in accordance with the detailed design.
4. Sufficiently large requirements are implemented in several parts. Once a part is developed, it is automatically tested and checked by the Architect. If defects are detected, the Developer fixes them.
5. In case of successful conceptual testing, the Developer proceeds with the implementation of the requirements in accordance with the version work plan.
6. After agreeing on new functionality, the Analyst updates the user documentation for the solution.
7. After all the improvements are implemented, the Build Engineer builds the version and generates an accompanying document with a description of the version parameters.
8. The Tester checks the assembled version according to the plan developed by the Analyst. Identified errors are recorded and eliminated by the Developers. If necessary, the working draft and the architectural model are modified.
9. Once the errors are resolved, the testing is repeated. After a decision to release a version has been made, a Build engineer prepares distributions, an accompanying document, and passes it on for deployment.
10. After the release of the version, the work under this iteration is considered completed and work on the next version begins.
Stage of Minor Improvements
All minor improvements are divided into two groups:
- with normal priority – are included in the next major version;
- with critical priority – an intermediate version is issued for them by making the required changes to the instance with the code of the currently deployed version.
- The Team Leader analyzes the development load of the group and takes the decision to implement minor improvements with a normal priority. Developers who are the least loaded on the implementation of planned improvements according to the version are engaged in making minor improvements with a normal priority.
- After minor improvements are done with a normal priority, they are released with the next major version.
- The decision to finalize with critical priority is taken by the Project Manager together with the Team Leader. In this case, the Developer who is the most familiar with the problem may temporarily switch from planned work to its elimination.
- After critical minor improvements are done, the intermediate version release procedure is started. The Build Engineer starts assembly and also prepares a Supporting Document, indicating the number of this intermediate version and a list of critical minor improvements eliminated in it.
- After the release of the interim version, the Gravum software development company developers make the final changes, corresponding to critical minor improvements, to the main working version.