초보 개발자

** 본 글은 차성덕 교수님의 소프트웨어공학이야기 책을 정리한 글입니다. ** 인스펙션 기법의 놀라운 점 인스펙션 기법의 뛰어난 성능 30년 전부터 적용되었다는 점 상식적이고 기본적인 내용으로 이루어진 점 인스펙션 기법 -Fagan 인스펙션: 3~6명의 관련자들이 적당한 준비 후 모여서 결함을 찾기 위한 집중적인 검토 모임을 갖는 것 인스펙션은 하루에 최대 두 번, 한 번에 최대 두 시간씩 제한하도록 추천 참여자들의 역할: Moderator(사회자), Reader, Inspector, Recorder 등 오류를 찾기 위한 목적에 집중할 수 있도록 노력하는 것 인스펙션 기법의 과정 Planning & Overview: 참여자들에게 "product" 설명하는 단계 (소스코드, SRS, 설계 문서 등의 pro..

** 본 글은 차성덕 교수님의 소프트웨어공학이야기 책을 정리한 글입니다. ** 요구공학 단계에서 발생하기 쉬운 위험요인 - Lawrence Overlooking a crucial requirements 중요한 요구 사항 간과 Inadequate Customer representation 불충분한 고객 표현 Modeling only functional requirements 비기능 요구사항 + 예외상황 시나리오 파악 필요 Not inspecting requirements 점검하지 않는 것 Attempting to perfect requirements before beginning construction 요구사항 완벽하게 만들고 다음 단계로 넘어가려고 하면 안 됨 Representing requirement..

** 본 글은 차성덕 교수님의 소프트웨어공학이야기 책을 정리한 글입니다. ** 소프트웨어웨어의 품질: reliability / correctness SRS 요구사항 문서 = 판단의 기준 - 명확하지 않은 요구사항: 품질 판단 불가능 - 틀린 요구사항: reliability 정의상으로는 옳지만 고객 입장 X - 중의적 요구사항: 테스트 케이스 오류 가능 신뢰도 정량적 측정 지표 (MTBF) Software Requirement Specification 가능한 정량적으로 기술되어야 한다. - 정량적이고 독립적인 검증 가능한 품질 지표 산출 주관적 해석, 애매한 표현은 적절치 않다. 특히 비기능적 요구사항 NFR을 기술할 때 주의가 필요하다. 요구공학이 어려운 이유 요구사항을 기술할 때, 자신의 관점에서 자신..

** 본 글은 차성덕 교수님의 소프트웨어공학이야기 책을 정리한 글입니다. ** 요구공학 소프트웨어 개발 비용 중 차지하는 비중은 10~15% 미만이나 중요한 단계 요구사항을 조기에, 제대로 파악하지 못하면 프로젝트에 부정적인 영향을 끼치고 막대한 손실로 이어짐 틀린 요구사항을 바로잡아서 다시 구현하려면 추가비용이 발생하고, 변경된 요구사항이 다른 기능에도 영향을 끼침 → 디자인 및 테스트 케이스도 수정되어야 하므로 개발 전 단계에 영향을 끼친다고 볼 수 있음 요구사항을 기술하는 방법: 기능 요구사항 + 비기능 요구사항 (품질 속성) 자연어 사용 (시스템의 복잡도 때문에 더 좋은 대안이 별로 없음) 정형 명세 및 정형 검증 / 모델링 기법 (높은 전문성, 시스템의 복잡도를 제대로 지원하지 못함) 더보기 엘..

** 본 글은 차성덕 교수님의 소프트웨어공학이야기 책을 정리한 글입니다. ** 소프트웨어의 오류로 인한 사고 보잉 737 Max 8 항공기의 추락 새로 도입된 MCAS 소프트웨어 기반 안전장치 시스템의 오작동 자율주행 자동차의 사고 Uber - 보행자 사망 / Tesla - autopilot 소프트웨어 오류 / Waymo ( + 자동차의 급발진 사고 ) Keyless Ignition system: 스마트키를 소지하고 있을 경우 엔진 조작이 가능한 장치 엔진 정지 버튼을 누르지 않고 떠날 경우에도 시동이 꺼지지 않는 문제 엔진 소음이 약해져 시동이 꺼지지 않은 것을 인지하지 못함 → 연료 낭비, 환경 오염, 일산화탄소 질식 ▷ 소프트웨어 자체의 오류뿐 아니라 소프트웨어가 제대로 작동했을 경우에도 사고가 발..

** 본 글은 차성덕 교수님의 소프트웨어공학이야기 책을 정리한 글입니다. ** 소프트웨어공학 교육의 필요성 소프트웨어 산업의 "승자독식" 체제: 1등 업체와 비교해서 월등한 품질을 갖지 못하면 생존 힘듦. 소프트웨어 산업의 경쟁력: 소프트웨어의 품질과 개발의 효율성 그래서 소프트웨어 개발 원가의 대부분은 인건비로 지출 → 유능한 개발 인력 확보 노력 최근 소프트웨어는 대규모의 복잡한 프로젝트가 많으므로 효율적으로 고품질의 소프트웨어를 개발하는 분야 공부해야 함 제품의 생산 원가의 대부분을 소프트웨어가 차지 (전투기 80%) + 자동차 산업에서도 Tech company가 경쟁력 있음 항상 컴퓨터공학 핵심 교과과정에서 소프트웨어공학 분야 SDF, SE 수업 비율 높음 - ACM, IEEE 새로운 분야가 계속..

** 본 글은 차성덕 교수님의 소프트웨어공학이야기 책을 정리한 글입니다. ** 소프트웨어공학의 정의 소프트웨어의 설계, 구현, 테스트 및 문서화에 대한 과학 및 기술 지식, 방법 및 경험의 체계적인 적용 소프트웨어의 개발, 운영 및 유지 관리에 대한 체계적이고 규율적이며 정량화 가능한 접근 방식의 적용 소프트웨어 생산의 모든 측면과 관련된 엔지니어링 분야 안정적이고 효율적으로 작동하는 소프트웨어를 경제적으로 얻기 위한 Multi-person construction of Multi-version software - David Parnas (information hiding) Multi-person: 수백명의 개발자들이 협력해야 하는 크고 복잡한 소프트웨어 (소프트웨어는 점점 복잡해짐) Multi-versi..