소프트웨어 개발

개발 수명周期은 아이디어부터 완성되고 유지보수된 소프트웨어에 이르기까지의 단계 집합입니다. 이는 프로젝트를 계획, 관리 및 통제하기 위해 존재하며, 올바른 제품을 제때에 좋은 품질로 제작하도록 합니다.

수명주기가 필요한 이유

"개발 수명주기의 목적"에 대한 채점자 목록: 큰 프로젝트를 계획하고 관리할 수 있는 단계로 나눕니다; 설계와 코딩 시작 전에 요구사항을 찾고 합의되도록 보장합니다; 테스트와 문서화를 내재화하여 끝부분으로 미루지 않습니다; 팀이 마일스톤에 따른 진행 상황을 추적하고 리스크를 관리할 수 있게 합니다; 그리고 고객에게 작업을 검토할 수 있는 정의된 지점을 제공합니다. 이를 사용하지 않으면 팀은 먼저 코딩을 시작하고 나중에 잘못된 제품을 만들었다는 것을 발견하게 됩니다.

다양한 수명주기가 존재하는 이유

모든 프로젝트에 맞는 단일 수명주기는 없으므로 여러 개발 수명주기가 존재합니다. 선택은 프로젝트의 크기와 복잡성, 시작 시 요구사항의 명확성, 예상되는 변화의 정도, 리스크 수준, 팀, 그리고 마감 기일에 따라 달라집니다.

일반적인 모델

• 워터폴(Waterfall) — 선형 순서(분석 → 설계 → 코딩 → 테스트 → 유지보수)이며, 각 단계가 완료되어야 다음 단계가 시작됩니다. 명확하고 문서화가 잘 되어 있으며, 안정적인 요구사항에 적합하지만, 프로젝트 중반의 변화에는 대응이 어렵고 고객이 끝까지 작동하는 것을 보지 못합니다.
• 반복적 모델(Iterative model) — 반복된 과정으로, 각 과정에서 부분적인 버전을 생성하여 검토하고 다듬습니다. 문제를 더 일찍 포착할 수 있습니다; 요구사항이 시간이 지나면서 발견되는 경우에 적합하지만, 예측이 어렵습니다.
• 신속 응용 개발(Rapid Application Development, RAD) — 프로토타입과 사용자 피드백을 적극 활용합니다. 첫 번째 배포 속도가 매우 빠릅니다; 변동하는 요구사항에 적합하지만, 사용자의 가용성에 의존하며 소규모 시스템에 적합합니다.
• 애자일(Agile) — 짧은 반복(스프린트), 지속적인 협업 및 테스트를 특징으로 합니다. 유연하고 적응적이지만, 전념하는 고객과 숙련된 팀이 필요합니다.

원리, 장점 및 단점 — 채점 기준서에 나열된 내용.

작중 예제. 한 회사는 새로운 게임 콘솔의 웹사이트를 가장 먼저 출시해야 하며, 콘솔의 기능이 발표됨에 따라 디자인이 변경될 것입니다. 가장 적합한 수명주기를 명칭하고 그 이유를 제시하시오.

RAD. 사이트의 프로토타입을 몇 일 내에 만들어 사용자에게 보여주고 요구사항이 변경됨에 따라 다듬을 수 있습니다. 사이트는 프로토타입 기반 접근法에 적합할 만큼 작으며, 빠른 배포가 주요 요구사항입니다. 워터폴은 페이지가 하나도 구축되기 전에 요구사항을 고정하고 끝까지 아무것도 제공하지 못합니다.

표준 단계

각 단계에는 목적, 산출물 및 typical 활동이 있으며, "… 단계 설명" 질문은 이 중 두세 가지가 필요합니다.

