소프트웨어 설계 - 요구사항 확인

소프트웨어 생명 주기 : 소프트웨어를 개발 과정을 단계별로 나눔

< 종류 >

1. 폭포수 모형

● 한 단계가 끝나야 다음 단계로 이동 가능

● 매뉴얼 작성

-> 매뉴얼 : 프로그램 사용/운영 내용 기술

● 결과물이 명확하게 산출  ● 병행 수행 X

2. 프로토타입 모형

● 시제품은 User와 System 사이의 인터페이스에 중점 두어 개발

● 폭포수 모형의 단점 보완( 개발 완료 시 오류 발생 )

3. 나선형 모형

● 점진적 모형  ● 위험 관리, 최소화 목적  ● 추가된 요구사항 첨가 가능  ● 대규모 프로젝트

4. 애자일 모형

● 고객의 요구사항 변화에 유연하게 대응  ● 일정 주기 반복하며 개발과정 진행

● 스프린트, 이터레이션이라는 짧은 주기 반복

● 요구사항에 우선순위 부여  ● 소규모 프로젝트  ● 스크럼, XP, ASD

-> 애자일 개발 4가지 핵심 가치

상호작용, 실행되는 SW, 고객과 협업, 변화의 반응

 

스크럼 : 팀 중심

1. 제품 책임자( PO )

● 제품 이해 높고, 요구사항 책임지고 의사 결정할 사람

● 백로그 작성, 백로그에 대한 우선순위 지정

-> 백로그 : 요구사항에 우선순위 부여

2. 스크럼 마스터( SM )

● 조언을 해주는 사람

3. 개발팀( DT )

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

< 개발 과정 >

1. 제품 백로그

2. 스프린트 계획 : 스프린트 백로그 작성

3. 스프린트 : 실제 개발 작업 진행하는 과정( 2 – 4주 )

4. 일일 스크럼 : 짧은 시간동안 진행 상황 점검, 소멸 차트

-> 소멸 차트 : 시간의 경과에 따라 남은 작업 시간을 그래프로 표현

5. 스프린트 검토 : 사용자가 포함된 참석자 앞에서 테스팅

6. 스프린트 회고 : 개선될 점, 규칙 준수를 확인하고 기록

 

XP : 요구사항에 유연하게 대응, 고객의 참여, 개발 과정 극대화

● 짧고 반복적인 개발 주기, 단순한 설계  ● 소규모 프로젝트

● 릴리즈의 기간을 잛게 반복, 고객의 요구사항 반영에 대한 가시성 높임

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

< XP 개발 단계 >

1. 사용자 스토리 : 요구사항을 시나리오로 표현

2. 릴리즈 계획 : 부분 혹은 전체 개발 완료 시점에 대한 일정 수립

3. 스파이크 : 요구사항의 신뢰성을 높이고 위험 감소 위해 별도로 만드는 간단한 프로그램

4. 이터레이션 : 하나의 릴리즈를 더 세분화

5. 승인 검사 : 고객이 직접 수행

6. 소규모 릴리즈 : 고객의 요구사항에 좀 더 유연하게 대응 가능

< XP 주요 실천 방법 >

● Pair Programming : 개발 책임 나눔

● Test-Driven Development : 테스트 케이스 작성

● Whole Team : 각자 자신의 역할이 있고 그 역할에 대한 책임 가짐

● Continuous Integration : 하나의 작업이 마무리 될 때마다 지속적으로 통합

 

현행 시스템 파악

< 1단계 >

1. 시스템 구성 파악 : 기간 업무/지원업무

2. 시스템 기능 파악 : 주요 기능/하부 기능/세부 기능

3. 시스템 인터페이스 파악 : 데이터 종류, 형식, 프로토콜, 주기 명시

< 2단계 >

1. 아키텍처 구성 파악 : 어떤 기술 요소들이 사용되는지 표현

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

< 3단계 >

1. 하드웨어 구성 파악 : 서버의 주요 사양, 수량, 이중화의 적용 여부 명시

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

 

OS : 컴퓨터 시스템의 자원들을 효율적으로 관리

< 고려사항 >

● 가용성 : OS 고유 장애 발생 가능성, 메모리 누수로 인한 성능 저하 및 재가동

