작성 목적
1. 소프트웨어 공학에 대한 이해
예전에 소프트웨어 공학에 대해 독학해본 적이 있는데 멘토님의 이야기와 보여주시는 것들을 보니 형식적인게 아니라 실제 현업에서도 사용하고 있는 기법들이라는 것을 많이 느꼈습니다. 그래서 소프트웨어 공학에 대해 먼저 공부해본 입장으로써 복습도 하고 멤버들에게도 멘토링과 관련된 내용들을 공유하기 위해 적어봤습니다.
2. 앞으로의 방향성 확립
팀원 모두가 이해하기 쉽게 '공통된' 전체 계획을 문서화 하여 공유할 필요가 있다고 생각합니다. 소프트웨어 공학은 아직 실제 프로젝트 경험이 없는 저희에게 큰 계획을 그릴 수 있게 도와주는 좋은 참고자료들이라고 생각합니다. 이를 통해 프로젝트 일정을 빠른 시일 내에 정할 수 있었으면 좋겠습니다.
1. 소프트웨어 공학 개념
소프트웨어를 설계, 개발, 사용, 유지보수 하는데 필요한 전반적인 과정을 문서화 하는 것
소프트웨어의 위기의 원인
•
논리적인 소프트웨어의 특징을 이해하지 못함
•
유지보수는 생각하지 않고 프로그래밍만 치중
•
사용자들의 요구하는 부분을 따라가지 못함
소프트웨어 위기의 결과
•
개발 기간 지연으로 인한 개발 비용 상승
•
유지보수가 어려워지고 비용이 증가
•
성능 및 신뢰성 부족
소프트웨어 개발 모델
폭포수 모델(water fall)
폭포가 아래로 물이 떨어지듯이 각 단계가 순차적으로 진행됨
•
장점 : 가장 오래되었고 적용 사례, 성공 사례가 많음. 단계별 문서 작업을 거치기 때문에 관리가 용이
•
단점 : 초기 요구 사항을 분석하기 어려움. 많은 시간과 노력이 단계별 문서화에 치중 됨
타당성 검토 → 계획 → 요구 분석 → 설계 → 구현(코딩) → 시험(검사) → 유지보수
1.
개발에 필요성에 대한 타당성을 검증
2.
사용자가 원하는 기능이나 비기능을 정의, 기능과 제약 조건을 정의하는 명세서를 작성함
3.
문제 영역과 사용자가 원하는 내용을 이해하기 위해 개념 모델 작성 및 프로세스 정의
4.
개발자가 식별할 수 있도록 문서로 작성(개략 설계, 상세 설계, 논리/물리 설계)
5.
구현(단위 테스트)
6.
발생한느 오류를 발견하고 수정하는 단계(통합 테스트, 시스템 테스트, 인수 테스트)
7.
개발 후 오류가 발생하거나 새로운 기능을 추가해야 할 때 일어나는 활동
나선형 모델
폭포수 모델 장점 + 프로토타입 모델 장점 + 위험 분석 과정 추가
나선형처럼 돌듯이 여러 번의 생명 주기 개발 과정을 거쳐 점진적으로 완벽한 시스템을 개발함
•
장점 : 위험 요소를 최소화하여 관리하고자 하는 것이 주 목적. 개발의 완성도가 높아짐. 가장 현실적인 모형
•
단점 : 요구 사항 분석이 잘못될 경우 위험 요소를 발견하지 못하고 프로젝트를 진행하면 비용 多
위험 분석 평가에 의존하기 때문에 개발과 유지보수를 명확히 구분하기 어려움
계획 및 정의 → 위험 분석 → 개발 단계 → 고객 평가 (무한루프)
1.
요구사항을 분석하여 개발 목적, 제약 조건 등을 설정하여 계획을 수립
2.
위험 요소를 분석하고 평가를 통해 프로젝트를 진행할지 중단할지 결정
3.
개선된 프로토타입(시제품)을 개발함
4.
개발 과정에서 나온 결과(시제품)을 평가함.
애자일(agile) 방법
개발자들이 설계와 문서에 치중하다보면 시스템에 집중을 못하는 경우가 있어 시스템에 초점을 두는 방법.
사용자가 빈번하게 요구 사항을 변경하면 문서화 작업을 자주 하게 된다. 이를 보완해 문서화를 최소화 하고 시스템을 구현하여 사용자에게 빨리 제공할 수 있는 방법.(XP, scrum, crystal 등이 있다)
핵심가치는 다음과 같다.
•
프로세스와 도구 중심이 아닌 개개인과의 상호 소통을 중시
•
문서 중심이 아닌 실행 가능한 소프트웨어를 중시
•
계약과 협상 중심이 아닌 고객과의 협력을 중시
•
계획 중심이 아닌 변화에 대한 민첩한 대응을 중시
XP
문서 작업보다 프로그래밍에 중점을 두는 모델. 사용자와 개발자가 상주하며 완벽한 시스템을 만드는데 중점을 두고 있다. 개발자, 관리자, 사용자의 역할이 구분되어야 한다.
사용자 스토리 → 아키텍처 스파이크 → 릴리즈 계획 → 반복(주기 개발) → 인수 테스트 → 작은 릴리즈
•
사람 중심의 방법으로써 5~10명의 프로그래머와 사용자가 한 장소에서 일함
•
짝 프로그래밍(30분 단위로 한명은 코딩하고 한명은 검사하는 역할을 번갈아가면서 함)
•
요구사항의 변화가 개발 후반이라도 반갑게 수용해야 함.
•
소프트웨어를 사용자에게 자주 전달해야 한다.
•
테스트 코드를 작성함으로써 디버깅 시간이 적게 걸려 개발 속도가 빠르고 유지 보수가 용이
•
작업량을 최소화 하기 위해 일정한 일정이 필요하다.
•
5가지 핵심가치 : 의사소통, 단순성, 피드백, 용기, 존중
스크럼 모델(scrum)
sprint라는 30일 주기를 기반으로 진행.
솔루션에 적용할 것들의 우선순위를 매기고 목록으로 열거하여 나누어 개발을 진행함.
일일 회의 및 점검을 통해 한 일을 목록에서 제거하고 우선순위를 참고하여 할 일을 분배함.
제품 기능 목록 작성 → 스프린트 계획 회의 → 스프린트 수행 → 스프린트 개발 완료 → 검토
핵심 가치 : 확약, 전념, 정직, 존중, 용기
•
product backlog : 제품에 담고자 하는 기능의 우선순위를 책임자가 결정
•
sprint backlog : 하나의 스프린트 동안 개발할 목록 작성. 할일→진행중→완료 순으로 진행
lean 스타트업
제품의 아이디어 및 비즈니스 모델에 대한 가설에 기반해 최소 기능을 갖춘 제품(MVP)을 빠르게 출시하고 잠재 고객들의 반응을 측정해 문제점을 고치거나 과감히 Pivot하는 것 (lean canvas 활용)
아이디어 구상 → MVP 개발 및 출시 → 측정 → 학습
2. 소프트웨어 프로젝트 계획
프로젝트 계획 수립 및 목적
프로젝트 범위, 프로젝트 자원, 프로젝트 추정, 프로젝트 일정 을 미리 수립하여 여러 위험성을 최소화 함.
(범위와 자원 부분은 형식적인 내용이므로 패쓰, 추정 역시 우리가 할 부분이 아니므로 패쓰)
프로젝트 일정
PERT
모든 업무를 파악하고 업무 별 낙관적 시간/통상적 시간/비관적 시간을 산정하여 예측함.
활동 시간의 평균과 분산을 구하는 PERT만의 공식이 존재함
WBS(업무분해기술)
실행할 작업을 산출물 중심으로 분할한 계층 구조. 소규모 작업 단계로 구성하며 우선순위, 상관 관계를 도출함. 어떤 작업으로 이루어지는지를 알아내는 것. PERT는 어떤 순서로 할 것인가를 정하는 것.
재밌는 예시가 있길래 가져와봤습니다.^^
간트 차트
프로젝트를 이루는 소작업별로 언제 시작하고 언제 끝나야 하는지를 한 눈에 볼 수 있도록 그린 프로젝트 일정표. 자원 배치와 인원 계획에 유용하게 사용됨.
3. 요구사항 분석 모델과 기법
자료 요청 시 추가해드리겠습니다. 일단 패쓰
4. 소프트웨어 설계의 기본 원칙
설계 구분
•
관리자적 관점 : 기본 설계(자료 구조), 상세 설계(구체적인 자료구조와 알고리즘)
•
기술자적 관점 : 데이터 설계(개체관계 다이어그램), 구조 설계(구조를 개발, 모듈로 분해, 인터페이스 정의), 절차 설계(흐름도, 자료명세서, 자료 상태도)
•
사용자적 관점 : 내부 설계(세부적인 절차를 개념화, 명세화), 외부 설계(다른 시스템과의 인터페이스 등 외부의 특성을 명세화)
설계 프로세스
5. 소프트웨어 설계 방법
데이터 설계
= 데이터 베이스 설계 (아래는 ER 다이어그램 예시)
아키텍처 설계
프로그램 구조를 개발하고 구성 요소들 간의 관계를 정의하는 것.
가장 큰 소픈트웨어 구조인 서브시스템, 패키지, 테스트 등을 명세하는 것.
개인적인 생각으로 지금 하고있는 플로우차트로도 충분할 것 같아 가볍게 적고 넘어갑니다.
인터페이스 설계
소프트웨어, 시스템, 사용자 등의 상호작용을 위해 어떻게 통신하는지 기술하는 과정
약간 뻔한 부분이라 크게 의미 없음
프로시저 설계
DFD(Data flow diagram)
우리가 하고 있는 플로우 차트가 이에 해당
6. 소프트웨어 테스팅 기법
화이트박스 테스트, 루프 테스트, 블랙박스 테스트 등등 많은데 아직 필요한 내용은 아니라서 패쓰
