소프트웨어 개발의 주요 단계를 다시 정리해보면 다음의 5단계를 거쳐서 소프트웨어를 개발한다. 1. specification2. design3. implementation4. test5. maintenance specification 단계에서는 사용자의 요구사항을 파악하고, use case diagram 을 통해 시스템의 기능을 시각화하였다.또한 사용자의 액션에 따라서 시스템이 어떻게 응답해야 하는지 use case description 을 작성하여 시스템에서 개발해야 하는 부분이 어디인지도 명확하게 정의할 수 있었다. 이번 글에서는 design 단계를 진행한다.design 단계에서는 앞서 파악한 내용을 분석하여 실제로 프로그램을 개발할 때 어떤 클래스와 메서드를 사용할 지 정의한다.이 과정을 마치고나면 ..
Configuration Management (CM)CM은 소프트웨어 시스템의 변화를 관리하는 도구, 프로세스, 정책과 관련된 개념이다.특히 팀 프로젝트를 하다보면 각 개발자들이 서로 다른 변화를 만들어내기 때문에 이 변화들을 관리하기 위해 필수적이다. 소프트웨어 컴포넌트의 확정된 변경사항은 버전별로 repository 라는 공동 저장소에 저장되어 있고, 개발자들은 repository 에 있는 코드를 자신의 workspace 로 가져와서 개발한다. CM 에서 수행하는 활동은 크게 4가지가 있다. 1. version management시스템 컴포넌트를 버전 별로 추적 관리하는 것 2. system building컴포넌트, 데이터, 라이브러리를 모아서 하나의 실행가능한 프로그램으로 만드는 것 3. chan..
Use Case Diagramuse case diagram 을 그리는 목적은 크게 2가지가 있다. 1. 시스템의 functionality (functional requirement) 를 '사용자의 관점'에서 문서화하는 것2. 사용자와 시스템 사이의 상호작용을 use case description을 사용해 문서화하는 것 이때 use case description 을 작성하면, 시스템 관점에서 어떤 기능을 개발해야 하는지 명료하게 정리된다.그러면 이 내용을 기반으로 시스템을 설계하고 구현하면 끝이다. use case diagram은 철저하게 '사용자의 관점' 에서 작성해야 한다.사용자가 로그인 화면에서 아이디와 비밀번호를 입력하고 로그인 버튼을 클릭했을 때, 시스템이 사용자 정보를 DB에서 조회하고.. 하는..
요구사항 분석 과정이번 글에서는 Software Activity 글에서 정리했던 요구사항 파악 단계를 구체적으로 정리해본다.먼저 요구사항을 파악할 때는 다음 3가지 단계를 거쳐야 한다. 1. 기존 시스템을 파악한다.2. 기존 시스템에서 문제점을 파악한다.3. 현재 시스템에 없는 새로운 요구사항이 있는지 파악한다. 요구사항을 파악할 때, 기존 시스템을 이해하는 것이 필요한 이유는 다음과 같다. - 기존 시스템에 존재하는 기능이 새로운 시스템에서도 계속 필요할 수 있다.- 기존 시스템에 존재하는 데이터를 새로운 시스템에 그대로 옮겨야 한다.- 기존 시스템의 기술 문서는 기존 시스템의 알고리즘 흐름을 자세히 파악하는데 도움이 된다.- 기존 시스템의 결함을 파악해서 새로운 시스템에는 같은 결함이 없도록 해야 한..
지금까지 소프트웨어 공학의 중요성 및 주요 개발 프로세스 모델들의 특징과 객체 지향 개념에 대해서 정리하였다.이번 글부터는 '요구사항 분석 - 설계 - 구현 - 검증 - 유지보수' 단계에서 요구사항 분석, 설계, 검증에 대한 내용을 자세히 정리한다. 먼저 요구사항 분석에 앞서 요구사항을 분석한 내용을 기반으로 다이어그램을 그릴 필요가 있기 때문에, '모델' 과 '다이어그램' 에 대해서 간단히 정리해보려고 한다. 모델모델은 현실 또는 상상의 무언가를 표현하는 것을 말한다.이때 모델이 유용하려면 아래로 내려갈수록 디테일하게 적절히 계층적 구조로 묘사되어야 하고, 현재 task에서 중요한 부분을 잘 나타내어야 한다.지금은 소프트웨어 공학을 보고 있으므로 소프트웨어 시스템을 모델로 표현하게 되는데, 대부분의 소..
Polymorphism 한국어로는 '다형성' 이라고 번역되나 abstraction 과 마찬가지로 영어 단어로 봐야 그 의미가 제대로 이해된다.polymorphism 은 poly + morph + ism 의 합성어로, poly 는 '다수의' 라는 의미를 갖고 있고, morph 는 '모양' 을 가리킨다.그래서 한국어로도 다형성이라고 번역을 한 것인데, 사실 코드에서 '모양' 이라고 하면 잘 와닿지 않는다. 소스코드에서 '모양, 형태' 라는 말을 더 와닿게 번역하면 '구현' 이 된다.즉, polymorphism은 구현이 다양하게 있다는 뜻이다.이 말은 다음과 같이 표현할 수 있다. one interface, multiple implementation 말 그대로 하나의 인터페이스에 여러가지 구현이 존재할 수 있..
이번 글부터는 객체지향의 주요 개념을 소프트웨어 개발 방법의 관점에서 살펴보려고 한다. 먼저 객체지향이 등장한 배경은 SW의 모듈화를 위해서였다.모듈은 소프트웨어를 설계할 때 '독립적인 기능을 수행하는 개발단위'를 말한다.기능이 독립적이라는 뜻은 이 기능이 다른 모듈의 변화에 영향을 주지도, 받지도 않는다는 것을 말한다. HW에서의 모듈화를 생각해보자.컴퓨터를 조립할 때, CPU, RAM, SSD, 그래픽카드, 네트워크카드, 파워, 팬, 마더보드 등의 부품이 필요하다.그런데 이 각각의 부품들은 모두 서로 다른 제조사에서 만든다.하지만 이 부품들을 잘 모아서 조립하면 하나의 온전한 컴퓨터로서 기능한다.다른 부품을 그대로 두고 RAM 만 바꾸거나, 그래픽카드만 바꾸거나 해도 다른 하드웨어의 동작에는 전혀 영..
AgileSoftware Process글에서 Agile을 Plan-Driven 방식과 비교하며 사용자의 요구사항 변경에 민첩하게 반응하는 개발 방법론이라고 정리했었다.이번 글에서는 이 애자일 방법론에 대해 더 자세히 정리해본다. 애자일 개발 방법론이 등장한 배경은 기존 개발 방법론에서 발생하는 오버헤드에 대한 부담이었다.예를 들어 waterfall 방식은 각 단계가 끝날 때마다 document가 나오는 것이 장점이었지만, 고객의 요구사항이 빠르게 바뀌는 상황에서 매번 바뀌는 요구사항에 맞춰 문서화를 하고나서 개발하는 것은 오버헤드가 존재한다. 그래서 애자일은 요구사항이 변화할 때 부가적인 작업 없이 빠르게 대응해서 software delivery time을 줄이는 것을 목표로 한다. 과거의 plan-ba..
RUP(Rational Unified Process) (⭐️⭐️⭐️)RUP는 Rational 라는 회사에서 만든 소프트웨어 개발 프로세스를 말한다.보통 3번째 글에서 정리한 소프트웨어 모델들을 조합하여 소프트웨어를 개발하는데, 각자 자신들만의 개발 방법론을 쓴다고 해도 그 3가지를 조합해서 사용하는 것은 비슷하기 때문에 RUP 만 살펴봐도 다른 개발 방법론을 이해하는데는 충분하다. RUP에서는 크게 3가지 perspective를 가지고 process 를 설명한다. dynamic perspectivedynamic perspective 에서는 RUP 의 소프트웨어 개발 단계(Phase)를 크게 4개로 나눈다.각 단계는 그 안에서 반복될 수 있으며, 전체 프로세스도 계속해서 반복되는 것을 나타낸다. 각각의 P..
모든 소프트웨어 개발 방법론에는 공통적으로 Specification - Design and Implementation - Testing - Maintenance 의 5단계가 들어간다.Waterfall은 각 단계가 1번씩만 등장하며 하나의 단계가 끝나야만 다음 단계로 넘어갈 수 있었고, Incremental Development 는 이 단게가 반복되었다.이제 각각의 자세한 단계를 정리해보자. Software Specification흔히 '스펙' 이라고 부르는 specification 은 이름 그대로 소프트웨어 개발에 있어 필요한 사항을 명시하는 과정이다.이때 스펙에 명시하는 사항에는 크게 소프트웨어에서 필요로 하는 기능과 시스템 기능과 개발 단계에서 나타나는 제약 조건이 있다.제약 조건에는 소프트웨어가 동..
