소프트웨어 폭주 – 몇 가지 놀라운 결과들


프로젝트를 망치는 여러가지 방법이 있는데, 망한 것으로부터도 교훈을 얻을 수 있다. 이런 교훈을 얻은 후 다시 반복하지 않아야 역사는 발전할 것이다. 근데 보통은 했던 잘못한 일을 반복하는 경향이 있다. 교훈을 배우지 않기 때문이다.

로버트 L. 글라스의 글은 통찰력이 있고, 정말 깜짝 놀라게 하는 능력이 있다.

프로젝트 관리를 잘 하기 위해서는 배워야 할 점이 참 많다고 생각한다. 엔지니어라고 하더라도 말이다.

소프트웨어 폭주 – 몇 가지 놀라운 결과들

Robert L. Glass President Computing Trends

난 항상 실패하는 컴퓨팅 프로젝트에 관심이 있다. 성공보다는 실패로부터 훨씬 더 지울 수 없는 교훈이 많은 것으로 보인다.

독자 중 일부는 내가 예전에 가명으로 선도적인 컴퓨팅 신문 칼럼을 한때 썼던 것을 알지도 모르고 그 컬럼의 내용은 허구적인 실패 이야기였다. (나는 가명으로 작성하고 소설을 썼는데, 그 이유는 당시 내 고용주가 내 세탁 공공 장소에서의 더러운 린넨을 감사하지 않을 것이라고 의심하기 때문에 이야기를 소설화 한 것이다!)그 컬럼은 궁극적으로 책 ‘The Universal Elixir and Other Computing Projects That Failed’ 이 되었다. 그리고 다른 책을 또 썼다. ‘The Second Coming: More Computing Projects That Failed’

그 성공에 힘 입어, 나는 다시 컴퓨팅 대참사에 대한 글을 썼다. 실재 있는 실패한 메인 프레임 컴퓨팅 컴퓨팅 그리고 다시 컴퓨팅 저하, 실패한 마이크로 컴퓨터 프로젝트의 실화. 실패는 내 운명이었다!

그러나 그 책들은 1987년에 출판되었고 10년도 더 된 일이다. 내가 실패에 대한 관심을 잃은 아니었다. 그저 좋은 실패 사례를 찾는 것이 점점 힘들어졌을 뿐이다! 조기 실패의 빈도와 메인 프레임과 마이크로 컴퓨터 산업의 침체는 거의 끝났다. 컴퓨팅은 거의 지루하게도 성공적인 필드가 되었다.

일부는 물론, 위의 내용에 대해서 문제 제기를 할 것이다.”소프트웨어 위기”를 부르짖는 사람들은 소프트웨어 분야의 믿음이 실패로 가득 차고 성공적인 요소가 거의 없다는 신념을 말한다. 하지만 그것은 내가 그것을 보는 방법이 아니다. 나는 실패 사례를 찾아서 보낸 시간에도 불구하고, 나는 소프트웨어는 드라마틱한 성공스토리의 시대라고 믿고 컴퓨팅 시대를 점화하는 불꽃을 내고 있다고 믿는다. 물론 실패가 있었다; 그러나 그들이 흥미로워하는 것은 그들 중 다수가 속하지 않는 지엽적인 것이다. 그것은 저널리스트와 소프트웨어 사람들이 “예외 보고”라고 부르는 것이다.- 우리는 그들이 올바르게 실행되는 것들보다 더 흥미롭거나 중요하기 때문에 잘못된 것들에 집중하는 경향이 있다.

흠, 난 다시 실패에 있다! 나는 약 10 년 동안 소프트웨어 폭주에 대한 자세한 이야기​​를 수집해 왔으며, 아직 함께 또 다른 책에 넣을 만큼 그들을 충분히 가지고 있다. 그 책은 덴버 공항 수하물 처리 시스템에 대한 이야기​​를 포함하여, FAA 항공 교통 제어 시스템, 국세청의 현대화 노력 등. 한번 실패한 너트는 영원히 실패하는 너트이다!

나는 책에 대한 이야기​​를 축적으로 내가 하는 일 중 하나는 그들이 우리를 가르치는 교훈을 분석하는 것이다. 책을 위한 개요를 생성하는 것은 좋은 방법이다. 그리고 그것은 또한 독자를 위해 부가 가치가 있다는 것을 확인하는 방법이다. 다음은 읽기에 재미있을 뿐만 아니라, 교훈은 읽는 것이 배우는 경험이 되게 한다.

