어쨌건간에 흘러가는 者

쥐새끼는 쥐새끼에 걸맞는 자리에 있어야 하는데, 어쩌다가 대가리 노릇을 하다보니 애꿎은 국민이 고생하고 있습니다. 하긴, 그 왕초 쥐새끼를 앞세워 뒷구린 짓거리를 이어가는 여의도 등지의 쥐때들... 그간 보여주었던 그들의 놀라운 생존력을 감안한다면, '어쩌다가'라는 표현은 뭔가 좀 어색하기도 합니다.

날마다 뉴스를 접하면서 제 입에서는 쌍시옷 소리가 끊이지 않는데, 본 블로그에는 그런 모습이 전혀~ 안보입니다. 오로지 앞으로 먹고 살기 위한 포스팅만이 끊이지 않을 뿐. 뭐 이미지 관리 차원에서 그랬던 것은 아닙니다. 걍 어쩌다가 보니 그랬던 것일 뿐이죠.

하지만, 요즘 심하게 갈등 때리고 있습니다. 난 입만 살아있는 것인가.. 나 역시 쥐새끼같은 행동을 하는 건 아닌가... 하고 말입니다.
역사를 장식하는 주요한 순간마다 놀라운 통찰력을 보여주었던 10대들의 의기에 찬 모습들. 이와 함께한 일반 국민들... 이러한 분들의 노고 덕분에 현재의 '대한민국', 그 안의 풍요로운 '나'가 있음은 의심할 여지가 없습니다. 이에 대한 보답은 저 역시 그들과 함께 함이라는 것을 잘 알고 있으면서도 아직까지도 제대로 참여해본 바가 없다는데 심히 부끄러움을 느낍니다.

시위에 참여하신 모든 분들에게 감사하다는 말씀 드리면서, 저 역시 조만간 참여할 것임을 다짐합니다.

그 쥐새끼가 쥐가 되어버린 건, 어쩌면 미국을 넘 좋아해 미국 쇠고기를 먹다, 머리에 구멍 뚤려 뇌의 무게가 쥐의 그것으로 되었기 때문인지도 모른다... 라고 억지로 상상해보았습니다. ㅋ


여하간, 저도 한마디 외칩니다.

너 하나로 족하다! 국민마저 쥐대가리로 만들려 하지 말라!  쥐새끼 타도!

본 포스트는 개인 스터디 용으로 작성된 Ian Sommerville의 Software Engineering, 8/E의 요약본입니다.

12. Rapid application development(RAD)
- 데이터에 집중된 비즈니스 응용(application), 즉 DB로부터의 정보를 표현하는 응용에 주로 사용
- RAD 환경 도구 : DB 프로그래밍 언어, Interface 생성기, 오피스 응용 프로그램과의 연결, 리포트 생성기, 대화식 개발에 알맞는 Visual programming 도구

13. Visual development
- 단위가 작은 재사용 가능 S/W 컴포넌트의 통합에 의존하는 RAD 기법
- Visual Basic같은 스크립트 언어를 사용
- 대규모 컴포넌트가 기정의, 기구현되어 있음
- 특정 응용 요구사항에 맞도록 재구성될(tailored) 수도
- COTS(Commercial Off-the-Shelf; 상용 기성품) 기반 개발이라 부르기도. 기성품을 재구성(configure)하고 연결
- 복합 문서(Compound documents)
  1) 사용자 조작(computation)이 가능한 능동 요소(active element)가 내장된 문서. 복합 문서 자체는 각기 다른 응용을 통합하는 역할
  2) 각각의 능동 요소는 특정 응용과 연결되어 해당 요소 선택시 활성화됨
- 문제점
  1) 팀 기반 개발에 알맞지 않음
  2) 명시적 시스템 아키텍처가 없음
  3) 프로그램 부위간 복잡한 의존성이 유지보수 문제를 일으킬 수도

14. S/W 프로토타이핑(Prototyping)
- 개념을 보여주고(demonstrate), 설계 선택사항(option)을 시험해보기 위한 개발할 시스템의 초기 버전
- 용도는,
  1) 요구공학 프로세스 : 요구사항 추출 및 검증을 위해
  2) 설계 프로세스 : 선택사항 시험 및 UI 설계 개발을 위해
  3) 테스트 프로세스 : back-to-back 테스트 수행을 위해
- 장점
  1) 시스템 사용성 향상
  2) 사용자의 실제 필요에 더욱 근접
  3) 설계 품질 향상
  4) 유지보수성 향상
  5) 개발 노력(effort)의 절감
  6) back-to-back 테스트가 가능해짐15. 폐기용 프로토타입(Throw-away prototypes)
