Thanks to everyone who attended my talk at ESC SV! There were about 80 attendees, and I especially appreciated the many questions and insightful comments from the audience.
The organizers ran out of handouts, so I'm posting the handout Acrobat file so everyone can get a copy. This copy has been updated to include some last-minute changes I made right before the talk. It summarizes a lot of the areas covered by my book:
Avoiding the Top 43 Embedded Software Risks (handouts), Phil Koopman, ESC SV, May 2011
http://www.ece.cmu.edu/~koopman/pubs/koopman11_escsv_handouts.pdf (5.7 MB, Acrobat format)
You can also see the accompanying paper at this link.
Enjoy!
Tuesday, May 3, 2011
2 comments:
Please send me your comments. I read all of them, and I appreciate them. To control spam I manually approve comments before they show up. It might take a while to respond. I appreciate generic "I like this post" comments, but I don't publish non-substantive comments like that.
If you prefer, or want a personal response, you can send e-mail to comments@koopman.us.
If you want a personal response please make sure to include your e-mail reply address. Thanks!
Subscribe to:
Post Comments (Atom)
Static Analysis Ranked Defect List
Crazy idea of the day: Static Analysis Ranked Defect List. Here is a software analysis tool feature request/product idea: So many times we...
-
It is common to see small helper functions implemented as macros, especially in older C code. Everyone seems to do it. But you should ... -
(If you want to know more, see my Webinar on CRCs and checksums based on work sponsored by the FAA.) If you are looking for a lightwei... -
Oct 3, 2014: updated with video of the lecture Here is my case study talk on the Toyota unintended acceleration cases that have been in ...
Thanks for sharing the handout!I found your talk is quite innovated and have good matches with the handout.Perfect!
ReplyDeleteDear Sir
ReplyDeleteI am in full agreement with your observations that the main problem areas are process related rather than technology related. However, I have different opinions on few topics that you mentioned in your papers. First, the “High requirements churn”: I think that the requirements change which takes place during the course of a project should be considered as a “constraint.” The high rate of requirements change can be controlled by educating the customer using the prior experience of working with similar products and creating awareness in the customer about the time and cost escalation due to requirements change. This helps the customer organize and freeze the requirements or at least minimize the changes. In my view, the risk is in not having proper requirement management techniques rather than the requirement change itself.
Second, “High people turnover”: Reasons for people turnover also include better compensation, interesting job descriptions and growth opportunities. So people can change jobs even if they are not abused. The Project manager can minimize this risk by knowledge retention using strict process, check lists, maintaining documents and auditing the project. So I consider poor project management or failure of knowledge management as the risk rather than employee turnover.
Third, “Too much assembly language”: Since a program or an algorithm can be coded in a number of ways in a high level language, the efficiency of a compiler is subjective. The compiler cannot compensate for a poorly written program in the high level language. Many a times, the compilers do not make use of the special instruction set of the architecture for producing efficient code. Though the high level programs written intelligently (i.e. considering the microprocessor architecture and the instruction-set) can produce the code that is as efficient as the assembly code, availability of such coding skills is an issue. An average assembly program is better than a highly compiler-optimized, poorly written program in high level language. Problems related to maintainability and readability with the assembly language can be taken care of by adopting coding standards, adding comments and maintaining documentation, which are easier to implement than finding good programming skills. However, considering the advantages of high level language over assembly, a mix of both can produce the best program i.e. coding the main control with high level language and using assembly for time-critical and computation-intensive modules (e.g. CRC, ISR, encryption/decryption algorithms). Since the proportion of assembly code is usually very small (about 5-10%) compared to high level language modules, porting the code to a different architecture doesn’t pose a big problem. In my opinion, modules of assembly language programs are very much essential for overall efficiency of the embedded software and cannot be renounced.
Regards,
Girish