스크랩: Top 5 Embedded Software Problem Areas


Safety critical관점에서 보면, 결론부터 말하면 Top 5에 들어갈 필요가 없는 항목들이 아닌가 싶다.

(1) How is your code complexity?

코드 복잡도는 control flow, data flow complexity, class/component coupling/cohesion등으로 지표화를 할 수는 있다. 단 criteria를 정하기가 애매하다. 그런데, 그렇다고 해도 safety-critical관점에서는 구체적으로 요구하는 표준은 없다. 그래서.. 그냥 무시해도. 다만 고객이나 평가자가 사전 요구했다면 얘긴 달라짐.

(2) How do you know your real time code will meet its deadlines?

deadline을 만족시키는 것을 보이는 것은 어려운 일이긴 하지만, 약간의 희생을 감수하고 충분한 margin을 두면 괜찮지 않겠는가 생각한다.

(3) How do you know your software quality is good enough?

safety critical영역의 approval/certification 관점에서, metric관점의 뭔가를 요구하진 않는다. 그래서.. 별로 흥미가 없다.

(4) Is your software process methodical and rigorous enough?

표준에서 정의했으니까, 별 문제 없다. 이 질문은 표준의 정의가 유효한가에 대한 것인가? 사실 그것은 공학/과학의 영역이 아니라서 어떻게 정하더라도 그 결정의 타당성을 증명하긴 어렵다.

(5) What about dependability aspects?

엄밀하게 따지면 소프트웨어의 영역은 아니다. 임베디드 소프트웨어가 약간 박쥐 같아 보일 수는 있을지라도 그래도 이건 시스템 영역으로 둘 수 있을 거 같다.

Several times a year I fly or drive (or webex) to visit an embedded system design team and give them some feedback on their embedded software. I’ve done this perhaps 175 times so far (and counting). Every project is different and I ask different questions every time. But the following are the top five areas…

방법: Top 5 Embedded Software Problem Areas — Better Embedded System SW

 

Advertisements

답글 남기기

아래 항목을 채우거나 오른쪽 아이콘 중 하나를 클릭하여 로그 인 하세요:

WordPress.com 로고

WordPress.com의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Twitter 사진

Twitter의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Facebook 사진

Facebook의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Google+ photo

Google+의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

%s에 연결하는 중