[SE] SDLC (Software Development Life Cycle)

** 아래 글은 개인의 조사를 바탕으로 주관적으로 작성되었습니다. 잘못된 부분은 댓글로 남겨주시면 수정하겠습니다.

 

소프트웨어 생명 주기 (Software Development Life Cycle, SDLC)

 소프트웨어의 계획부터 배포에 이르기까지 시간적인 경과를 의미하며, 명확하게 나눠진 여러 단계를 통해 시스템의 품질을 올려 고객의 만족도를 높이는 것이 목적이다. 이런 목적의 달성을 위해 구조적, 정보공학적, 객체지향, CBD(Component-Based Development), Agile, DevOps 와 같은 방법론들과 여러 모델들이 발생하게 되었다.

 

아래 이미지는 SDLC의 각 과정을 나타낸 그림이다.

 

---

 

구조적 방법론

1970년 발생한 기능 중심의 전통적인 방법론이다. 자세한 내용은 아래에 정리해보았다.

 

절차

요구사항 분석 - 구조적 분석 - 구조적 설계 - 구조적 프로그래밍

• 요구사항 분석 : 데이터 분석, 시스템 환경 분석, 사용자 요구기능
• 구조적 분석 : DFD 작성, DD 작성, Minispec 작성, DB 분석 (1/2)
• 구조적 설계 : DB 분석 (2/2), DB 설계, 어플리케이션 설계
• 구조적 프로그래밍 : 3개 논리적 구조로 프로그래밍

 ** DFD : 데이터 흐름도, 기능별로 분할하여 표현한 구조도

 ** DD : 자료 사전, 자료의 의미나 단위, 값 등에 대한 사항을 정의

 ** STD : 상태 전이도, 상태가 변경되는 과정과 프로세스를 명시하는 것

 ** NS 차트 : 알고리즘은 순차, 선택, 반복 구조면 설명이 가능하다.

 

등장 배경

 GOTO 문을 쓰지 말자라는 주장이 호응을 얻으면서 분석과 설계를 구조적으로 하자. 라는 의견으로 확대됨

 

특징

 데이터 흐름 지향 (DFD/ ERD), 모듈의 분할과 정복에 의한 하향식(Topdown) 설계방식 - 소수의 전문가, 모듈의 구조화를 통한 재사용/ 유지보수성 제고, SDLC 구조를 가진 폭포수 모델이 기본. 단일입구/ 단일 출구의 처리구조를 가짐. 

정형화, 체계화, 모듈화의 장점이 있다.

 

단점 

 어플리케이션은 여전히 기능적 설계, 기능의 유지보수와 재사용성은 낮음, 프로젝트의 관리 및 조직, 역할 등 방법론적 다른 요소들의 정의가 없음., 단순한 소프트웨어의 개발만 목표로 하여 단위 프로젝트에서만 사용, 데이터의 정보 은닉이 안됨.

 

모델

 폭포수(Water Fall), v-model

 

참고 링크

https://ko.wikipedia.org/wiki/V_%EB%AA%A8%EB%8D%B8

V 모델 - 위키백과, 우리 모두의 백과사전

---

 

정보공학적 방법론

1980년대 발생한 자료 중심의 방법론으로 대규모 정보 시스템을 구축하는데 적합하다.

기업 정보 시스템에 공학적 기법을 적용하여 시스템의 계획, 분석, 설계 및 구축을 하는 데이터 중심의 방법론이다.

자세한 내용은 아래를 보자.

 

절차 

 정보 전략 계획 수립 단계 - 업무 영역 분석 단계 - 업무 시스템 설계 단계 - 업무 시스템 구축 단계

 

등장 배경

 정보 시스템은 소프트웨어의 개발과는 달리 하드웨어, 네트워크 등 여러 소프트웨어와 복잡하게 연결되는 대규모 시스템이기 때문에 이러한 시스템을 개발하기 위해서는 장기간, 많은 인력이 소모됨. 그러므로 철저한 계획과 팀워크를 기반으로한 프로젝트의 관리와 이를 위한 잘 짜여진 방법론이 필요하게 됨

 

특징

• 일반전인 소프트웨어 개발이 아닌 기업의 Biz 전략에 따라 수립된 ISP에 따라 정보시스템 통합에 그 초점이 맞추어짐.
• 따라서, ISP 수립 - 업무영역 분석 - 업무시스템 설계 - 업무시스템 구축 의 순서를 가진다.
• Process는 변하지만 Data는 불변이기 때문에 프로그램 로직은 데이터 구조에 종속적이며(CRUD를 따르며) 데이터 안정성을 추구하기 위한 데이터 구조에 중점을 둔다.
• 기본적으로 정보공학은 공학적 개발 방법론이며 자동화 도욱, CASE 툴을 이용하여 코드의 자동 생성을 목표로 한다.

단점

 어플리케이션은 여전히 기능적 설계, 기능의 유지보수, 재사용성 낮음

 

---

 

