조직의 변화가 어려운 4가지 이유


improvement는 여러 곳에서 필요하다.
자기자신을 위해서
내가 속한 조직을 위해서
improve하려고 하는 대상 고객을 위해서

다음과 같은 4가지 이유로 변화가 어렵다.
출처: 조직의 변화가 어려운 4가지 이유

1. 익숙한 방식대로 행동하려는 구성원들의 관성 때문이다.

2. 리더만 바뀌면 변화가 쉽게 일어난다는 인식때문이다.

3. 한꺼번에 너무 많은 것을 바꾸려고 하기 때문이다.

4. 구성원의 행동보다는 신념과 가치관을 먼저 바꾸려고 하기 때문이다.

종합해보면 조직 변화가 어려운 원인의 대부분은 구성원의 ‘행동’을 변화시키는 것에 실패하기 때문인 것을 알 수 있다.성공적으로 조직의 변화를 이끌기 위해서는 목표하는 바대로 구성원들의 행동을 바꿀 수 있는 방법에 초점을 맞추고 접근해 나가야 할 필요가 있다.

어려운건 알겠는데, 그렇다면 변화를 일으키기 위해서는 무엇이 필요하고 무엇부터 해야 할까?

출처: LG경제 연구원

구성원 행동 변화를 통한 조직 변화

인간의 행동은 시스템처럼 합리적으로 변하지 않는다. 『스위치』의 저자 칩 히스(Chip Heath) 와 댄 히스(Dan Heath)는 성공적인 행동 변 화를 이끌어내기 위해서는 이성과 감성 모두에 호소할 수 있어야 하고,상황이나 환경 또한 변화시켜야 한다고 주장한다. 개인이 무엇인가 혼자 결심하고 동기부여가 되어 자신이 처한 상황과 맥락을 바꾸는 것은 어렵지만, 기업의 변화를 위해서는 리더와 조직 자체가 이런 역할을 해 줄 수 있을 것이다.관건은 다수의 구성원으로부터 변화된 행동을 이끌어내는 것이다.

●현재 문제되는 행동이 무엇인지를 공유

●구체적인 변화의 모습과 행동 목표 제시

●조직의 시스템, 제도를 변화의 방향과 연계

●변화를 적극적으로 실행하는 타겟 그룹 형성

●저항과 실패 기간을 당연시하고 인내

변화를 위해서는 성공한 창업가의 특징을 고려해 보는 것이 도움이 될 것이다.

Advertisements

Guidelines for Assessing Software Partitioning Protection Schemes


출처: Cast-2

그런데, 아래의 체크리스트만 있다고 만족되는 것은 아니다. 부분적으로 cover된다는 것이고,

다른 reference들도 참조해봐야 한다.

 