- 프로토타입은 개발 후 폐기되어야 : 제조 시스템(production system)을 위한 적절한 기반이 되지 못하기 때문에
  1) (보안성, 신뢰성 등의) 비기능적 요구사항을 만족시키기 위해 프로토타입을 손질할(tune) 수 없음
  2) 일반적으로 프로토타입에 대한 문서는 없음
  3) 프로토타입의 구조는 보통 많은 변경으로 인해 낙후됨(degraded)
  4) 프로토타입은 조직의 품질 기준(표준)에 미치지 못하는 경우가 다반사

본 포스트는 개인 스터디 용으로 작성된 Ian Sommerville의 Software Engineering, 8/E의 요약본입니다.

7. 애자일 기법(Agile Methods)
- 기존의 개발 접근법에 대한 불만,즉 계획 수립, 설계, 문서화에 대한 부하(overhead)에 대한 반기로 시작
- 설계와 문서화보다는 S/W 자체(특히 코드)에 초점을 두도록
- 점증적 접근법에 기반
- 빠르게 변화, 진화해가는 요구사항에 대한 신속한 S/W의 배포
- 주로 소/중규모 비즈니스 시스템이나 PC 제품이 알맞음
- XP는 가장 잘 알려진 애자일 기법 중 하나

8. 애자일의 원칙
- 고객 참여(Customer involvement) : 고객은 요구사항 개발 및 운선순위 결정, 시스템의 반복(iteration)을 평가
- 점증적 인도(Incremental delivery) : 고객이 지정한 요구사항이 포함된 점증 단계를 기반으로 s/w가 개발되고 인도됨
- 사람은 프로세스가 아님(People not process) : 기정의된 프로세스를 강요하지 않음. 개발자 및 개발팀 만의 방식, 그들의 기술을 인정
- 변화를 포용(Embrace change) : 요구사항의 변화를 받아들이고 ,변화 수용 가능한 시스템을 설계
- 단순성 유지(Maintain simplicity) : S/W 및 개발 프로세스 모두에서 단순성에 초점을. 수시로 시스템에 남겨진 복잡성을 제거하도록

9. 애자일의 문제점
- 고객은 전적으로, 계속하여 프로세스에 참여하기 어려움
- 개발팀 구성원이 집중적인 참여를 요구하는 애자일의 특성에 맞지 않을 수도
- 다수의 이해관계자(stackholder)가 있을 경우 우선순위 변경이 어려워짐
- 단순성 유지는 추가적 작업을 요구
- 내재화된 점증적 명세화 작업으로 인해, 명사가 포함된 계약서 작성이 난해. 따라서 타 외부 개발 조직과의 co-work이 어려워질 수도

10. Extreme Programming(XP)
- 가장 잘 알려지고, 가장 많이 사용되는 애자일 기법
- 반복적 개발과 같은 좋은 실무 관행과 고객 참여을 극한(extreme)까지 밀고 나감
  1) 새로운 버전이 하루에도 몇 번씩 빌드될 수 있음
  2) 매 2주마다 각 점증적 단계가 고객에게 인도
  3) 매 빌드마다 모든 테스트가 수행되고 테스트에 성공했을 때만 해당 빌드를 인정
11. Extreme programming Practices
- 점증적 계획(Incremental planning) : 시토리 카드를 이용, 작업으로 분할. 이들 작업은 스케줄링과 비용 산정의 근간. 시간을 고려하여 우선순위 결정
- 소규모 릴리즈(Small releases) : 비즈니스 가치를 제공하는 최소한의 유용한 기능을 먼저 개발. 릴리즈를 자주, 점증적으로 수행
- 단순한 설계(Simple design) : 현재의 요구사항을 충족하는 충분한 설계를
- 테스트 주도 개발(Test driven development): 구현 이전에 자동화된 단위 테스트 프레임워크를 통해 테스트 킷을 먼저 작성
- 리팩토링(Refactoring) : 계속적으로, 최대한 많이 코드를 리팩토링. 단순성, 유지보수성 증가
- 짝 프로그래밍(Pair programming) : 짝으로 팀을 이뤄 함께 개발. 서로가 상대의 작업을 검사(checking)하도록. 비공식적 검토(Informal review)가 자연스럽게 이루어짐
- 집단적 소유(Collective ownership) : 짝이 시스템의 모든 영역을 맡음으로 고립된 비 개발 영역이 없도록. 누구든지 변경 코드 변경 가능
- 계속적 통합(Continuous integration) : 작업이 완료되자마자 전체 시스템에 통합되도록. 이후 모든 단위 테스트를 통과해야
- 유지 가능한 속도(Sustainable pace) : 초과 근무는 낮은 품질, 보통의 생산성 만을 양성할 뿐
- 현장의 고객(On-site customer) : 고객은 개발팀의 일원. 전적으로 개발에 시간을 할당하여 시스템 요구사항을 전달할 책임이 고객에게 존재