요구사항 확인 (1) - (소프트웨어 설계) [정보처리기사 필기]

 

소프트웨어 생명 주기

소프트웨어 생명 주기(Life Cycle)는 소프트웨어 개발 방법론의 바탕. 운용 유지보수 등의 과정을 단계별로 나눈 것.

각각의 개발 단계와, 주요 활동 및 결과를 산출물로 표현하였다.

생명 주기를 표현하는 형태를 생명 주기 모형, 프로세스 모형, 공학 패러다임이라고 한다.

1) 폭포수 모형

가장 오래된 프로세스 모형으로 폭포처럼 선형적으로 진행. (고전 모형)

각 단계를 완전히 끝낸 후에 다음 단계로 넘어감. (역행, 병렬 불가능)

각 단계별 직능 중심의 조직이기 때문에, 결과물을 명확히 정의해서 각 단계의 정보를 다음 단계로 넘겨야 함.

또한 메뉴얼 역시 작성해야 함

장점 : 모델이 단순하여 이해하기 좋음, 각 단계가 명확하여 관리 쉬움 -> 대규모 프로젝트에 적합

단점 : 이전 단계의 문제 발견 시 비용이 크게 소요, 테스트, 사용자의 평가가 마지막에 이루어짐

 

2) 프로토타입 모형

요구사항에 대한 피드백을 받기 위해 실험적으로 만들어 사용자에게 보여주고 평가하게 함

폭포수 모델의 단점을 보완하기 위해 만들어짐

사용자와 시스템 사이 인터페이스에 중점을 둠

장점 : 의사소통 원활, 문제점을 빨리 파악하여 반영

단점 : 프로토타입 개발에 비용 소모, 고객의 오인으로 과도한 요구 가능성

 

3) 나선형 모형

보헴에 의해 제안되어 처음으로 위험이란 개념을 도입하고, 이를 분석,고려한 모델.

나선과 같이 여러 개발 과정을 거쳐 점진적으로 소프트웨어 개발.

별도의 유지보수 과정이 필요 없고, 위험 관리를 통한 리스크를 최소화.

장점 : 비선형, 반복적 개발로 품질을 높일 수 있음, 변경에 유연하게 대처

단점 : 초기 위험 분석을 잘못하면 대참사 발생

 

4) 애자일 모형

짧은 싸이클을 반복하는 방법으로, 적응력 높은 개발 기술의 총칭.

스크럼, xp, 칸반, Lean, 크리스탈, ASD, FDD, DSDM 등

각각의 주기(ex) 스프린트, 이터레이션)마다 평가와 요구를 수용

요구사항을 중요시하고, 우선순위를 부여하여 개발 진행

1. 형식적인 문서보다는 커뮤니케이션 중시
2. 사용자는 문서가 아니라, sw를 통하여 요구를 확인
3. 사용자의 요구는 프로젝트 중간에 바뀔 수 있음을 항상 고려
4. 짧은 주기 동안 요구정의, 구현, 테스트까지 이루어지며 반복 주기를 통해 지속적으로 개선

 

스크럼 기법

애자일 모델의 하나로 팀이 중심이 되어 개발의 효율성을 높이는 방법.

스크럼 구성 요소

제품 책임자 (PO)

• 제품에 대한 이해도가 높고, 요구사항을 책임. 주로 의뢰자나 사용자
• 이해관계자들의 의견을 통해 제품에 대한 요구사항 작성
• 요구사항을 통한 백로그(할 일) 작성 -> 우선순위 지정 가능
• 팀원은 백로그 스토리 작성, 우선순위 갱신. 하지만 백로그 우선순위 지정은 PO만

스크럼 마스터 (SM)

• 팀이 잘 수행할 수 있도록 객관적이게 조언 해주는 가이드 역할.
• 일일 스크럼 회의(15분)를 주관하여 진행사항 점검, 장애 요소들 처리

개발 팀

• 개발자, 디자이너, 테스터 등 (보통 7~8명)

 

스크럼 개발 프로세스

제품 백로그

• 제품 개발에 필요한 요구사항을 우선순위에 따라 나열한 목록
• 요구사항에 따라 지속적으로 업데이트
• 사용자 스토리 기반으로 릴리즈 계획 수립

스프린트 계획 회의

• 스프린트 별로 수행할 작업에 따른 단기 일정 수립
• 요구사항을 태스크(작업 단위)로 분할
• 개발자 별로 태스크에 따른 스프린트 백로그 작성

스프린트

• 개발 작업 진행 과정 (2~4주)
• 백로그에 작성된 태스크에 따라 작업 시간, 양 고려하여 할당
• 개발자가 원하는 태스크를 고를 수 있도록 하는 것이 좋음
• 태스크는 To Do, In Progress, Done의 상태

스크럼 회의

• 매일 매일 약속된 시간에 15분 정도 진행 상황 점검
• 스크럼 마스터가 장애 요소에 대해 도움
• 남은 작업 시간은 소멸 차으테 표시

스프린트 검토 회의

• PO가 개선할 사항에 대한 피드백 정리 -> 다음 스프린트에 반영하도록 백로그 업데이트

스프린트 회고

• 스프린트 이후 규칙 준수, 개선점 점검

 

XP (Extreme Programming) 기법

소규모 조직이 변경이 많은 요구 사항에 유연하게 대응하기 위한 기법

고객의 참여와 개발 과정의 반복을 극대화 -> 생산성을 향상시킴. (빠르게 개발하기)

