Category Archives: Automotive SPICE

Workload estimation(작업량 추정)

한국어는 아래

In order to do everything, you need to know:

  • what you need to do,
  • how set the order of the tasks,
  • who should do the work, and
  • how long it takes.

The reason that the work is delayed or the quality of work is severely damaged is that job estimation activity is skipped

Looking at a recent book whose title is ‘team of teams’, I doubt ‘is this always right?’ Although it is doubtful, basically, most of the things of the non-complex world around us work well in this way.

That’s why I’m working on a project which is not related to software certification project, I’m participating in this way. Although I participated in the beginning of the assignment, I didn’t participate in a resource management plan that was very, very, very very, very very important in my assignment planning process, so it was quite difficult to work in a poorly established environment.

At that time, it could be a variable which is now fixed, and it would be useless to say that the constant had to be changed in order to complete.

Here, in fact, the estimation of the workload at the concept stage was already wrong, and there was a problem with resource allocation. The effect will continue to occur until the task is completed. As if the cesium accumulated in the human body continuously emitted radioactivity and affect the human body. (Is Japan ok now? -_-)

The method of estimating the workloads can be different depending on who carries out the work. So it is necessary to communicate with persons who will be assigned. Also, if there are variations that can occur here, depending on whether I have full control over the person in charge (i.e. whether I am a direct boss, fully penetrating the person’s schedule, and scheduling the person’s work) And can vary depending on how much the person can devote to the work (whether I am not interested in it, or whether I do my best to do nothing until it is not fired) is.

Because of these various variables, there is no formula to accurately calculate or determine workload. It is just an estimation.

In SW development, estimation is done in the following way.

  1. Refer to projects you have done in the past.

  2. Estimate considering velocity of the ongoing task. (In this case, monitoring activity is required to measure the progress speed.)

If there is no data to refer to, do atomic decomposition. Then, each workload is evaluated relative to each other. For example

T1 = 5 * t2

T2 = 3 * t3

T10 = n

T1 takes five times longer than t2. It is precisely five days or five weeks.

When you compare each other in this way and do a relative evaluation, you can maintain a balance between the workloads. Of course, several people participate in this evaluation. Participants are those who will eventually do the work, and because they are not assigned to ‘myself’ in the work, they do not selfishly increase their workload. And because it determines the ‘relative’ amount of work, it is 5n rather than 5days, so you can be willing, honest, and sincere to participate in decision making.

At the end, determine the unit of n (whether the unit is 1 day, 1 hour, or 2 days) and assign the workforce to do the work.

Of course, it will take time, but even though you can get the best efficiency, it will be much better than the time constant and the variables become constants, and these things become constraints and constantly damage the project schedule and quality.


모든 일을 하기 위해서는 어떤 작업을 해야 하는지를 알아야 하고, 작업의 순서를 정해야 하고,  그 작업을 누가 해야 하고, 그 작업이 얼마나 걸리는지를 알아야 한다. 보통 일을 하다가 일정이 지연되거나 일의 퀄리티가 심각하게 훼손되는 것은 이 작업을 하지 않기 때문이다.

최근에 본 team of teams 책을 보고, 이런 생각이 항상 옳은건가? 하는 의문이 들기는 하지만, 기본적으로 우리 주변의 비복잡계 세상의 일들은 대부분 이런식으로 하면 잘 먹힌다.

그래서 지금 참여하고 있는 소프트웨어 인증이 아닌 다른 프로젝트에서도 이런 방식으로 일을 하고 있다. 나름 그 과제의 초반에 참여하기는 했지만 과제 기획과정에서 매우매우매우매우매우매우매우매우매우 중요한 자원관리 계획에는 참여를 하지 못했기 때문에 판이 짜여진 상황에서 일을 하려니 일하기가 꽤 어려웠다.

그 당시에서 변경가능한 사항들이 참여하는 시점에서는 고정불변의 상수가 된 시점이었고, 그 일을 하기 위해서는 그 constant가 다른 값이어야 한다고 아무리 얘기를 해도 소용이 없는 상황이 된 것이다.

여기서 사실 concept단계에서의 작업량 추정이 이미 잘못되어 있었던 것이고, 그에 따라 자원 배분에 문제가 있었던 것이다. 그에 따른 영향은 과제가 종료될 때까지 지속적으로 발생한다. 마치 인체에 축적된 세슘이 지속적으로 방사능을 배출해서 인체에 영향을 끼치는 것과 비슷한 이치라고나 할까..(일본은 이제 괜찮은가? -_-)

작업량 추정의 방식은 그 작업을 누가 하느냐에 따라서도 기간이 달라질 수 있다. 그래서 작업담당자와의 의사소통이 필요하다. 또 여기서 발생할 수 있는 variation이 있다면, 그 담당자를 내가 온전히 control할 수 있는 관계인지(즉 내가 직속 상사이고, 그 사람의 스케줄에 대해서 완전히 꿰뚫고 있는지, 그리고 그 사람의 일을 스케줄링이 가능한지) 아닌지에 따라서 달라질 수 있으며, 그 사람이 얼마나 그 작업에 헌신할 수 있는지(본인은 그 일에 관심이 있는 것이 아니라, 짤리지 않을때까지 최선을 다해서 아무 일도 하지 않으려는 본성인지의 여부)에 따라서도 달라질 수 있다.

