대한민국 개발자 희망보고서(07.06.11 ~ 07.06.17)

p. 27
내가 일하는 시간의 절대량보다 능력을 최대한 발휘한 시간이 진정한 의미의 생산성이다.
명확한 목표가 있을 때 몰입할  가능성이 높다.

p. 39
왜 이 일을 꼭 이렇게 해야 하는지, 그리고 좀 더 나은 방법은 없는지를 생각하지 않고 일을 잘 할 수 없다.

p. 41
IT 프로젝트의 현실
프로젝트는 90% 달성될 때까지는 빨리 진행된다. 그런데 나머지 10%가 영원히 계속된다.

p. 51
개발자는 프로그래머보다 진보적인 개념으로 프로그램을 짜는 차원을 넘어서 소프트웨어 제품을 만드는 사람이다. 기술뿐아니라 커뮤니케

이션, 문제해결, 팀워크에 대한 능력을 가지고 있다.

p. 77
실패하는 프로젝트의 7가지 습관
프로젝트에 투입되는 인력의 자질에 따라 많게는 28배 이상의 생산성 차이를 나타낸다.

p. 84
프로젝트 관리의 핵심요소라고 할 수 있는 일정과 비용, 품질이 균형있게 잘 관리되어야 한다. 이 세 가지 요소는 서로 대립적인 관계가

아님을 명심하라. 그리고 가장 중요한 한 가지, 고객을 항상 염두에 두어라. 모든 비즈니스는 고객을 돕는 일이다. 프로젝ㅇ트도 마찬가

지다. 프로젝트는 내부 고객인 프로젝트 팀원과 시스템을 사용할 실제 고객을 만족시키는 활동이 지속적으로 이루어져야 하며 또 결과로

나타나야 한다. 이것이 누구나 프로젝트의 성공을 바라지만 실제 성공시키기는 어려운 가장 큰 이유다.

p. 97
실속있는 요구사항 개발을 위한 몇 가지 원칙
1. 요구사항 누락을 막아라.
2. 사용자층을 정확하게 식별하라.
3. 고객의 참여를 이끌어내라.
4. 요구사항의 가시성을 높혀라.
5. 우선순위를 부여하라.
6. 요구사항 검토 및 승인활동을 반드시 실시하라.
- 요구사항을 검토한다는 것은 충분한 대화를 나누라는 뜻이다.

p. 103
프로타이핑 퍼포먼스
일하는 방법을 이해한다 -> 관찰한다 -> 시각화 한다 -> 평가하고 다듬는다 -> 실천한다
시각화 한다 = 프로토타입을 만드는 과정

프로토타입 성공요소
- 프로토타입을 개발하고 평가하는 일정을 프로젝트 계획에 반영하라.
- 완벽한 사용자 인터페이스 프로토타입은 존자하지 않는다. 다양한 프로토타입을 개발하라.
- 요구사항에 대한 이해가 완벽한 경우에는 굳이 프로토타입을 만들 필요는 없다.
- 프로토타입에 사용할 데이터는 현실적이어야 한다. 검토자가 비현실적인 데이터에 관심을 두면 프로토타입의 본래 목적을 잃기 쉽다.
- 프로토타입으로 프로그램 명세서를 작성해서는 안 된다. 프로토타입은 화면의 항목에 대한 상세한 정의, 예외 처리 등에 대해 다루지 않는다.

p. 119
데이터베이스 모델링
완벽한 설계는 더 추가할 게 없을 때가 아니라 더 이상 뺄 것이 없을 때 완성된다.

p. 124
3차 정규화까지는 반드시 숙지할 것
3차 정규화는 데이터 중복을 제거하기 위한 데이터베이스 설계의 일반적인 목표이다.
1정규화: 모든 속성은 하나의 값을 가져야 한다.
2정규화: 모든 속성은 식별자(Unique Identifier) 전부에 종속되어야 한다.
3정규화: 식별자가 아닌 모든 속성들간에는 종속될 수 없다.