객체지향 방법론

 1990년대 발생한 객체 중심의 방법론으로 현실 세계의 개체(Entity)를 하나의 객체(Object)로 만들어, 기계를 조립하듯 객체의 조립을 통해 필요한 소프트웨어를 구현하는 방법론이다. 복잡한 현실 세계를 모델링하며 객체, 클래스, 메시지 등으로 구성되어 있다.

 

절차

개발 준비 - 분석 - 설계 - 구현 - 테스트 - 전개 - 인도

 

등장 배경

 구조적 방법론이나 정보공학 방법론 모두 프로세스와 데이터를 분리하여 처리한다는 단점은 이를 통합하여 처리하는  객체 지향의 등장에 가장 큰 배경이 되었다.

 

특징

재사용성이 뛰어나고 유지보수 비용이 적어 생산성 및 품질을 향상 시킬 수 있다.

추상화, 캡슐화, 상속, 정보은닉 등 객체를 중심으로 프로그래밍 구조를 단순화함

구조적, 정보공학적 방법론은 프로세스와 데이터 분리했지만 객체지향 방법론은 프로세스와 데이터의 통합함 (클래스)

분석과 설계간 차이가 없음.

 

단점

• 전문가 부족 (?)
• 기본 SW 기술 필요
• 상속이 많으면 성능이 저하되는 단점 
• 다형성이 많으면 유지보수가 어려워진다.

 

추상화

• 개념 : 현실세계의 사실은 그대로 객체로 표현하기 보다는 문제의 중요한 측면을 주목하여 상세 내역을 없애 나가는 과정
• 역할 : 복잡한 프로그램을 간단하게 해주고 분석의 초점을 명확히 함
• 특징 : 클래스를 이용함으로써 데이터와 프로세스를 함께 추상화 구조에 넣어, 더 완벽한 추상화를 실현함

 

캡슐화 (정보은닉) 

• 개념 : 객체의 상세한 내용을 객체 외부에 숨기고 단순히 메시지 만으로 객체와의 상호작용을 하게 하는 것.
• 역할 : 객체의 내부 구조와 실체를 분리하여 내부의 변경이 프로그램에 미치는 영향을 최소화하여, 유지보수성을 올림
• 특징 : Public과 Private

 

상속성

• 개념 : 슈퍼 클래스가 갖는 성질을 서브 클래스에 자동으로 부여하는 것.
• 역할 : 프로그램을 쉽게 확장할 수 있도록 해주는 강력한 수단

 

다형성

• 개념 : 하나의 인터페이스를 이용하여 서로다른 구현 방법을 제공하는 것
• 역할 : 특정지식을 최소화한 관련된 클래스들을 위한 일관된 매개체를 개발하는 수단을 제공

 

---

 

CBD 방법론

2000년대 발생한 컴포넌트 중심의 방법론이다.

 

** 컴포넌트 : Context와 Interface

** 컨테이너 : 컨포넌트를 구현하기 위한 서비스 런타임 환경

 

절차

 도메인 분석 - 도메인 설계 - 컴포넌트 추출 - 컴포넌트 설계 - 컴포넌트 구현

 

특징

• Black Box 재사용 : 인터 페이스를 이요하여 재사용
• 추상화, 캡슐화 : Input과 Output만 있음
• 표준화된 UML을 통한 모델링 및 산출물 작성
• 반복 점진적 개발 프로세스 제공
• 표준화된 산출물 작성 및 컴포넌트 제작 기법을 통한 재사용 성 향상.

 

품질 측정 지료

 기능에 대한 이해가 편함, 변경이 편함, 컴포넌트간의 결합도(응집도는 이미 컴포넌트를 만들때 고려됨)

 

---

 

Agile 방법론

 2001년 발생한 방법론으로 고객의 요구사항 변화에 유연하게 대응할 수 있도록 일정한 주기를 반복하면서 개발 과정을 진행하는 방법론이다. 소규모 프로젝트, 고도로 숙달된 개발자, 급변하는 요구사항에 적합하다.

애자일 방법론의 대표적인 종류로는 XP (익스트림 프로그래밍), 스크럼과 칸반 보드, 크리스탈 등이 있다.

** TDD는 XP의 하위 항목이다.

 

등장 배경

기존 개발 방법론의 한계와 SW 개발 환경의 변화로 인한 새로운 방법론이 필요

 

절차

사용자 스토리 - (계획 -> 개발 -> 승인 테스트)의 과정을 반복

 

---

 

DevOps

2009년 발생한 방법론이다. Agile의 한계를 극복하기 위해 나왔으며, 방법론을 실현하기 위한 다양한 도구들이 발생되어 기존의 방법론들 보다 좀 더 명확하고 직관적으로 변했다고 생각한다.

다양한 파이프 라인들을 통해 부서나 팀원 간의 문제 발생 요소를 최소화하면서 결과물의 품질과 개발 효율을 높인다.

 

좀 더 많은 정보는 아래 글을 참고하면 좋을 것 같다.

https://hwan001.co.kr/200?category=1081020 

[SE] DevOps