카테고리 체크리스트
Time Interrupts를 사용하지 않거나, 사용하는 경우 interrupt가 발생하더라도 task의 올바른 동작을 입증할 수 있다.
무한 루프가 발생하지 않거나 혹 발생하더라도 이를 탐지하고 오류를 처리할 수 있는 매커니즘이 있다.
real time correspondence:
(1) frame overrun이 발생하지 않음을 보장할 수 있다.
(2) real time clock에 의해 task의 동작이 영향을 받지 않음을 입증할 수 있다.
(3) counter/timer corruption이 발생하지 않거나 발생할 경우 이를 처리할 수 있음을 보장할 수 있다.
(4) pipeline and caching에 의해 task의 동작이 영향을 받지 않음을 입증할 수 있다.
Control Flow defects(timing aspects)
(1) 다른 partition이나 보호영역으로 incorrect branching이 발생하지 않음을 보장할 수 있다.
(2) corruption of a jump table으로 인해 task의 동작이 영향을 받지 않음을 입증할 수 있다.
(3) 프로세서 sequence control의 corruption로 인해 task의 동작이 영향을 받지 않음을 입증할 수 있다.
(4) corruption of return addresses가 발생하지 않음을 입증할 수 있다.
(5) unrecoverable hardware state corruption (e.g., mask and halt)가 발생하지 않음을 입증할 수 있다. (혹은 발생시 이를 탐지하고 처리할 수 있음을 보장할 수 있다.
Memory, I/O contention(경합)이 발생하지 않음을 보장할 수 있다.
Data flags가 발생하지 않음을 보장할 수 있다.
Software traps
(1) divide by zero가 발생하지 않음을 보장할 수 있다.
(2) un-implemented instruction가 발생하지 않음을 보장할 수 있다.
(3) specific software interrupt instructions 가 발생하지 않음을 보장할 수 있다.
(4) unrecognized instruction이 없음을 보장할 수 있다.
(5) Recursion termination이 없음을 보장할 수 있다.
Indirect non terminating call loops가 없음을 보장할 수 있다.
Holdup commands (performance hedges)가 없음을 보장할 수 있다.
Deterministic scheduling (processor and communication)임을 보장할 수 있다.
Guaranteed access for each software partition to a prescribed set of hardware resources for a prescribed period of time and at a prescribed rate and, if necessary, at a prescribed point in time을 보장할 수 있다.
Space Loss of input or output data가 없음을 보장할 수 있다.
Corruption of input or output data 의 없음을 보장할 수 있다.
Corruption of internal data의 없음을 보장할 수 있다.
(1) direct or indirect memory writes 의 없음을 보장할 수 있다.
(2) table overrun의 없음을 보장할 수 있다.
(3) incorrect linking의 없음을 보장할 수 있다.
(4) calculations involving time의 없음을 보장할 수 있다.
Delayed data의 없음을 보장할 수 있다.
Program overlays의 없음을 보장할 수 있다.
Buffer sequence (double jeopordy)의 없음을 보장할 수 있다.
External device interaction (e.g. displays)의 없음을 보장할 수 있다.
(1) loss of data (e.g. overwritten)의 없음을 보장할 수 있다.
(2) delayed data의 없음을 보장할 수 있다.
(3) incorrect data (unlikely across systems) 의 없음을 보장할 수 있다.
(4) protocol halts (e.g. ack nacks)의 없음을 보장할 수 있다.
Control Flow defects (space aspects)의 없음을 보장할 수 있다.
(1) incorrect branching into a partition or protected area 의 없음을 보장할 수 있다.
(2) corruption of a jump table (double duty?) 의 없음을 보장할 수 있다.
(3) corruption of the processor sequence control의 없음을 보장할 수 있다.
(4) corruption of return addresses의 없음을 보장할 수 있다.
(5) unrecoverable hardware state corruption (e.g., mask and halt)의 없음을 보장할 수 있다.
Protection of code memory, data memory, registers, and input/output buffers을 보장할 수 있다.
Persistent storage locations (e.g., data memory), assigned to a software partition, write-able only by that partition.  의 없음을 보장할 수 있다.
Context data (e.g., processor registers, CPU-caches) used by a task preserved or flushed as appropriate when control is transferred to another partition.의 없음을 보장할 수 있다.

시스템 요구사항의 고려사항


1. 무결성 및 가용성 고려사항

시스템 요구사항은 무결성(기능 및 운영의 정확함) 및 가용성(기능의 연속성) 양쪽 모두를 언급해야 한다.

  • 무결성: “정확하게 동작한다고 믿을 수 있음을 나타내는 시스템 또는 아이템의 질적 또는 양적 특성(Qualitative or quantitative attribute). 이는 때때로 작업이 정확하게 기준을 충족하지 못하는 확률을 사용하여 표현된다.”
  • 가용성: 시스템 또는 아이템이 적시에 주어진 지점의 작동 상태(functioning state)에 있는 질적 또는 양적 특성. 이는 때때로 시스템이 출력을 제공하지 못하는 확률(즉, unavailability)을 사용하여 표현된다.

무결성의 손실은 시스템의 부정확한 운영을 초래한다. 예는 기본 비행 디스플레이에 교통 충돌 및 회피 시스템(TCAS; traffic collision and avoidance system)부정확한 해결책 조언, 또는 자동 조종 장치 hardover의 잘못된 데이터를 포함한다. 무결성을 위한 설계를 위해, 방지하거나 고장을 무력화(neutralize faults)하기 위해 주로 아키텍처적 완화가 요구된다. 이것은 무결성 결함을 방지하고 또는 이러한 유형의 결함을 보호하기 위해 중복 구현, 파티셔닝, 모니터링, 비유사성 또는 다른 완화 전략의 사용을 포함할 수 있다. 또한, 무결성을 해결하기 위해, 결함 감지 및 응답 또는 결함 방지는 종종 적용될 수 있고 시스템 요구사항으로 파악되어야 한다.

많은 시스템은 가용성의 손실로부터의 보호를 요구한다. 가용성은 기능적 동작이 모든 예측 가능한 사용 조건(정상 및 비정상 상태를 포함하여)하에서 연속적이고 복구 가능 해야 한다는 점에서 무결성과 다르다. 주요 기능은 하드웨어 우발 결함, 데이터 결함 또는 소프트웨어 및 하드웨어 upset 동안 또는 이후에 이용 가능해야 한다.

높은 가용성을 요구하는 시스템 또는 기능은 일반적으로 매우 높은 신뢰성을 가지고 중복 구현을 활용한 장치를 요구한다. 중복 설계가 가용성을 보장하기 위해 사용되면, 그것들은 결함을 견디는 것(tolerate fault)과 결함을 신속하게 탐지하고 복구가 가능해야 한다. 중복 설계를 통합하는 시스템은 일반적으로 중복 관리 및 결함 관리 요구 사항이 있다.

몇 가지 디자인 결정이 무결성과 가용성 모두에 영향을 미칠 수 있음을 유의해야 한다. 이 두 가지는 모두 고려되어야 한다. 예를 들어, 시스템은 가용성을 손상시키지 않고 무결성 결함을 완화 할 필요가 있다. ARP4754의 원래 버전은 비유사성의 사용을 고려할 때 무결성과 가용성 사이의 관계를 나타낸다: “아키텍처 비유사성이 무결성 및 가용성 모두에 영향을 미친다는 점을 주목해야 한다. 무결성의 증가는 가용성의 감소와 연관될 수 있기 때문에, 반대의 경우도 마찬가지로, 특정 응용프로그램은 적합성을 확인하기 위해 두 관점에서 분석되어야 한다.

 

2. 다른 시스템 요구사항에 대한 고려사항

무결성 및 가용성에 대한 문제 외에도, 시스템 명세에서 다음을 포함하여 고려해야 하는 다른 측면들이 있다. 기능 hazard 평가 또는 후속 안전 분석에 의해 나타나는 요구 사항.

  1. 안전 요구사항, 즉, 기능 hazard 평가 또는 후속 안전 분석에 의해 도출된 요구 사항.
  2. 결함 허용은 결함 영역의 식별을 포함한 시스템에 영향을 미친다. 전자 아키텍처와 통합 안전 시스템을 위한 시스템 엔지니어링(BASIS) 컨소시엄은 결함 영역을 “장애가 어디에 위치했는지, 어떻게 발생했는지, 결함 영역 내에서 얼마나 멀리 확장되는지에 관계없이 내부 장애(internal disturbances)는 정확히 하나의 결함으로 계산되는 컴포넌트 세트”로 식별한다.
  3. 어떤 고립 영역(containment regions)에 대한 필요성을 포함한, 정상적인 저하(Graceful degradation) (예, 고장 안전 모드). EASIS는 “고립 영역(containment region)은 각 고장에 의해 부정적인 영향을 받았을 수 있는 컴포넌트의 세트이다. 다시 말해: 방지 영역은 결함 전파가 중단되어야 하는 경계를 정의한다” 라고 설명한다. 예는 비행 표면을 이동하거나 조종사가 응답하기 전에 플래그된 실패한 데이터 전에 자동 조종 장치 결함 감지를 포함한다.
  4. 다음과 같은 에러 감지:
    1. 데이터 확인—범위, fresh, 단락 회로, 개방 회로에서 데이터가 유효한지 확인하기 위해 데이터를 검사하는 것
    2. 중복 데이터의 비교—중복 센서 또는 프로세싱 유닛과 출력을 비교 하는 것
    3. 프로세서와 메모리에서 에러 확인—예를 들어, built-in 테스트를 수행, 워치독 타이머를 사용, ROM 또는 플래시 메모리의 체크섬 계산, built-in 프로세서 예외 사용, 메모리 검사 수행, 또는 RAM 읽기/쓰기 테스트
    4. 통신 모니터링—분산 시스템에서 수신 메시지의 확인을 수행하는 것, 예를 들어, 메시지 제한 시간(message timeout), 메시지 시퀀스 카운터, 또는 체크섬 확인
  5. 검출된 오류의 오류 처리. 오류 처리의 몇 가지 예는 다음과 같다.
    1. 기능을 종료
    2. 성능이 저하된 모드로 진입
    3. 사용자에게 안내 제공
    4. 실패한 시스템과 상호작용하는 다른 시스템에게 메시지 전송
    5. 시스템을 리셋하고 이전 상태로 복귀
    6. 다른 신뢰할 수 있는 데이터 사용(입력 에러가 감지되었을 때)
    7. 에러가 연속 발생시 타임 아웃이나 시스템을 셧다운
  1. 시스템이 하드웨어 오류에 응답하는 방법을 다루는 결함 감지 및 처리 (연속 또는 랜덤 응답과 같은)
  2. 높은 품질 소자를 선택하여 처리(더 높게 지정된 고장 사이의 평균 시간), 전자기 간섭 등에 의한 환경적 영향에 대한 보호, 요구사항에서 특정 금지된 결함을 식별 그리고/또는 구조적 취약성을 제거하여 결함 회피.
  3. 아키텍처 또는 설계에 대한 요구사항(즉, 중복, 비교 확인, 투표 방법). 이것이 요구사항과 설계 사이의 경계를 다소 흐리게 할 수 있지만, 구현 시 고려해야 할 사항은 무엇이든 식별하는 것은 중요하다. 요구사항의 해설은 너무 빨리 설계를 정의하지 않고 설계 고려사항을 식별하는 일반적인 방법이다.
  4. 제조 공정에 대한 요구사항. 이러한 요구 사항은 하드웨어 제조 및 생산 과정의 주요 특성을 문서화.
  5. 기능 제한. 시스템은 임의의 공지 된 또는 원하는 한계에 규정 될 필요가 있다. 예를 들어, 몇 가지 기능은 특정 비행 단계 또는 사용의 범위 동안에만 허용될 수 있다.
  6. 중요한 기능. 이러한 요구사항은 고장으로 인한 중요한 기능의 손실을 방지하기 위해 필요하다.
  7. 결함의 봉쇄 또는 격리를 제공하기 위한 파티셔닝 또는 보호. 덜 중요한 기능은 더 적은 확인 및 검증의 엄격함을 요구하기 때문에 파티셔닝 또는 보호는 확인 및 검증의 노력을 줄이기 위해 사용될 수 있다.
  8. 둘 또는 더 많은 아이템에서 공통 고장을 회피하기 위해 사용될 수 있는 다양성. 다양성의 예는 다른 설계, 알고리즘, 도구(예, 컴파일러) 또는 기술들을 포함한다[5].
  9. 결함 허용을 달성하기 위해 또는 단일점 결함을 회피하기 위해 사용되는 중복. 중복 컴포넌트는 다수의 프로세서, 센서 등을 포함한다.
  10. 조종석 응답 시간, 오류 감지 및 응답, 전원 가동 시간, 재시작 시간 등과 같은 문제를 해결하기 위한 타이밍 관련 요구사항,
  11. 초기화, 콜드 스타트, 웜 스타트 그리고 전원 차단 요구사항을 포함하는 순서(sequence)
  12. 비행 단계, 연관 및 분리된 결정, 모드 선택 등의 모드 및 상태 전이
  13. 필요한 환경적 안전성을 반영하기 위한 환경적 인증 수준. 수준은 시스템의 중요성, 예상된 설치 환경 및 규제 요구 사항에 따라 달라진다. RTCA/ DO-160[ ]는 민간 항공기에 설치된 장비에 대한 환경 인증 절차를 설명한다.
  14. 안전 고려 사항이 적절하게 구현되도록 하기 위하여 필요할 수 있는 시험 규정. 예를 들면 테스트 노력을 지원하기 위한 자극 입력, 데이터 기록, 또는 다른 장비의 인터페이스를 포함한다.
  15. 높은 고도에서 발생하는 방사선의 영향으로부터 항공 시스템을 보호하기 위한 몇 가지 항공 프로젝트에 필요한 단일 및 다중 이벤트 고장 보호(Single and multiple event upset protections). 일반적인 해법의 예는 연속 기본 테스트, 에러 정정 코드, 투표 방식, 및 경화된 하드웨어(hardened hardware)를 포함한다.
  16. 특히 안전 분석 가정을 지원하기 위한 신뢰성 및 유지 관련 고려 사항: 결함 및 관련된 데이터 logging, 시작 테스트 그리고 조작(rigging).
  17. (숨겨진) 잔여 잠재 결함의 가능성을 줄이기 위한 지연 요구사항. 예를 들면 고장 식별 및 유지 보수 또는 built-in 테스트 간격에 대한 경고를 포함한다.
  18. 적절한 시스템 사용을 보장하기 위한 사용자 및 휴먼 인터페이스 요구사항. 인적 요소의 요구를 해결하고 운영상 문제를 최소화 하기 위해 광범위한 인증 지침 및 기준이 존재한다.
  19. 적절한 사용 및 유지를 보장하기 위한 유지보수 요구사항 또는 제한사항
  20. 시스템 아키텍처가 안전 감시를 요구할 때, 안전 감시 요구사항.
  21. 암호화, 설정 및 부하 검사 그리고 인터페이스 배리어와 같은 보호를 포함한 보안 고려사항.
  22. 타이밍 및 메모리 여분, 노후화된 기술의 최소화 등과 같은 추후 성장 및 유연성 요구.

 

ISO26262, DO-178C, DO-278A