• 분석(analysis) — 프로그램이 무엇을 해야 하는지 파악. 활동: 인터뷰, 설문 조사 및 기존 시스템 관찰; 타당성 연구; 이후 모든 단계를 검증하는 기준이 되는 요구사항(specification) 합의.
• 디자인(design) — 어떻게 구현할지 결정. 산출물: 구조도(structure chart)(모듈 및 매개변수), 각 모듈용 플로우차트(flowcharts) 또는 가상코드(pseudocode), 식별자 표(identifier tables) 및 데이터 구조, 화면 및 파일 레이아웃, 그리고 코드 작성 이전에 사양서로부터 즉시 작성하는 테스트 계획(test plan).
• 코딩(coding) (구현) — 디자인에 따라 고수준 언어로 모듈 단위로 프로그램을 작성; 각 모듈은 작성되는 즉시 테스트됨.
• 테스팅(testing) — 테스트 계획(정상, 비정상, 극단, 경계 데이터)에 따라 프로그램을 실행하고 발견된 오류 수정; 통합, 알파, 베타, 수용性 테스트가 순서대로 진행됨.
• 유지보수(maintenance) — 출시 후 결함 수정, 신규 하드웨어/소프트웨어/법령에 대한 적응, 기능 개선(아래 참조).

작업 예제. 워터폴 도식 분석 → ? → ? → ? → 유지보수를 완성하고 디자인 단계에서 발생하는 과정을 설명하십시오.

The missing stages are Design, Coding, Testing. At the design stage the requirements are turned into a plan for the program: the problem is decomposed into modules (a structure chart), the algorithm for each module is written as pseudocode or a flowchart, the data structures and identifiers are chosen, the screens and files are laid out, and the test plan is written from the specification.

구조도

**구조 차트(structure chart)**는 프로그램을 모듈(서브루틴)으로 나누는 **계층적 분해(hierarchical decomposition)**와 그들 사이를 전달되는 파라미터를 보여줍니다. 각 모듈은 직사각형이며, 선은 호출자(call caller, 위)를 피호출자(callee, 아래)에 연결합니다. 작은 화살표는 아래로 가는 데이터와 위로 돌아오는 결과를 나타냅니다. 이 디자인을 후속하는 **가상 코드(pseudocode)**로 변환할 수 있습니다.

                CalculatePay
            /        |         \
       GetEmployee  CalculateBonus  CalculateTax
       Returns:     Takes: sales    Takes: gross
       employeeID   Returns: bonus  Returns: tax

이것은 설계 단계의 도구이며, 여기서 프로시저 서명(procedure signatures)을 읽을 수 있습니다.

The symbols the examiner asks about. A box is a module; a line links a caller (above) to the modules it calls (below), read left to right in the order they are called. A small arrow with an open circle at its tail is a data couple — a parameter passed down into a module or a value returned up; an arrow with a filled circle is a control couple, a flag (usually BOOLEAN) that tells the caller what happened. A diamond at a branch means selection: only one of the modules below it is called, depending on a condition. A curved arrow sweeping across the links means iteration: the modules under it are called repeatedly in a loop.

작은 예제 worked example. 네 개의 모듈이 PROCEDURE Main(), PROCEDURE ReadData(BYREF Count : INTEGER), FUNCTION IsValid(Value : INTEGER) RETURNS BOOLEAN 및 PROCEDURE Report(Total : INTEGER, Count : INTEGER)로 정의됩니다. Main은 ReadData를 호출한 뒤, 읽힌 각 값마다 IsValid을 한 번 호출한 후 Report를 호출합니다. 구조 차트를 설명하십시오.

상단에 Main, 그 아래 행에 ReadData, IsValid, Report가 왼쪽에서 오른쪽으로 호출 순서대로 배치됨. ReadData 연결선 위쪽으로 데이터 커플 Count(BYREF 매개변수가 돌아옴). IsValid 연결선 아래로 데이터 커플 Value, 위쪽으로 제어 커플(부울린 결과), 각 값에 대해 호출되므로 해당 연결선 위에 곡선 반복 화살표. Report 연결선 아래로 두 개의 데이터 커플 Total와 Count. 반대로 읽으면, 값을 반환하는 모든 모듈은 함수(function)이며, 헤더에는 RETURNS와 반환 타입이 필요합니다.

상태 전이 도표(state-transition diagram)

상태 전이 도표는 시스템이 가질 수 있는 **상태(states)**와 그들 사이를 이동시키는 **이벤트(events)**를 보여줍니다. 자동 판매기, 신호등, 사용자 인터페이스 등에 적합합니다. 상태 전이 도표는 알고리즘이나 시스템의 동작을 문서화하는 데 사용됩니다. 각 상태는 원이며, 각 전이는 이벤트로 라벨이 붙은 화살표입니다.

   coin inserted               item selected
