At least your evaluation period is short. Longer periods (e.g. quarterly or longer) with the type of system your boss came up with are subject to moving targets, that is, the core target tasks can change as the needs of the organization changes. Then what happens to your evaluation? Target tasks are not met because they're suddenly de-prioritized, but someone forgot to update the evaluation tasks. That's a pretty awful system for longer periods. With a monthly evaluation, it's not so bad, to be honest, because tasks may not change quite so quickly.
Yes, I've seen these types of systems used at other companies. I've never seen monthly, though. I've seen quarterly and yearly.
That said, in my opinion, any evaluation system where the boss is shifting their responsibility onto a subordinate is a bad system. It is THEIR responsibility to evaluate you, not the other way around. That's why THEY are the boss and that's what's in THEIR job description. It is not in the job description (typically) of a software developer to evaluate themselves, their team members, or anybody else in an official capacity, and especially to determine whether incentives are paid out or not.
In software development, it is actually really hard to come up with a good evaluation system. Managers are often terrible at evaluating other people's performance. It's just the way it is. Because of that, they typically resort to some method to measure performance. In some companies, it's by the number of bugs fixed or the number of projects completed. In your case, it's in the core target task(s). I assume your tasks are shorter than one month, because if they're not, that throws the whole thing off. Again, the reason this is done is because managers need some sort of metric to do an evaluation with.
In your case, there's a possibility that your boss was tasked to come up with a way by the higher ups since software development doesn't necessarily fit the standard way to measure things. Sales people are evaluated on number of closed deals or amount of money brought in by new sales. Customer service reps are evaluated by number of tickets resolved, or by feedback from surveys sent to clients. Tech support are evaluated by number of tickets closed, and timeliness of closing them. How do you measure a software developer? It's not so simple since projects can go on and on and on. So, the obvious things are number of bugs fixed or completing target tasks on time. These might not be the RIGHT things, but they are the most obvious on the surface.