“나이 40 넘어가니..이제 갈 회사도 없고..” 아웃스탠딩


요약

  1. 젊었을때 현재의 지위가 유지되고 봉급이 점점 올라갈거라는 기대를 버려라.
  2. 나이들어서 몸이 불편해지기 전에 관리를 잘하자. (몸이 말을 안들으면 심리적으로 위축되고 실적에도 영향을 미침)
  3. 세상은 변하므로 젊을때부터 새로운 것을 배우는 것을 게을리하지 말자(나이들면 더 배우기 싫어짐)
  4. 외모관리에도 어느정도 신경은 쓰고
  5. 회사 내외 유능한 분들과 교류
  6. 40대 갑자기 돈줄이 끊어질 것(!)에 대비하여 돈을 모아놓는다

 

이래저래 agility가 필요한 시대다.

원문 링크

 

Advertisements

A case of a mess of development due to an unclear understanding of the development process(개발 프로세스의 불명확한 이해로 인해 발생되는 엉망진창 개발 사례)


korean version is below. 한국어 버전은 아래에.

It is also important to have good separation of system and software levels, and it is also important to separate Requirement and Design. Even if it is not a sub-system, it can be regarded as a sub-system, or if it is recognized as a requirement even though it is not a requirement, it can be regarded as a problem at that time. However, serious problems may arise later in the process development or verification and validation view.

Possible problems

The process can not be observed. You think that the defined process is difficult or impossible to apply. For example:

  1. Requirements also become obscure. You may have problems that you do not know how to implement and how to verify.
  2. There is a problem with traceability. Direct / indirect tracking becomes difficult, and it does not have derivative properties.
  3. It can not be tested. Obviously, the requirements are identified and the test environment is set up to verify at that level, but it becomes impossible to observe and test becomes impossible.
    Usually this happens and the procedure is ignored. The administrative procedures are distorted and unrealistic. So engineers think that there is no obligation to adhere to this procedure.

 

System level 및 Software level을 잘 분리하는 것도 중요하고, Requirement 및 Design을 잘 분리하는 것도 중요하다. Sub-system이 아님에도 불구하고 sub-system으로 인식하거나, requirement가 아님에도 requirement로 인식하게 되면 그 당시에는 별 문제가 없는 것으로 여겨질 수 있다. 하지만 나중에 프로세스에 따른 개발 혹은 Verification 및 Validation관점에서 심각한 문제가 발생할 수 있다.

발생할 수 있는 문제

프로세스대로 준수할 수 없게 된다. 정의된 Process가 적용하기 어렵거나 불가능하다고 생각하게 된다. 예를 들면 다음과 같은 것들이 있다.

  1. 요구사항도 애매해진다. 어떻게 구현해야 할지, 어떻게 검증해야 할지 잘 모르는 문제가 생길 수 있다.
  2. 추적성 관련 문제가 생긴다. 직접/간접적 추적이 어렵게 되고, 그렇다고 파생 속성을 지니지도 않는데 애매하게 된다.
  3. 시험할 수 없다. 분명 요구사항으로 식별이 되어서 해당 level로 검증하기 위해 시험 환경을 꾸몄으나, observable할 수 없게되어 시험이 불가능하게 된다.
  4. 보통 이렇게 되면 절차도 무시하게 되기 마련이다. 관리적인 측면에서의 업무 절차가 꼬이게 되고, 현실적이지 않게 된다. 그래서 엔지니어들은 이 절차를 굳이 준수해야 할 의무가 없다는 생각을 하게 된다.