[Idle] --------------→ [Awaiting selection] ----------→ [Dispensing]

누락된 전이를 쉽게 찾아낼 수 있게 해줍니다(예: "선택을 기다리는 동안 두 번째 동전이 삽입되면 어떻게 될까?").

Reading and drawing one. Each transition is labelled input | output (or condition | action): what happened, then what the system does as it changes state. A question gives a table of current state, input, output, next state and asks for the diagram, or the reverse — every row of the table is exactly one arrow. Check that every state has an arrow leaving it for every input that can occur, including the ones that leave the state unchanged (an arrow that loops back to the same state).

작은 예제. 펌프 컨트롤러에는 상태 *펌프 꺼짐(pump off)*과 *펌프 켜짐(pump on)*이 있습니다. 펌프 꺼짐 상태에서 입력 *낮은 수준 감지(low level detected)*은 출력 *펌프 작동(activate pump)*을 생성하고 펌프 켜짐 상태로 이동합니다; 펌프 켜짐 상태에서 *정상 수준 감지(normal level detected)*은 *펌프 정지(deactivate pump)*을 생성하고 펌프 꺼짐 상태로 이동합니다. 다른 모든 입력은 상태를 변경하지 않습니다. 표를 그리십시오.

"변경 없음" 행 두 개는 도식에서 루프 화살표로 나타납니다. 이 부분을 누락하면 완성도에 대한 점수를 잃습니다.

• 구문 오류 — 언어의 문법을 위반함(대괄호 누락, 키워드 오타). 번역 시에 포착되며, 수정되지 않으면 프로그램 실행이 불가능합니다.
• 실행 중 오류 — 실행 중 발생(0으로 나누기, 파일 못 찾기, 배열 인덱스 범위 초과). 프로그램이 충돌하거나 예외를 발생시키며, 체크 문구를 추가하여 수정합니다.
• 논리 오류 — 프로그램은 실행되지만 잘못된 결과를 출력함(+을 - 대신 사용, 1단위 차이 루프, 조건 순서 잘못 등). 가장 찾기 어렵습니다. 유일한 징후가 잘못된 출력이기 때문에, 신중한 테스트와 추적(tracing)을 사용해야 합니다.

*각 오류가 나타나는 시기: 구문 오류는 번역 시, 실행 중 오류는 실행 중, 논리 오류는 출력 시

결함 노출 및 방지. 결함은 테스트 계획에 따른 테스트, 드라이 런 또는 추적 표, 동료와의 워크스루, IDE 디버거(브레이크포인트, 스텝 단위로 실행, 변수 모니터링)에 의해 노출됩니다. 코딩 전에 설계(구조 차트, 가짜 코드), 의미 있는 식별자와 주석이 포함된 모듈형 코드, 모든 입력에 대한 검증, 실행 중 오류로 인한 프로그램 충돌 대신 예외 처리, 그리고 타이핑 중 IDE의 동적 구문 검사에 의해 방지됩니다.

해설 예제. 각 경우의 오류 유형과 그 현상을 서술하십시오. (a) Result <- STR_TO_NUM(x) / STR_TO_NUM(y)에 y = "0"을 입력하여 실행함. (b) 동일한 줄에 x = "12a"을 입력하여 실행함. (c) FOR i <- 1 TO 9로 작성한 루프가 10개 요소 배열을 처리함. (d) OUTPUT "Total: " Total에 콤마가 누락됨.

(a) 실행 중 오류 — 0으로 나누기; 해당 데이터로 이 줄이 실행될 때 프로그램이 충돌함. (b) 실행 중 오류 — 문자열을 숫자로 변환할 수 없음. (c) 논리 오류 — 프로그램은 실행되나 열 번째 요소를 처리하지 않아 출력이 잘못됨. (d) 구문 오류 — 명령문이 언어 규칙을 위반하여 프로그램 실행 전 번역기에 보고됨.

해설 예제. 다음 가짜 코드의 오류를 수정하십시오. 이 코드는 10개의 점수의 평균을 출력하도록 되어야 합니다.

Total <- 0
FOR i <- 1 TO 10
    INPUT Mark
    Total <- Total + Mark
