1과목 소프트웨어 설계 (1)

1. 소프트웨어 생명주기 (Software Life Cycle)

- 소프트웨어 개발 방법론의 바탕

- 소프트웨어를 개발하기 위해 정의, 운용, 유지보수

- 개발단계, 각 단계의 주요 활동, 활동의 결과 산출

- 표현하는 형태 : 소프트웨어 생명 주기 모형 = 소프트웨어 프로세스 모형 = 소프트웨어 공학 패러다임

 

2. 소프트웨어 공학

- Software Engineering : 소프트웨어의 위기를 극복하기 위한 방안으로 연구된 학문, 여러가지 방법론과

도구, 관리 기법등을 통하여 소프트웨어의 품질과 생산성 향상을 목적

 

기본원칙 1) 현대적인 프로그래밍 기술을 계속적으로 적용

               2) 개발된 소프트웨어의 품질이 유지되도록 지속적으로 검증

               3) 소프트웨어 개발 관련 사항 및 결과에 대한 명확한 기록 유지

 

3. 폭포수 모형 (Waterfall Model)

- 소프트웨어 개발도 이전 단계로 돌아갈 수 없다는 전제하에 각 단계를 확실히 매듭짓고 검토 승인 후 다음

단계를 진행하는 개발 방법론

- 가장 오래되고 가장 폭넓게 사용된 전통적인 소프트웨어 생명 주기 모형, 고전적 생명 주기 모형

- 성공 사례가 많음

- 타당성 검토 -> 계획 -> 요구분석 -> 설계 -> 구현(코딩) -> 시험(검사) -> 유지보수

 

4. 나선형 모형(Spiral Model, 점진적 모형)

- 보헴(Bohem)이 제안

- 폭포수 모형과 프로토 타입 모형의 장점 + 위험 분석 기능

- 나선을 따라 돌듯이 여러번의 개발과정을 거쳐 점진적으로 완성

- 소프트웨어를 개발하면서 발생할 수 있는 위험을 관리하고 최소화 목적

- 누락되거나 추가된 요구사항을 첨가 할 수 있고, 정밀, 유지보수 과정이 필요 X

 

계획수립 -> 위험분석 -> 개발 및 검증 -> 고객 평가 (반복)

 

 

5. 애자일 모형(Agile Model)

- 민첩한, 기민한 이라는 의미로, 고객의 요구사항 변화에 유연하게 대응할 수 있도록 일정한 주기를 반복

하면서 개발과정 진행

- 좋은 것을 빠르고 낭비 없게 만들기 위해 고객과의 소통에 초점을 맞춘 방법론을 통칭

- 스크럼(Srcum) , XP(eXtreme Programming),  칸반(Kanban), Lean, 크리스탈(Crystal), ASD(Adaptive Software Development), 기능 중심 개발(FDD) , DSDM, DAD

 

핵심가치

1) 프로세스와 도구보다는 개인과 상호작용에 더 가치를 둔다

2) 방대한 문서보다 실행되는 SW에 더 가치

3) 고객과 협업에 더 가치

4) 계획을 따르기보단 변화에 반응

 

6. 스크럼(Scrum)

- 팀이 중심이 되어 개발의 효율성을 높인다

- 팀원 스스로가 스크럼 팀을 구성(self-organizing)해야 하며, 개발 작업의 모든 것을 스스로 해결(cross-functional)

- 제품 책임자, 스크럼 마스터, 개발팀

 

제품 책임자(PO, Product Owner)

- 개발될 제품에 대한 이해도가 높고, 요구사항을 책임지고 의사 결정 할 사람

- 제품을 테스트 하면서 주기적으로 요구사항 갱신

 

스크럼 마스터(SM, Scrum Master)

- 스크럼 팀이 잘 수행 되도록 조언을 해주는 가이드 역할

- 통제를 하진 않음

- 일일 스크럼 회의에서 진행사항 점검, 장애 요소 공론화

 

개발팀(DT, Development Team)

- 제품 책임자와 스크럼 마스터를 제외한 모든 팀원

- 개발자 외에도 디자이너, 테스터 등 모든 사람