릴리즈 기간을 짧게 반복 -> 요구사항에 대한 가시성을 높임.

핵심 가치 : 의사소통, 단순성, 용기, 존중, 피드백

개발 프로세스

사용자 스토리 : 고객의 요구사항을 간단한 시나리오로 표현

릴리즈 계획 수립 : 부분적으로 기능이 완료된 제품 제공에 대한 계획

스파이크 : 요구사항 신뢰도 높이고, 기술 문제에 대한 위험 감소를 위해 별도로 만드는 프로그램

이터레이션 : 릴리즈를 더 세분화 한 단위

승인 검사 (인수 테스트) : 릴리즈 단위의 부분 완료 제품이 구현되면 수행 (고객이 직접)

소규모 릴리즈 : 고객의 요구사항에 대응하여 개발, 최종 테스트 수행 후 결과물 전달.

 

XP 실천 방법

짝 프로그래밍 (Pair Programming)

• 두 명의 프로그래머가 하나의 컴퓨터 공유 -> 한명은 코딩, 한명은 검토
• 오히려 유지보수에 대한 비용이 감소되어 각자 코딩하는거랑 차이가 없다고 함.

테스트 주도 개발(Test-Driven Development)

• 테스트 시나리오를 먼저 작성하고, 이를 위한 코드를 생성 -> 할 일 정확히 파악

전체 팀 (Whole Team)

• 모든 팀원은 다 역할이 있고, 이에 따른 책임을 가져야 함.

계속적인 통합(Continuous Integration)

• 모듈 단위로 나누어 코드 개발, 지속적으로 통합 (매일 빌드하기)

디자인 개선/리팩토링 (Design Improvement)

• 프로그램 기능의 변경은 없이 단순화, 유연성 강화 등으로 시스템 재구성

소규모 릴리즈 (Small Releases)

• 릴리즈 기간을 짧게 하여 고객의 요구 변화에 신속하게 대응

 

현행 시스템 파악 절차

1단계

• 시스템 구성 파악 : 조직의 주요 업무를 담당하는 기간 업무, 지원 업무로 구분
• 시스템 기능 파악 : 단위 업무 시스템이 제공하는 기능들을 주요, 하부, 세부 기능으로 구분하여 계층형으로 표시
• 시스템 인터페이스 파악 : 단위 업무 시스템 간 주고받는 데이터의 정류, 형식, 프로토콜, 연계 유형 주기 등 명시

2단계

• 아키텍처 구성 파악 : 어떤 기술 요소들이 사용되는지 최상위 수준에서 계층별료 표현한 구성 파악
• 소프트웨어 구성 파악 : 단위 업무 시스템별 업무처리를 위해 설치된 sw의 제품명, 용도, 라이선스 등 명시

3단계

• 하드웨어 구성 파악 : 단위 업무 시스템들이 운용되는 서버의 주요 사양, 수량, 이중화 적용 여부 명시
  (이중화 : 운용 서버 장애 시 대기 서버 -> 서비스를 계속 유지할 수 있도록)
• 네트워크 구성 파악 : 서버의 위치, 서버 간 네트워크 연결 방식을 네트워크 구성도로 작성

 

개발 기술 환경 파악

개발하고자 하는 소프트웨어와 관련된 환경 파악

운영체제(OS)

컴퓨터 시스템 자원을 효율적으로 관리, 사용자가 컴퓨터를 편리하게 사용할 수 있는 환경을 제공하는 소프트웨어

고려사항	내용
가용성	시스템 장시간 운영으로 인한 장애 발생 가능성, 메모리 누수로 인한 성능 저하
성능	대규모 동시 사용자 요청, 대용량 파일 작업, 메모리 크기
기술지원	오픈 소스 여부, 사용자들 간의 정보 공유, 제작자의 기술 지원
호환성	설치 가능 HW, 주변기기 지원 여부
구축 비용	라이선스 정책 및 비용, 유지 관리 비용, 총 소유 비용

 

데이터베이스 관리 시스템(DBMS)

사용자와 데이터베이스 사이에서 사용자의 요구에 따라 정보를 생성, DB를 관리해 주는 소프트웨어

오라클, IBM DB2, MYSQL, SQLite, MongoDB 등 존재

고려사항	내용
가용성	시스템 장시간 운영으로 인한 장애 발생 가능성
성능	대규모 데이터 처리 기능, 대용량 트랜잭션 처리 기능
기술지원	오픈 소스 여부, 사용자들 간의 정보 공유, 제작자의 기술 지원
호환성	설치 가능 OS, JDBC, ODBC 호환 여부
구축 비용	라이선스 정책 및 비용, 유지 관리 비용, 총 소유 비용

 

웹 어플리케이션 서버(WAS, Web Application Server)

사용자의 요구에 따라 동적인 콘텐츠를 처리하기 위해 사용되는 미들웨어 (웹 서버 : 정적)

Tomcat, GlassFish, JEUS 등 존재

고려사항	내용
가용성	시스템 장시간 운영으로 인한 장애 발생 가능성, 안정적 트랜잭션 처리
성능	대용량 트랜잭션 처리 기능, 다양한 설정 옵션
기술지원	오픈 소스 여부, 사용자들 간의 정보 공유, 제작자의 기술 지원
구축 비용	라이선스 정책 및 비용, 유지 관리 비용, 총 소유 비용

 

전문가가 아니라 정확하지 않은 지식이 담겨있을 수 있습니다.
언제든지 댓글로 의견을 남겨주세요!