NEXT i
Average <- Total / 9
OUTPUT "Average" Average

나눗셈은 9가 아닌 10이어야 함(논리 오류); 출력 줄에는 문자열과 값 사이에 콤마나 &이 필요함(구문 오류); 그리고 Average은 REAL로 declared되지 않았음(언어에 따라 구문 오류 또는 실행 중 오류). 어떤 줄이며 수정된 줄은 무엇인지 서술하시오: Average <- Total / 10.

• 드라이 런 — 종이에 코드를 추적으로 작성하며 각 변수의 값을 표에 기록함.
• 워크스루 — 팀이 코드를 검토하는 회의.
• 백색 박스 테스트 — 코드의 내부 구조를 기반으로 설계되어 모든 명령문, 분기 및 루프를 커버함.
• 흑색 박스 테스트 — 사양(specification)만으로 설계됨: 입력을 제공하고 출력을 확인함.
• 통합 테스트 — 모듈을 결합하여 그 간 인터페이스를 테스트함.
• 알파 테스트 α — 출시 전 개발자/사내에서 수행; 베타 테스트 β — 제한된 수의 실제 사용자가 자체 환경에서 수행.
• 수용 테스트 — 고객이 제품이 목적에 부합하는지 결정하기 위해 수행.
• 스텝 — 아직 존재하지 않는 모듈의 위치 표시자로서, 위쪽부터 아래로 내려가는 테스트(top-down)가 가능하게 함.

어떤 방법을 언제 사용할까. 드라이 런과 워크스루는 컴퓨터가 필요 없습니다. 드라이 런은 개인이 추적 표를 사용하여 알고리즘을 추적으로 하는 것이며, 워크스루는 저자가 코드를 줄마다 설명하고 팀원이 결함을 찾으며, 동시에 코드 이해를 팀 내에 확산시키고 설계를 검증하는 회의입니다. 백색 박스 테스트는 코드를 볼 수 있는 사람이 작성하여 모든 경로를 실행하도록 하며, 흑색 박스 테스트는 사양에서 작성되어 입력만 예상 출력과 비교하므로 사용자나 별도의 테스터가 수행할 수 있습니다. 통합 테스트는 모듈 테스트 이후에 이루어집니다: 개별적으로는 통과한 모듈이라도 서로 전달되는 데이터의 타입이나 순서가 틀리면 실패할 수 있습니다. 알파 테스트는 사내에서, 베타 테스트는 샘플 실제 사용자에게 릴리스 후보를 제공하여 실제 사용 중 발생한 결함을 보고하게 하고, 수용 테스트는 고객이 결제 전에 요구사항 대비 완성된 제품을 확인하는 것입니다. 스텝은 모든 모듈이 준비되기 전에 위쪽부터 아래로 내려가는 테스트를 시작할 수 있게 합니다.

Worked example. After the program passed its in-house tests it was given to a group of users to try before release. Name this type of testing, and state what happens next.

베타 테스트 — 실제 사용자가 자체 환경에서 개발자가 발견하지 못한 결함을 보고함. 결함이 수정된 후, 고객이 요구사항에 대해 수용 테스트를 수행하고 프로그램이 출시되며, 실사용 중 발견된 결함은 수정 유지보수(correction maintenance)를 통해 처리됨.

해설 예제. 워크스루를 통해 프로그램을 테스트하는 세 가지 장점을 제시하십시오.

오류는 코드를 작성하지 않은 사람에 의해 가정을 하지 않고 코드를 읽음으로써 발견됩니다. 논리는 테스트 데이터뿐만 아니라 설계 및 사양과 대조되어 검증되며, 여러 사람이 코드가 어떻게 작동하는지 학습하여 향후 유지보수에 도움이 되며, 테스트 데이터나 작동 중인 컴퓨터가 필요하지 않아 초기에 수행할 수 있습니다.

테스트 전략은 고수준 접근 방식입니다. 즉, 어떤 종류의 테스트를, 누가, 언제, 그리고 다음 단계로 넘어가기 위한 기준을 정의합니다. 테스트 계획은 테스트의 상세 목록입니다. 각 항목에는 입력 데이터, 예상 출력, 실제 출력을 기록하기 위한 열이 포함됩니다.