- 보통 최대 7~8명

 

 

7. 스크럼 개발 프로세스

 

제품 백로그(Product Backlog)

- 제품 개발에 필요한 모든 요구사항을 우선순위에 따라 나열한 목록

 

스프린트 계획 회의(Sprint Planning Meeting)

- 이번 스프린트에서 수행할 작업을 대상으로 단기 일정 수립

 

스프린트(Sprint)

- 실제 개발 작업을 진행하는 과정

- 2~4주 기간 내 진행

- 속도를 추정한 후 개발 담당자에게 할당

 

일일 스크럼 회의(Daily Scrum Meeting)

- 모든 팀원이 매일 약속된 시간에 약 15분 정도의 짧은 시간 동안 진행 상황을 점검

- 회의는 보통 서서 진행, 남은 작업 시간을 소멸차트(Burn-down Chart)에 표시

 

스프린트 검토 회의(Sprint Review)

- 부분 또는 전체 완성 제품이 요구사항에 잘 부합되는지 사용자가 포함된 참석자 앞에서 테스팅 수행

 

스프린트 회고(Sprint Retrospective)

- 스프린트 주기를 되돌아보며 정해놓은 규칙을 잘 준수했는지 개선점 없는지 확인 후 기록

 

 

8. XP(eXtreme Programming)

- 수시로 발생하는 고객의 요구사항에 유연하게 대응하기 위해 고객의 참여와 개발 과정의 반복을 극대화하여

개발 생산성을 향상시키는 방법

- 짧고 반복적인 개발주기, 단순한 설계, 고객의 적극적인 참여로 소프트웨어 빠르게 개발

- 릴리즈 기간을 짧게 반복하면서 고객의 요구사항 반영에 대한 가시성 높임

- 핵심가치 : Communication(의사소통) , Simplicity(단순성), Courage(용기), Respect(존중), Feedback(피드백)

 

9. XP 주요 실천

 

- Pair Programming(짝 프로그래밍) : 다른 사람과 함께 프로그래밍 수행, 개발에 대한 책임을 공동으로 나눠 환경 조성

- Collective Ownership(공동 코드 소유) : 개발 코드에 대한 권한과 책임을 공동 소유

- Test-Driven Development(테스트 주도 개발) : 개발자가 실제 코드를 작성하기 전에 테스트 케이스를 먼저 작성,

테스트가 지속 되도록 자동화된 테스팅 도구(구조, 프레임워크) 사용

- Whole Team(전체 팀) : 개발에 참여하는 모든 구성원의 역할 책임 가짐

- Continuous Integration(계속적인 통합) : 모듈 단위로 나눠서 개발된 코드들은 하나의 작업 마무리 될때마다 지속 통합

- Design Improvement(디자인 개선) = Refactoring(리팩토링) : 프로그램 기능의 변경없이, 단순화, 유연성 강화 등을 통해 시스템 재구성

- Small Releases(소규모 릴리즈) : 릴리즈 기간을 짧게 반복하여 고객의 요구변화에 신속 대응

 

 

10. 현행 시스템 파악

 

1단계 - 시스템 구성 파악 : 조직의 주요 업무를 담당하는 기간 업무와 이를 지원하는 지원업무로 구분

          - 시스템 기능 파악 : 현재 재공하는 기능들을 주요 기능, 하부 기능, 세부 기능으로 구분하여 계층형

          - 시스템 인터페이스 파악 : 단위 업무 시스템 간에 주고받는 데이터 종류, 형식, 프로토콜, 연계 유형, 주기 명시

 

2단계 - 아키텍처 구성 파악 : 최상위 수준에서 계층별로 표현한 아키텍처 구성도 작성

          - 소프트웨어 구성 파악 : 소프트웨어들의 제품명, 용도, 라이선스 적용방식, 라이선스 수 명시

 

3 단계 - 하드웨어 구성 파악 : 단위 업무 시스템들이 운용되는 서버의 주요 사양과 수량, 서버의 이중화 적용 여부

           - 네트워크 구성 파악 : 서버의 위치, 서버 간의 네트워크 연결 방식을 네트워크 구성도로 작성