Make software efforts visible

Weeks and months pass, and the software just keeps getting unfinished. Are you familiar with this problem? Then perhaps this article can help. Statements like "we're at about 80 percent completion" or "we need another one or two months" should be treated with caution and are usually completely unfounded.

Why is it so difficult to determine software costs?

The relationship between software developers and project managers isn't always easy. Software developers have their own language and often express themselves in a way that's difficult for the project manager to understand. This can lead to the project manager being unable to understand what the software developer is doing. They hope the software developer will do their job and complete the software by a deadline. However, this assumption doesn't usually hold true. The problem is that software developers themselves lack the methods to conduct estimations. Especially with software, forgotten work packages can cause effort to explode.

How do you get qualified statements about the costs?

A software specification is required as the basis for a qualified statement. This specification must contain the requirements for the software system. A software architecture is created based on this specification. The software system usually consists of software running on a processor. The software system is then hierarchically broken down into software items and finally into software units. The software unit represents the smallest unit that cannot be further subdivided from an architectural perspective. The units are therefore the individual building blocks of the software. The software architecture can then be used to determine effort and plan tasks.

For each piece of software, specific activities must be performed. These activities are based on the software development plan and the software security class. It's best to present the activities in a table. This allows you to measure progress. If you want to omit individual activities for certain units (e.g., unit tests), you can, of course, indicate this in the table. Based on this table, you can also estimate the effort required for the remaining work. Don't forget the additional tasks that arise (software system tests, integration, bug fixing, etc.). However, the table initially provides an important contribution to effort estimates.

Conclusion

When estimating software effort, it's recommended to have a table with all software units and their planned activities. This will give you a good overview of the status of your software development.