각 항목의 구성 내용. 테스트 전략은 어떤 단계에서 어떤 테스트 방법이 사용될지(프로그래머에 의한 모듈 테스트, 이후 통합, 알파, 베타, 수용), 각 단계의 책임자, 필요한 테스트 데이터, 그리고 다음 단계로의 전환 기준을 명시합니다. 테스트 계획은 개별 테스트를 나열합니다. 각 테스트마다 테스트 대상 모듈 또는 기능, 입력 데이터, 해당 데이터를 선택한 이유(정상, 비정상, 극단, 경계), 예상 결과, 실제 결과를 기록할 공간, 그리고 결과가 다를 경우의 조치 사항을 포함합니다. 계획은 프로그램이 우연히 하는 것이 아니라 해야 할 일을 테스트하기 위해, 사양을 바탕으로 설계 단계에서 작성됩니다.

테스트 데이터 선정

각 필드 또는 조건에 대해 세 가지 유형을 포함해야 합니다:

• 정상 데이터 — 유효 범위 내의 일반적인 값 (점수 0–100: 50, 75).
• 비정상 데이터 — 거절되어야 할 값 (-10, 200, "abc").
• 극단 데이터 — 여전히 수용되는 최대 및 최소 값 (0 및 100).
• 경계 데이터 — 가장자리에서의 값으로, 오프바이원 오류가 숨어 있는 곳 (각 수용된 극단 값과 그 바로 바깥에 있는 거절된 값: 0/-1, 100/101).

Worked example. A field accepts an exam mark from 0 to 100. Give test data of each kind with its expected result. Normal: 50 - accepted, a typical value inside the range. Abnormal: -10, 200, "abc" - all rejected, being out of range or the wrong data type. Extreme: 0 and 100 - the largest and smallest values that are still accepted. Boundary: the pairs straddling each edge - -1 rejected alongside 0 accepted, and 100 accepted alongside 101 rejected. Every value must carry its expected result, or the test plan proves nothing. Extreme and boundary are the pair most often confused: an extreme value sits inside and is accepted, while a boundary test is always a pair either side of the edge - which is exactly where off-by-one errors hide.

Worked example. A component passes if its weight, measured to the nearest gram, is within 3 g of the target of 50 g, i.e. from 47 g to 53 g inclusive. Draw up the test-plan rows for the check.

각 행은 값이 선택된 이유와 발생해야 할 것을 명시해야 합니다. 단순한 숫자 나열만으로는 점수를 얻을 수 없습니다.

프로그램의 수명 기간 비용 대부분은 유지보수에 소모됩니다. 세 가지 유형이 있습니다:

• 완벽화 유지보수 — 성능이나 기능을 개선하는 것 (더 빠른 쿼리, 새로운 옵션 등). 작동 중이라 하더라도 수행됩니다.
• 적응 유지보수 — 변화하는 환경에서도 작동하게 유지하는 것 (새로운 OS, 새로운 API, 법적 변경 등).
• 수정 유지보수 — 사용 중 발견된 버그를 수정하는 것.

프로그램은 수명 기간 내내 세 가지 유형 모두를 필요로 할 수 있습니다.

각 유형이 필요한 이유 — 채점 기준에 제시된 이유. 수정: 출시 후 사용자가 결함을 보고하거나, 테스트가 커버하지 못한 특정 상황에서 잘못된 출력이 관찰됨. 적응: 운영체제, 하드웨어 또는 브라우저가 업그레이드됨; 법률이나 회사 규칙이 변경됨 (세율, 개인정보 보호 요구사항 등); 프로그램이 새로운 외부 시스템이나 파일 형식과 호환되어야 함. 완벽화: 사용자가 추가 기능이나 더 나은 인터페이스를 요청함; 프로그램이 더 빠르거나 메모리 사용량이 적게 되도록 개선됨; 코드가 정리되어 향후 변경이 용이하게 됨.

Worked example. (a) A released program outputs a wrong value under certain circumstances. (b) The hardware that runs a program is replaced. (c) Customers ask for the coffee-shop loyalty program to send a message on a customer's birthday. Name the maintenance type in each case.