● 성능 : 대규모 동시 사용자 요청에 대한 처리, 대규모 및 대용량 파일 작업에 대한 처리

● 기술 지원 : 여러 사용자들 간 정보 공유

 

DBMS : User와 DB 사이에서 User의 요구에 따라 정보를 생성, DB 관리, 데이터 종속성과 중복성 문제 해결

< 고려사항 >

● 가용성 : 백업이나 복구의 편의성

● 성능 : 대규모 데이터 처리 성능, 대용량 트랜잭션 처리 성능

 

WAS( Web Application Server ) : 데이터 접근, 세션 관리, 트랜잭션 관리

< 고려사항 >

● 가용성 : WAS 결함 등으로 인한 패치 설치를 위한 재가동, 안정적인 트랜잭션 처리

● 성능 : 대규모 트랜잭션 처리 성능, 다양한 설정 옵션 지원

 

요구사항 : SW 개발이나 유지 보수 과정에서 필요한 기준과 근거 제공

-> 기능 요구사항

● 시스템이 뭘 하는지, 어떤 기능을 수행하는지  ● 사용자가 시스템을 통해 제공받기를 원하는 기능

-> 비기능 요구사항

● 시스템 장비 구성, 성능, 인터페이스, 데이터, 테스트, 보안, 품질

-> 사용자 요구사항

● 사용자 관점에서 본 시스템이 제공해야 할 요구사항

-> 시스템 요구사항

● 개발자 관점에서 본 시스템 전체가 사용자와 다른 시스템에 제공해야 할 요구사항

< 요구사항 개발 과정 >

1. 도출

● 지속적 반복  ● 인터뷰, 설문, 브레인 스토밍, 유스케이스

2. 분석

● 요구사항이 불명확/모호한 것 발견하여 걸러냄

3. 명세

● 기능 요구사항 전부 기술, 비기능 요구사항은 필요한 것만 기술

● 사용자가 이해하기 쉬우며, 개발자가 효과적으로 설계할 수 있도록 작성

4. 확인

● 요구사항 명세서가 정확하고 완전하게 작성되었는지 검토

< 요구사항 분석 >

1. 요구사항 분류

2. 개념 모델링

● 단순화, 개념적으로 표현  ● 개체 간 관계 및 종속성 반영  ● UML로 모델링 표기

● 유스케이스 다이어그램, 데이터 흐름 모델, 객체 모델, 데이터 모델

3. 요구사항 할당

● 구성 요소 식별

4. 요구사항 협상

● 요구사항이 서로 충돌될 경우 해결

1. 요구사항과 자원이 충돌  2. 기능/비기능 요구사항 충돌

5. 정형 분석

● 요구사항을 수학적 기호로 표현 후 분석  ● 자원이 배정되기 전에 수행

< 종류 >

1. 요구사항 검토 : 요구사항을 훑어보면서 확인

2. 프로토 타이핑 : 프로토 타입 만든 후 개발 진행 동안 도출되는 요구사항 반영

-> 장점

● 최종 시스템 완성 전 추가/변경 요구사항이나 아이디어에 대한 피드백 가능

● 개발될 시스템의 사용에 대한 문제점을 시스템 완성 전 식별 가능

-> 단점

● 프로토 타입 제작에만 집중 될 수 있음

● 지속적이고 반복적인 프로토타입의 개선으로 인한 비용 부담

3. 모델 검증 : 개발된 모델이 요구사항을 충족시키는지 검증

4. 인수 테스트 : 사용자 입장에서 확인

 

UML : 객체지향 방법론의 장점 통합( OMG에서 표준으로 지정 )

1. 사물 : 다이어그램 안에서 관계가 형성될 수 있는 대상들

● 구조, 행동, 그룹, 주해

2. 관계 : 사물과 사물 사이의 연관성 표현

● 연관 관계

P.51 – 54

● 다이어그램 : 여러 관점에서 시스템을 가시화한 뷰 제공

-> 정적 모델링( 구조적 다이어그램 )

클래스, 객체, 컴포넌트, 배치, 복합체 구조, 패키지

< 컴포넌트와 배치 다이어그램은 구현 단계에서 사용 >

-> 동적 모델링( 행위 다이어그램 )

유스케이스, 시퀀스, 커뮤니케이션, 상태, 활동, 상호작용 개요, 타이밍