스크랩: 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

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s