초보 개발자

** 본 글은 차성덕 교수님의 소프트웨어공학이야기 책을 정리한 글입니다. ** 개발비용을 예측하는 것은 왜 어려울까? 누가 작업을 수행하는가에 따라 다르고, 영향을 주는 요인이 너무 많다. 이미 개발한 소프트웨어를 확장하는 경우에도 사소한 차이가 매우 큰 비용 변화를 가져오기도 한다. (ex. 보안 관련 s/w, centralized →client-server로 환경 재구축, MMORPG 접속자 수 두 배 늘리기 등) 기존의 소프트웨어 개발 경험은 새로 만드는 소프트웨어의 개발 비용 예측에 큰 도움이 된다. → 프로젝트 전 과정에서 적절한 자료의 수집 및 분석이 꼭 필요하다. 소프트웨어 개발 비용은 어떻게 예측할까? Top-down 방식으로 개발하려는 소프트웨어의 구조를 파악한다. (상위 설계에 해당하는..

** 본 글은 차성덕 교수님의 소프트웨어공학이야기 책을 정리한 글입니다. ** 여러 객체지향 방법론 통합 → 방법론에서 지원하는 Diagram은 OMG/ISO의 국제 표준으로 채택 : UML UML이 도움이 되지만 없어도 문제는 생기지 않기 때문에 실제 산업체에선 잘 쓰이지 않는다 그럼에도 불구하고, 보충 설명 수단+기술적인 의견 설명으로 UML을 사용하는 것은 유용하다. UML 사용 빈도 설문조사 사용한다: use case, class, statechart, sequence, activity 사용 빈도: sequence → class → use case → statechart → activity 그러나 class diagram은 객체지향 프로그래밍 시 필수... UML 잘 활용한다고는 하기 어려움 Am..

** 본 글은 차성덕 교수님의 소프트웨어공학이야기 책을 정리한 글입니다. ** 애자일 개발 선언문 Individuals and interaction over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan 너무 많은 애자일 기법... 어떤 것을 적용하는 것이 좋을까? 주위 사람들의 경험, 각종 교육이나 세미나, 애자일 기법의 적용 사례들을 조사해보자! 가장 널리 쓰이는 애자일 기법 애자일 기법 - 소수, 동기부여, 협력 준비가 되어 있는 팀이 생산성을 극대화 하기 위..

** 본 글은 차성덕 교수님의 소프트웨어공학이야기 책을 정리한 글입니다. ** 기존의 방법론에서 어떤 단점? 그리고 어떻게 극복? 주어진 환경과 제약사항을 고려했을 때 어떤 후보? 등을 생각해보자 Waterfall : 폭포수 모델 요구공학 → 디자인 → 코드 구현 → 모듈 단위 시험 테스트 → 통합테스팅 이전 단계로의 Loop back이 가능하다. 누락된 것이 있으면 멈추고 다시 돌아가서 하라는 뜻 NASA (폭포수 모델 + 각 단계가 동시다발적으로 실행되기도 함) - 복잡한 소프트웨어 환경이라는 것을 인지 요구사항 분석 단계에서 디자인 + 구현 → 프로토타입 구현, 선행적인 디자인 작업 등 재작업, 변경은 추가 비용을 발생시키므로 최소화 하는 것이 좋음. Document: entry criteria, ..

** 본 글은 차성덕 교수님의 소프트웨어공학이야기 책을 정리한 글입니다. ** 소프트웨어 개발방법론은 여러 가지가 있고, 사람마다 견해가 다르다. 경험한 개발방법론을 추천해주는 사람도 있지만 무엇을 채택해야 할지에 대한 답은 쉽게 내릴 수 없다. 적용된 분야가 다를 수 있고, 내가 경험해보지 않았다는 점 또한 큰 요소이기 때문이다. - 작은 크기의 개발프로젝트는 사실 개발방법론에 큰 영향을 받지 않는다. 특정 개발론이 아닌 개발자들의 개인적 능력, 팀의 협력이 중요하다. - 큰 크기의 프로젝트는 체계적인 계획과 적절한 개발방법론의 선택이 중요하다. 어떤 단계 및 절차를 거쳐 개발할 것인지에 대한 문서: 소프트웨어 개발 계획서 / 프로젝트 관리계획서 소프트웨어 개발 계획서 / 프로젝트 관리계획서 단계별로 ..

** 본 글은 차성덕 교수님의 소프트웨어공학이야기 책을 정리한 글입니다. ** 소프트웨어 개발 조직의 역량을 평가하는 성숙도 평가 모델 CMM 소프트웨어 개발 조직의 역량을 객관적으로, 정량적으로 평가하고자 하는 바람 Software Process Improvement가 필요한 이유 소프트웨어는 개발자의 능력, 적용되는 기술, 프로젝트가 얼마나 체계적/효율적으로 진행되는지에 따라 성공이 결정된다. 프로젝트의 성공을 위해서는 프로세스를 개선하려는 노력이 필요하다. (Watts Humphrey - SPI 선구자) SW-CMM: capability maturity model (성숙도 모델) 첫 시작은 미국 국방성의 Software Engineering Institute (SEI)이다. 소프트웨어로 인한 비용 ..

** 본 글은 차성덕 교수님의 소프트웨어공학이야기 책을 정리한 글입니다. ** 페이건 인스펙션 (Formal Technical Review) 긍정적 효과가 반복적으로 검증된 방법이지만 귀찮고, 시간이 많이 걸린다는 단점이 있다. Johnson의 논문에서 80% 이상이 전혀 사용하지 않거나 가끔 사용한다. - Modern Code Review (light-weight code review) waterfall의 대안으로 agile이 제안된 것처럼 FTR의 대안으로 제안되었다 meeting-based examination 단계를 생략한다. - 같roq은 시간, 장소에 모이는 것 쉽지 않음 페이건 인스펙션, FTR의 향후 목표 - Johnson Provide tighter integration between F..

** 본 글은 차성덕 교수님의 소프트웨어공학이야기 책을 정리한 글입니다. ** 최근 개발되는 소프트웨어의 크기가 증가하면서, 현실적으로 모든 소프트웨어에 대해 실시하는 것은 불가능하게 되었다. 모든 소프트웨어에 대해 인스펙션을 시행하는 것이 불가능할 때 선별적으로 중요한 산출물만이라도 인스펙션을 실시한다. Fagan에서 추천하는 속도는 시간당 150~200줄 정도이다. 모든 소프트웨어에 대해 인스펙션을 시행할 수 없을 경우 소스코드의 중요도를 상, 중, 하로 분류하고 상은 필수, 중은 선택, 하는 walkthrough없이 일반 테스팅만 걸친다 만약 모든 중요도를 중, 하로 분류한다면? 동료 개발자의 도움을 받아 품질을 확인해주는 편법을 쓴다면? - 편법은 통하지 않는다. PM이 무능하지 않다면 당연히 알..