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. 보통 이렇게 되면 절차도 무시하게 되기 마련이다. 관리적인 측면에서의 업무 절차가 꼬이게 되고, 현실적이지 않게 된다. 그래서 엔지니어들은 이 절차를 굳이 준수해야 할 의무가 없다는 생각을 하게 된다.
Advertisements

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

답글 남기기

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

WordPress.com 로고

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

Twitter 사진

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

Facebook 사진

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

Google+ photo

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

%s에 연결하는 중