p. 137
똘레랑스(Tolerance) - 견딘다.
대충 절충해서 합일점을 찾는 타협이ㅏ 아니라 그보다 한 차원 높은 상태에서 서로 다른 상대방을 있는 그대로 받아들이고 그것을 견디어

내는 관용과 존중의 정신이다.

p. 268
소프트웨어 품질의 특성
기능성(Functionality): 소프트웨어가 주어진 조건하에서 사용될 때 명시적 혹은 묵시적 요구 기능을 제공하는 능력
신뢰성(Reliability): 소프트웨어가 주어진 조건하에서 사용될 때 정의한 일정 수준의 성능을 유지하는 능력
사용성(Usability): 소프트웨어가 명시한 조건하에서 운용 시 사용자가 쉽게 이해하고, 배우고, 활용하며, 친숙해질 수 있는 정도
효율성(Efficiency): 명시한 조건하에서 사용한 자원의 양을 기준으로 적절한 성능을 제공하는 능력
유지보수성(Maintainability): 소프트웨어의 수정요이성 정도. '수정'은 교정, 개선, 환경변화에 대한 적응을 포함
이식성(Portability): 소프트웨어를 다른 환경(조직, 하드웨어, 소프트웨어 환경)으로 이식할 수 있는 정도

p. 310
누가 적합한 사람인지의 여부는 전문 지식이나 배경, 기술 보다는 성격상의 특질이나 타고난 소양과 더 관련이 있다.

p. 319
슈메르체크가 - '정글세미나'

p. 331
- 전문지식: 어떤 사람이 적어도 하나의 특정 분야에 정통하다면, 다른 분야에도 정통할 수 있는 능력이 있다고 볼 수 있다. 전문지식은

일을 하기 위한 기본이다. 기술은 매우 빠르게 변하므로 스스로 연구할 수 있고 매우 복잡한 내용도 이해할 수 있는 능력이 필요하다.
- 프로젝트에 대한 헌신: 성실한 자세와 뜨거운 열정은 프로젝트에 긍정적이다. 팀의 사기를 복돋아준다. 지원 희망분야나 전직 사유 등

을 질문해 보라.
- 프로젝트 성공, 실패 사례: 과거에 수행했던 프로젝트 중에서 기억에 남는 성공, 실패 사례를 한 가지씩 이야기하게 한다. 그리고 왜

그랬는지? 원인을 분석하게 함으로써 가치관을 엿볼 수 있다.
- 팀워크: 프로젝트 성공의 핵심요소 중의 하나는 팀워크다. 팀워크가 잘 발휘되었던 멋진 사례, 아니면 반대의 사례를 이야기하게 하고

몇 가지 질문을 던져본다. 예를 들어 진척이 처진 동료를 도와준 사례가 있었는지, 왜 도와주었는지?
- 문서작성능력: 이력서와 자기소개서를 보면서 경험한 업무와 기술이력헤만 초점을 두지말고 글쓰기 능력을 살펴보라. 문서작성은 소프

트웨어 개발의 중요한 요소이다. 이력서와 자기소개서의 전개방식을 검토하라.
- 자신의 장, 단점: 끝으로 자신의 장점과 단점을 한 가지씩 언급하게 한다. 면접 중 관할한 것과 일치하는지 비교해 본다.

p. 339
IT 전문가의 조건
- 최고의 실력자가 되려는 전문성
- 평생 학습에 대한 욕구
- 스스로 배우려는 노력
- 뛰어난 문제해결 능력
- 명쾌한 커뮤니케이션 능력

p. 354
히로나카의 '학문의 즐거움'
어떤 문제에 부딪치면 나는 미리 남보다 시간을 두세 곱절 더 투자할 각오를 한다. 그것이야말로 평범한 두뇌를 가진 내가 할 수 있는 최

선의 방법이다.

p. 386
기술사 시험은 정해진 시간 안에 정해진 분량을 써내는 것이 기본이다. 품질은 그 다음이다.

p. 389
기술사 시험은 한 분야를 깊이있게 파기 보다는 전체적인 IT프레임워크에 대한 이해의 성격이 강하다.