Tag Archives: improvement

Stateflow model 리팩토링


Power shift 2nd 과제 경험담이다.

Stateflow 모델링 전공자로서, Stateflow만으로 모든 것을 다 해결해 줄 수 있다는 방식의 사고방식을 난 지지하지 않는다.
heterogeneous방식의 모델링이 훨씬 효과적이고 그렇게 되어야 한다고 생각한다.

즉 여러 방식의 모델링 표기방식을 혼합하여 사용하는 것이 더 가치가 있다고 생각한다.

UML의 view가 하나만 있는게 아니듯이 하나의 모델링 방식은 어떤 문제를 해결하기 위해서는 훌륭한 해결책 일 수 있겠으나, 모든 문제를 하나의 방법으로 해결할 수 있는 것은 아니다.

불가능하다는 의미는 아니다. 모든 문제를 한 가지 방식으로 해결하려는 방식은 불편할 수 있다는 의미다.

이것으로 나의 정체를 드러내고, 과제 경험담을 말하자면,,

변속기 모델이 모델 자체로는 직관적인 듯 했고, 조오금 이해하기 어려운 측면도 있었으나, 익숙해지니까 쏙쏙 이해가 되었음. 문제는 code생성을 고려해서 모델링의 최적화가 필요할 수 있었다는 점이고, 일부 behavior의 경우 차라리 coding으로 구현한 것이 훨씬 좋았을 것 같다는 것이다.

설계자가 의도한 것은 아니겠으나, 모델링에서도 quality를 위한 metric을 정의해야 하고, 그 기준에 부합한 모델링이 되도록 노력해야 할 필요가 있다는 점이다. 많은 모델링을 보다보면 그런 기준을 정의할 안목이 생길텐데, 그런 일 좀 쏟아졌으면 좋겠네…ㅎㅎ

Advertisements

Engineering effort및 일정을 최소화하기 위한 프로젝트 관리


비용 및 일정을 줄이는 것은 고객의 니즈와 당신의 조직에게 아주 효과적인 방법이다.

이 전략을 적용하기 위한 지표들로는 다음과 같은 것들이 있을 수 있다.

  • engineering months by product/component/activity
  • engineering months by defects/enhancements
  • defect and enhancement request counts
  • counts of remaining critical and serious defects
  • calendar time by phase and activity
  • code stability(% of code changed)
  • size(NCSS, tasks, objects, components)
중요 특징들 엔지니어링 노력 및 스케줄의 최소화
중요 비즈니스 요인 신제품 개발에 대한 경쟁력 압력 및 비용 제어
가장 중요한 시점 여러 경쟁사들이 제품을 만든다면 당신들은 이윤이 나는 제품을 더 팔아야 한다.
특징적 요소들 인도 날짜 및 노력에 집중함
가장 시각적 메트릭 날짜, 엔지니어링 노력, 결함
전략을 이끌어나가기 위한 그룹 회사 관리 부서
고객과 직접적 접촉을 해야 하는 그룹 마케팅/공장 고객 지원
너무 제한적 집중으로 인한 잠재적 문제점 결함 백로그는 관리가 안될 수 있다; 고객과 개발자들이 혼란스러울 수 있다.

노력과 시간을 줄이기 위한 방법?

  • 대부분의 시간을 소비하는 활동들을 개선한다.
  • 자주 defect가 발생하는 영역에 집중한다.
  • 대부분의 effort를 하는 defect에 집중한다.

어디서 비용이 많이 발생하는가?
– 알고 싶으면 tracking이 필요하다. 프로젝트 모니터링은 프로세스 개선을 위한 첫걸음이다.

개발 단계에 따른 엔지니어링 노력의 비율

Firmware
(31 projects)
Systems
(48 projects)
Applications
(53 projects)
Requirements 15% 14% 22%
Design 21% 19% 16%
Implementation 39% 30% 34%
Test 25% 37% 28%

위의 표는 엔지니어링 effort를 개선하기 위한 목적 외에도 여러가지 목적을 위해 사용될 수 있을 것 같다.  저 표를 보고 “어? 우리는 저렇게 일 안하는데? 라고 하는 조직이 많을 텐데, 그렇다고 하면 그 둘 간의 gap으로 인하여 어떤 차이가 있는지를 분석해보는 것도 해당 조직의 생산성을 높일 수 있는 방법이 될 수 있을 것으로 보인다.

또한 위의 표로부터 project의 기간 산정을 하는데 매우 유용한 reference가 될  수도 있다는 점이다. 비례식을 적용하여 requirement를 완성하는데 5달이 걸렸다면 대충 requirement의 개발 시간 비율을 20%로 가정하면, 25개월, 즉 2년 1개월이 프로젝트를 수행하는데 필요한 시간이라는 것을 알 수도 있을 것이다.

비용을 줄일 수 있는 새로운 방법을 학습하기

엔지니어들은 잘 알고 있을 수도 있겠지만, 신기술을 도입하면 마치 비용이 줄어드는 환상을 갖는 비전문가이면서 높은 자리에 있는 분들을 생각하게 되는 섹션이다. in the long run, 아마도 그렇게 될 수 있을 것으로 생각한다. 근데, 고위직에 있는 분들이 모두 그런 투자가 장기적 투자를 필요로 한다는 사실은 잘 모르고 있는 듯 하다. (현실과 이상의 gap은 항상 거리가 있다.)

개발 및 시험 스케줄을 줄이기 위한 추적

위의 표에서 보면 코딩 및 시험이 개발 일정의 60%를 차지한다는 것을 알 수 있으므로, 해당 활동에 대한 detail을 추적하여 분석한다.

  • 클래스의 갯수를 추적
  • operation(or method)의 갯수를 추적
  • non-comment source statements(NCSS)를 추적
  • number of defects per hours of testing time
  • amount of test execution time between defects
  • past average times to find and fix defects

Practical Software Metrics for Project Management and Process Improvement


오래되긴 했지만 (1992년) 오래된게 항상 유용하지 않은 것은 아니다.

프로젝트 모니터링을 어떻게 하는지에 대해 궁금하다면 참고할 만한 책이다.

뭘 어떻게 관리를 해야 할지 모르는 사람들에게 추천한다.

의외로 상당히 많은 indicator들을 추출할 수 있다는 사실에 깜짝 놀랄 것이다.