쥐새끼는 쥐새끼에 걸맞는 자리에 있어야 하는데, 어쩌다가 대가리 노릇을 하다보니 애꿎은 국민이 고생하고 있습니다. 하긴, 그 왕초 쥐새끼를 앞세워 뒷구린 짓거리를 이어가는 여의도 등지의 쥐때들... 그간 보여주었던 그들의 놀라운 생존력을 감안한다면, '어쩌다가'라는 표현은 뭔가 좀 어색하기도 합니다.
날마다 뉴스를 접하면서 제 입에서는 쌍시옷 소리가 끊이지 않는데, 본 블로그에는 그런 모습이 전혀~ 안보입니다. 오로지 앞으로 먹고 살기 위한 포스팅만이 끊이지 않을 뿐. 뭐 이미지 관리 차원에서 그랬던 것은 아닙니다. 걍 어쩌다가 보니 그랬던 것일 뿐이죠.
하지만, 요즘 심하게 갈등 때리고 있습니다. 난 입만 살아있는 것인가.. 나 역시 쥐새끼같은 행동을 하는 건 아닌가... 하고 말입니다. 역사를 장식하는 주요한 순간마다 놀라운 통찰력을 보여주었던 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 테스트가 가능해짐
back-to-back 테스트(동일 결과면 OK, 다르면 결함 존재)
프로토타이핑 프로세스
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) 매 빌드마다 모든 테스트가 수행되고 테스트에 성공했을 때만 해당 빌드를 인정
XP 릴리즈(release) 사이클
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) : 고객은 개발팀의 일원. 전적으로 개발에 시간을 할당하여 시스템 요구사항을 전달할 책임이 고객에게 존재
댓글을 달아 주세요
링크 타고 왔어요~ ㅎㅎ