일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | |||||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |
- information hiding
- link layer
- 게임개발
- STCF
- stride
- 게임 개발
- MLFQ
- Waterfall
- 배경 그림
- 운영체제
- SJF
- protection
- Unity #Indie Game
- DSP
- SDLC
- Security
- 유니티
- DP
- unity
- 메카님
- FIFO
- polymorphism
- AINCAA
- OSI 7계층
- OWASP
- 컴퓨터 네트워크
- MAC
- 유스케이스
- Trap
- frequency-domain spectrum analysis
- Today
- Total
다양한 기록
SW Myths, 등장 배경, 본문
1. 일정이 늦어지면 더 많은 프로그래머를 쓰면 된다
현실: 조정 작업 증가, 속도 더 늦어질 수 있음
-> 추가된 프로그래머의 역량에 따라 달라짐
2. 목표 서술만으로 프로그램 작성 시작에 충분
목표는 시작하기엔 좋지만 충분하지 않다
초기 정의가 불완전한 것은 소프트웨어 프로젝트 실패의 주요 원인
3. 프로그램을 작성하고 작동되기만 하면 작업 끝
문서화, 테스트 기록, 프로그램 설정은 배포의 중요한 부분임
4. 프로그램이 실행될 때 까지는 품질을 평가할 방법이 없다
설계 과정 중 리뷰를 통해 가능
5. 좋은 소프트웨어 개발 프로세스와 표준을 따르면 좋은 소프트웨어가 보장된다
성공 보장은 못함
6. 프로젝트 요구사항은 계속 바뀌지만 소프트웨어는 유연하기에 변경을 쉽게 수용할 수 있다
변경 수용의 용이성은 변경 요청이 프로세스 중 어느 시점에 발생했느냐에 따라 다름
7. 나는 슈퍼 프로그래머다. 내가 작성하면 완료된다
미성숙함의 징후이자 실패의 공식. 소프트웨어 프로젝트는 개인이 아닌 팀에 의해 수행,
성공을 위해선 단순 코딩 이상이 필요
데이터
28% => 성공적으로 개발됨
23% => 프로젝트 캔슬됨
49% => 늦게 완성되거나, 예산초과, 또는 문제가 있음
Software Crisis(불황) => 소프트웨어 공학의 등장 배경
1. 조직이 소프트웨어 개발에서 시간, 노력, 비용을 예측할 수 없는 문제
2. 소프트웨어의 낮은 품질
3. 하드웨어 대비 소프트웨어 비용 비율의 변화
4. 유지보수의 중요성 증가
5. 하드웨어 기술의 발전
6. 소프트웨어 기술의 발전
7. 소프트웨어에 대한 수요 증가
8. 더 크고 복잡한 소프트웨어 시스템에 대한 수요
왜 소프트웨어 공학이 필요한가?
- 문제는 복잡성
사이즈가 주로 문제.. 유닉스는 4백만 줄, 윈도우2000은 10^8 라인..
소프트웨어 공학은 이러한 복잡성을 관리하는 것임
소프트웨어 공학의 목표
- 시간 내에, 예산 범위 내에서 클라이언트의 요구를 충족시키는 소프트웨어를 제공
- 사용자의 요구가 변경될 때 소프트웨어는 쉽게 수정되어야 함
소프트웨어 공학의 주제
- 방법(method) : 어떻게 만들 것인가?
- 도구(tool) : 무엇을 사용해 만들 것인가?
- 프로세스(process) : 어떤 과정/단계로 만들 것인가?
- 패러다임(paradigm) : 어떤 접근법/스타일을 사용할 것인가?
소프트웨어 공학과 컴퓨터 과학의 차이
컴퓨터 과학: 이론과 기초에 중점을 둠
소프트웨어 공학: 실제 소프트웨어 개발과 유용한 소프트웨어 제공에 중점
비유
나무 - 컴퓨터 과학 이론은 소프트웨어 공학의 완전한 기반을 제공하기엔 충분하지 않으나 실제적인 측면을 위한 토대가 됨
숲 - 소프트웨어 공학은 컴퓨터 과학의 이로을 기반으로 하지만 더 넓은 실제적 문제들을 다룸
소프트웨어 공학과 시스템 공학의 차이
소프트웨어 공학: 시스템 공학의 일부
시스템 공학: 하드웨어, 소프트웨어, 네트워크를 포함한 컴퓨터 기반 시스템 개발의 모든 측면을 다룸
시스템 엔지니어는 ..
- 시스템 명세
- 아키텍처 서례
- 통합 및 배포
에 관여
사후 유지보수 코스트
대략 2/3 정도
시간이 지날수록 문제 감지 및 수정 비용이 증가함
왜?
- 라이프 사이클에서 일찍 발견 => 그냥 문서만 바꾸면 됨
- 늦게 발견 => 코드, 문서 다 바꾸고 테스트하고 회귀 테스트하고 클라이언트 컴퓨터에 제품 재설치 필요
초기 단계의 중요성
- 대규모 제품의 모든 결함 중 60~70%가 요구사항 정의, 분석, 설계에서 나옴
- 요구사항 정의, 분석, 설계 기법 개선이 중요 ..
* 가능한 빨리 결함을 발견하기 위해
* 전체 결함 수를 줄이기 위해 => 전체 비용도 감소
소프트웨어 공학이 직면한 주요 과제
- 레거시 시스템
- 이질성 (Heterogeneity)
- 전달 (Delivery)
유지보수가 필요한 이유
1. 요구사항 변경
2. 에러
3. 플랫폼 (OS, 웹->모바일, HW ..)
'소프트웨어공학' 카테고리의 다른 글
OOP #2: Encapsulation, Information hiding (혹은 Abstraction), Message (0) | 2024.10.20 |
---|---|
OOP #1 : 등장, 객체란? (0) | 2024.10.20 |
소프트웨어 공학이란 (0) | 2024.10.20 |
소프트웨어 특성, 역사, 분류 (0) | 2024.10.20 |
Introduction, SDLC 5단계 (0) | 2024.10.19 |