연구 일치하는 것을 발견 몇 가지 사항은 다음과 같습니다:

  1. 대부분의 폭주하는 프로젝트들은 거대했다. 거대한 프로젝트들은 작은 것들보다 훨씬 더 문제가 많다. 이 이야기는 그 발견을 지지한다.
  2. 대부분의 프로젝트 폭주 원인은 여러 가지 이유들이 있었다. 여러 가지 원인들은 한가지의 중요한 원인이 있을 수도 있고, 없을 수도 있는데, 거기에는 항상 폭주에 기여하는 여러 가지 문제들이 있다.
  3. 다수의 폭주하는 프로젝트들은 그들의 이력에서 그들이 교체하려는 시스템에 비해 상당한 진일보한 것으로 “돌파구”가 된 것에 대해 조기에 칭찬을 받았다. 프로젝트가 잘 진행될 때까지 그 프로젝트가 실패할 것으로 보이지 않았다.

그러나 예측 불가능함은 훨씬 더 매력적이다. 여기에 폭주하는 프로젝트의 몇 가지 특징이 있다.

  1. 기술은 빈번하게 관리와 같은 실패의 원인이었다. 특히 소프트웨어 공학 분야에서의 문헌은 주요 실패가 보통 관리로 인한 것이라고 말하는 경향이 있다. 그러나 이 16개의 실패 이야기의 거의 절반을 지배하는 문제는 기술이었다. (우리는 이것을 뒤에서 다룰 것이다).
  2. 두 개의 특별히 놀랍고 지배적이 기술적 문제가 있었다. 첫째는 새로운 기술의 사용이었다. 프로젝트들 중의 4개는, 완전히 그들이 소프트웨어 공학 개념의 최신을 사용하고 있기 때문에 돌파구가 될 것으로 기대했는데, 오히려 그들 때문에 실패했다! 오래된 레거시 소프트웨어를 대체하려는 메가 패키지를 사용했던 하나는 그런 접근 방법을 선택 하였으나 실패했다. 대형 프로젝트에서 4 세대 언어를 사용하고, (그 작업이 완료된 후에!) 발견한 것은(온 – 라인)에 대해 시스템의 성능 목표를 달성 할 수 있는 것이 아니었다는 점이다.
  3. 두 번째 주요한 기술적 문제는 성능이다. 이러한 폭주하는 프로젝트의 대부분은 어떤 의미에서 real-time에 있었고 너무 자주 단순히 내장된 시스템들이 유용하다고 보기에는 너무 느렸다.

다음은 이 논문에서 확인 된 추세의 일부는 다음과 같다:

  1. 응답자는 폭주 프로젝트 수가 감소하고 있다고 생각했다. (42 %가 폭주 프로젝트의 빈도가 감소한다고 응답하였고 반면 단지 8%가 증가하고 있다고 하였다.)
  2. 패키지 소프트웨어는 커스텀 소프트웨어와 같이 폭주 비율이 비슷했다(47%는 혼합, 22%는 패키지 단독, 24%는 커스텀)
  3. 일정이 가장 자주 주요한 폭주하는 프로젝트의 문제였다(89 %); 62 %는 비용 초과를 했다.
  4. 대부분의 시스템들은 시작부터 잘못 인식되었다. 이 위에서 논의 된 내 자신의 연구 결과와 다소 충돌합니다.
  5. 대부분의 폭주하는 프로젝트들은 시니어 관리자에 의해 발견되지 않음(19%), 하지만 프로젝트 팀 자체에 의해 발견되었다. (72%)
  6. 기술은 빠르게 폭주의 원인으로 증가하고 있다.
  7. 폭주 프로젝트의 주요 원인은 다음과 같다. (중요성의 내림차순)
  8. 프로젝트의 목표는 완전히 명시되지 않았다.
  9. 나쁜 계획 및 추정.
  10. 조직에 새로운 기술.
  11. 불충분한 또는 전혀 관리가 없는 방법론
  12. 팀에 부족한 시니어 직원.
  13. 하드웨어 및 / 또는 소프트웨어 공급 업체에 의한 성능 저하

참고

Cole, Andy (1995). “Runaway Projects: Cause and Effects,” Software World (UK) Vol. 26 No. 3.

저자에 대하여

Robert L. Glass is president of Computing Trends,   publisher   of   The Software Practitioner,   and    PERC    (Practical   Emerging Research Concepts) in Information Technology.  He also writes the “Practical Programmer” column for the Communications of the ACM.              He  has  been  active  in the  field  of computing  and  software  for  over  40 years, largely  in  industry  (aerospace)  but  also  as an  academic   (Seattle  University,  Software Engineering  Institute).   The author of some 20 books on computing subjects (many of them about failure!), he describes himself as having his head in the academic side of computing but his heart in its practice.

Advertisements

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


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

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

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

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

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

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

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

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

출처: LG경제 연구원

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

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

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

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

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

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

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

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

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.의 없음을 보장할 수 있다.

ISO26262, DO-178C, DO-278A