이런 여러가지 변수가 있기 때문에 작업량을 정확하게 계산하거나 결정하는 공식은 존재하지 않는다. 다만 추정할 뿐이다.

SW개발에서는 다음과 같은 방식으로 추정을 한다.

  1. 과거에 수행했던 프로젝트를 참조한다.

  2. 현재 진행중인 과제의 진행 속도를 참조한다. (이 경우 진행속도를 측정하기 위한 모니터링 활동이 필요하다.)

참조할 만한 데이터가 전혀 없는 경우 작업을 atomic decomposition을 한다. 그리고 각 작업량에 대한 상대평가를 한다. 예를 들면

t1 = 5*t2

t2 = 3*t3

t10 = n

t1은 t2보다 5배 작업 기간이 오래걸린다. 정확하게 5일인지 5주인지는 모르는 것이다.

이런 방식으로 서로를 비교하면서 상대평가를 하게 되면, 그 작업량들간에는 균형을 유지할 수 있게 된다. 물론 이 상대평가를 할 때에는 여러명이 참여를 한다. 참여자는 결국에는 그 일을 하게 될 사람들이고, 그 일에 대해 ‘본인’에게 할당된 것이 아니기 때문에 이기적으로 작업량을 늘리거나 하지 않게 된다. 그리고 어디까지 ‘상대적’ 작업량을 결정하기 때문에 5일이 아닌 5n을 결정하는 것이기 때문에 부담없이, 정직하고, 진실하게 의사결정에 참여할 수 있게 된다.

맨 마지막에는 n의 단위를 결정하고(1일인지, 1시간인지, 2일인지…), 그 일을 수행할 인력을 배정한다.

물론 시간이 소요되기는 하지만, 최적의 효율을 낼 수 있는데도 불구하고 시간이 흘러 변수가 상수가 되고, 그런 것들이 제약사항이 되어 프로젝트의 일정과 퀄리티에 지속적으로 데미지를 주는 것보다야 훨씬 나을 것이다.



It is not quite convenient, but redmine can be applied as a management system.(딱히 편리하다고는 볼 수 없으나, 관리 시스템으로 redmine을 적용해 볼 수도 있다.)

한글 버전은 아래로..

To build the process, I was troubled with management tools. As a matter of fact, my client did not consider the cost of the tool and I wanted to build a management system to make them work as a consultant.

I wondered what … I thought to solve it for months. Of course it should be a free tool. And It must be working. It should be supported in a somewhat administrative way.
I have been wondering if redmine, which I have used as a personal assistant for several years, can meet this requirement.

In fact, this was an issue that came up when discussing the A-SMGCS project, which used a task management system using redmine a few years ago.

At that time I communicated whether similar functions would be possible, and as a result, comments were ignored, and afterwards, I said, ‘Oh … I think it will.’

In conclusion, it is. Traceability, and change management of everything from requirements to design and testing procedures.

Compared to commercial tools, you will have to accept the inconvenience.

For people who build a management system using free tools, how about that way? 

프로세스를 구축하기 위해, 관리 도구를 고민했다. 당연 중소기업은 그 도구에 대한 비용을 고려하지 않았고.. 컨설턴트로서 그나마 working이 되도록 하기 위한 관리 시스템은 구축을 해주고 싶었다.

어떤 방법이 있을지…몇달을 고민을 했다. 당연히 무료도구여야 한다. 그리고 나름 말이 되도록 돌아가야 한다. 그리고 어느정도 관리적인 차원에서 지원이 되어야 한다.

몇년간 개인 비서로 사용해온 redmine을 이 요구사항을 만족시킬 수 있을지에 대해서 고민했다.

사실 이 내용은 몇년 전에 redmine을 이용한 과제 관리 시스템을 사용했던 A-SMGCS과제 논의시 나왔던 이슈였다.

그 당시 나는 비슷한 기능이 가능하지 않을지에 대해서 의견을 전달했고, 결과적으로는 의견은 묵살당했고, 그 뒤로 ‘아..될 거 같은데..’하고 말았던 적이 있다.

결론을 말하자면, 된다. 추적 기능을 넣을 수 있고, 요구사항부터 설계, 시험절차 등에 대한 모든 사항들에 대한 변경 관리등이 가능하다.

상용도구에 비해 불편한 점은 감수해야 할 것이다.

나름 되긴 된다.

무료 도구를 이용해서 관리 시스템을 구축하는 사람들은 고민을 해보시길…^^

어떻게 하느냐고 물으신다면….

[콜드브루의 모든 것]②대량생산의 비밀

Unit testing is useless in some aspects(단위 시험은 어떤 측면에서 쓸데없다)