(a) 수정 — 납품된 프로그램의 결함이 수정되고 있음. (b) 적응 — 프로그램이 새로운 환경에서 실행되도록 변경됨. (c) 완벽화 — 이미 작동하는 프로그램에 기능이 추가됨.

기능 추가 또는 버그 수정을 요청받을 때:

1. 기존 코드를 읽으십시오. 알고리즘과 데이터 흐름을 이해할 때까지.
2. 변경이 이루어질 위치를 찾으십시오. 어느 서브루틴, 어느 줄인지.
3. 변경을 최소화하라 — 작동 중인 코드를 다시 작성하지 마라.
4. 관련 부분을 업데이트하라 — 변경된 매개 변수 목록을 호출하는 모든 곳, 변경된 데이터 구조를 사용하는 모든 Routine.
5. **새로운 행동과 기존(regression testing) 행동 모두를 테스트하라. (변경으로 인해 무언가를 고장 나게 하지 않았는지 확인.)
6. 변경 사항을 문서화하라.

명확한 주석, 의미 있는 이름, 분할된 서브루틴 및 구조도(structure chart)는 프로그램 수정을 훨씬 쉽게 만듭니다. 이것이 첫 버전 출시 후에도 설계 도구들이 중요한 이유입니다.

본인이 작성하지 않은 프로그램 분석하기. 식별자 표(identifier table)와 모듈 헤더에서 시작하십시오: 이는 본문의 줄을 읽기 전에 각 모듈이 무엇을 받아서 무엇을 반환하는지 알려줍니다. 그 다음 작은 입력 하나에 대해 추적 표(trace table)로 알고리즘을 추적하여 각 출력 값의 출처를 기록하십시오. 그런 다음 개선 지점을 결정하십시오—통상적으로 기존 모듈에서 호출되는 새로운 모듈이므로, 작동 중인 코드가 가장 적게 방해받도록 하는 것— 그리고 변경 사항에 대한 가상의 코드(pseudocode)와 이를 입증할 테스트 데이터를 작성하십시오.

정의 문제는 고정된 문구로 채점합니다. 이 내용들을 정확히 외우고, 답은 하나만 제시하십시오.

• 개발 모델(폭포, 반복, RAD)을 원리, 장점, 단점으로 비교하고, 프로그램 개발 수명 주기의 5단계를 알며 각 단계에서 산출물을 이해해야 함.
• 각 오류가 언제 나타나는지에 따라 구문, 논리, 실행 중 오류를 구분해야 함: 번역 시, 출력 시, 실행 중.
• 모든 종류의 테스트 데이터(정상, 비정상, 극한, 경계)를 선택하고, 각 값에 대해 이유와 예상 결과를 제시해야 함.
• 변경 사유에 따라 유지보수의 유형(정정, 적응, 완화)을 구분해야 함.
• 구조도(structure chart)에서 모든 기호를 명시하십시오: 박스, 호출선, 데이터 커플, 제어 커플, 선택 다이아몬드, 반복 화살표. 차트에서 모듈 헤더를 읽을 때, 한 기능에는 RETURNS이 존재함을 기억하십시오.

흔한 실수

• 수명 주기 단계를 이름만 기술하는 것("디자인 단계에서 프로그램을 디자인한다")은 부족합니다. 산출물(구조도, 가상의 코드, 테스트 계획 등)을 명시해야 함.
• 잘못된 출력을 "실행 중 오류"라고 부르는 것은 틀림. 프로그램이 끝까지 실행되었다면 논리 오류임.
• 경계 데이터를 극단값만으로 제시하는 것은 틀림. 점수는 모서리의 양쪽의 값이 필요함.
• 알파 테스트와 베타 테스트를 동일시하는 것은 틀림. 알파는 개발사 내부에서, 베타는 외부 실제 사용자에 의해 수행됨.
• 적응 유지보수와 완화 유지보수를 혼동하는 것은 틀림. 적응은 프로그램 외부의 변화에 대응하고, 완화는 아무도 변경할 필요가 없었던 프로그램을 개선함.
• 모듈을 임의의 순서로 배치하여 구조도를 그리는 것은 틀림. Calls order에 따라 왼쪽에서 오른쪽으로 읽어야 하며, 모든 매개 변수에는 화살표가 필요함.