Is there a methodology for preliminary estimation of labor costs for the development of an electronic device?

Question

Electronics

Kind!
Tell me, are there formal methodologies for estimating the cost of a project for the development of electronics?
For software, there are PERT, COCOMOII methodologies, function point method, etc. etc.
Is there something similar for electronics?
I need to make a preliminary calculation of the cost of the project, and I have not been involved in the development of electronics before.

Answer 1

If you have not worked in electronics before, then the probability of success in project evaluation tends to zero, by any methodology.
This picture reflects the reality very well:
In the development of electronics, there is a fairly large amount of research component. It is impossible to plan it, and those who understand this use the PDCA concept, make prototypes, MVP, set the goal not of a ready-made device, but of answering a question.
For example, you take the LIS3DH MEMS accelerometer from ST and put it into your device. It would seem that the device has been produced for almost 10 years, studied up and down, datasheet for 10 pages - where is there to stumble? But in fact, there are enough pitfalls, for example, service registers that are not write-protected. And writing to them can turn the device into a brick. You can say - well, you don’t need to write there. Yes, of course, I will answer, but a serial flash also hangs on SPI, and here's a surprise - the CS of the accelerometer, in addition to allowing the exchange, also works as a service signal for selecting the interface type (SPI / I2C). It is possible that when CS is raised, the I2C address of the accelerometer will get on the bus and garbage will be written to the service registers.
I wrote this to you, so to speak, to confirm my right to categorically answer your question. The described situation met in a real project. Well done guys, they localized and fixed it quickly, but it could have been different. And there are a lot of such stories. And with firmvara and with iron.
So don't rely on Gantt, the waterfall model, and other classic planning methods. I can only give a few tips on how to make a forecast (not an estimate):
- split the project into tasks, tasks into subtasks, subtasks into elementary actions. The higher the degree of decomposition, the more reliable the forecast will be. For example, we split large tasks into subtasks lasting no more than 8 hours.
- Read the SCRUM book. Revolutionary project management method. Agile methodologies are surprisingly well suited to the development of electronics and embedded software
- negotiate with the customer for a phased work: result and payment. First, make a scarf, then run it, so add some more functionality. So you will have control points, and feedback from the customer. It will not work that after six months of work you will make a thing that the client does not need.
- take on small projects