한글버전은 아래로..

I think the title is somewhat irritating. I admit it. It is an exaggerated expression. But it is also true.

I think there is nothing better than a unit test. It is a very good practice if you have completed the unit test to see if you are doing what you intended to do.

But if you think about the quality of the product by a third party, the position will change. In a real consulting project, I found that it is quite tricky for a third party auditor to make a technical assessment of this part.

That’s true.

When we say that the coverage measurement is not a coverage analysis, the unit test ‘s uselessness shines. For example, suppose you create a calculator program that has an add / subtract function. In terms of coverage, 1 + 1, 1-1, 1/1, 1 * 1 will achieve 100% by default.

But …. Do you think you will use the test procedure and write the test results in a normal unit test? Or do you think you will see the test results and change the test procedure? Eh ? What are you talking about?

In the process, it is important to write a test procedure, to test it, to get test results, and to review the results. But ……………. There might be a developer who does not …

It is possible to use a trick somewhat different from the intended direction in the standard. However, the problem is that it is very difficult to carry out a technical examination of this part in the case of a unit test. Is it possible for a third party assessor to understand and check the logic of your code ?

What’s even worse is that there is a shortcut to achieve this if you have a goal to achieve 100% of MC / DC as well as code coverage … This is not the intention of the person who originally thought of this method.

This leads to the conclusion that it is not possible to check whether the unit test was carried out with authenticity. It is not that much if it is aimed at making sure that one trick is properly passed through one by one. Besides, it’s hard for the assessor to catch that part.

If then, why we have to force unit test?

In that respect, the requirement based test method overcomes this problem. In addition, it is possible to check how well the requirements are written, and the examination of the test procedures and the results of those parts can be better done.

From that point of view, standards that require unit testing need to be refreshed


제목이 약간 자극적이라는 생각이 든다. 인정한다. 과장된 표현이다. 하지만, 사실이기도 하다.

단위 시험을 제대로 한다면 그것만큼 훌륭한 툴은 없다고 생각한다. 설계자의 의도에 맞는 행동을 하는지의 여부를 단위시험까지 완벽하게 되었다면 매우 훌륭한 practice임에는 틀림이 없다.

하지만 제3자가 그 제품에 대한 quality를 평가해야 하는 입장에서 생각해보면 입장이 달라진다. 실제 컨설팅 프로젝트에서 이 부분에 대해 제 3자 auditor가 이 부분에 대한 기술적인 평가를 하는 것이 상당히 까다롭다는 것을 발견했다.

실제로 그렇다.

coverage analysis가 아닌 coverage 측정 행위를 한다고 했을때, unit 시험의 무용론은 빛을 발하게 된다. 예를 들어 가감승제 기능이 있는 연산기 프로그램을 만든다고 가정하자. coverage 관점에서 1+1, 1-1, 1/1, 1*1을 하면 기본적으로 100%를 달성하게 될 것이다.

그런데…. 보통의 단위 시험을 시험 절차를 쓰고 시험 결과를 쓴다고 생각하는가? 아니면 시험 결과 나온 것을 보고 시험 절차를 변경한다고 생각하는가? 엥 ? 이게 무슨 소리냐고?

프로세스 상으로는 시험 절차를 쓰고, 시험을 해서 시험 결과가 나오고, 그 결과를 검토하는 것이 정석이다. 그런데……………. 그렇게 하지 않는 개발업체도 있을 수 있다는 말이다…

표준에서 의도했던 방향과는 약간 다르게 trick을 쓸 수 있는 것이다. 그런데, 문제는 단위 시험의 경우 이 부분에 대한 기술적 검토를 하는 것이 굉장히 어렵다는 것이다. 코드의 로직을 다 이해하고 점검해야 하는데, 과연 제 3자 평가자가 그 정도까지 할까?

게다가 더 최악인 점은…. Code coverage뿐만 아니라 MC/DC까지도 100%를 달성하고자 하는 목표만 있다면, 이를 달성하기 위한 지름길이 있다는 점이다… 이 또한 당초 이 방법을 생각한 사람의 의도한 것이 아닐 것이다.

상황이 이렇다보니 unit test에 대한 진정성을 가지고 수행했는지에 대한 점검이 원천적으로 불가능하다는 결론에 다다르게 된다. 어차피 꼼수로 하나 제대로 하나 통과받도록 하기 위한 목적이라면 별것도 아니라는 얘기다. 게다가 평가자가 그 부분을 잡기도 힘들고..

그럴거면 unit test라는 것을 왜 억지로 하도록 해야 하냐 이거다.

그런 점에서 requirement based test방법은 이런 문제점을 극복한다. 게다가 requirement가 얼마나 잘 작성되었는지를 점검할 수도 있으며, 그 부분에 대한 시험 절차와 결과의 검토가 더 잘 이루어질 수 있다.

그런점에서 봤을때, unit test를 요구하는 표준들은 좀 반성을 해야 할 필요가 있다고 생각한다…