소프트웨어 개발

 

1. 개요
2. 소프트웨어 개발 프로세스
2.1. 요구사항 개발(Requirements Development)
2.2. 설계(Design)
2.3. 시험(Testing)
2.4. 유지보수(Maintenance)
3. 정보 시스템의 구축
4. 관련 도구(CASE Tool)
4.1. 모델링 관련
5. 참고


1. 개요

소프트웨어의 개발(Development)은 요구사항 개발(Requirements Development), 설계(Design), 구현(Implementation), 시험(Testing), 유지보수(Maintenance) 등의 일련의 과정을 말한다. 개발(Development)과 구현(Implementation)을 혼동하여 소프트웨어 개발이 구현(Implementation) 에 국한되는 것으로 오해하는 경우가 있는데, 요구사항추출, 설계, 구현, 시험, 유지보수 등의 과정을 거쳐 하나의 소프트웨어 솔루션이 개발되는 것이다.
대기업에서 가장 널리 보편적으로 사용되는 방식은 애자일(Agile) 방법론이라 불리는 방식으로 IBM, Intel을 비롯한 세계적인 기업들이 소프트웨어 솔루션의 개발에 주로 사용하고 있다. 애자일 프로세스는 국내에서 리니지2개발에 활용된 바 있으며[1], 소프트웨어 제품의 품질확보를 위한 소프트웨어공학(Software Engineering)의 공학적 원리를 모두 적용하는 것보다는 단순화할 수 있기 때문에 널리 활용되고 있다.[2]
현대의 소프트웨어는 은행권[3]이나 군사[4]와 같은 특수목적을 제외하면 대부분 객체지향(Object Oriented) 방법론에 의하여 개발되고 있다. 물론 다른 개발방법론을 적용해도 소프트웨어 개발은 요구사항 개발, 설계, 구현, 시험, 유지보수에서 크게 벗어나지 않으며, 각 단계를 전개하는 유형에 따라 Waterfall Model, Spiral Model, Iterative and incremental development, Code and Fix 등으로 구분할 수 있다. 한편 산업공학에는 Service Engagement Process, Linear Developemnt Process, Iterative Customer Development Process 등이 있다.
전산직 공무원 (전산 개발) 시험에서는 9급의 경우 컴퓨터일반 과목에서, 7급의 경우 '''소프트웨어 공학''' 과목에서 다뤄지는 내용이다.

2. 소프트웨어 개발 프로세스


2.1. 요구사항 개발(Requirements Development)

시스템/소프트웨어의 개발에는 수 많은 사람들이 관여하게 되는데, 이 모두를 이해당사자(Stakeholders)라고 지칭하며, 소프트웨어의 개발에 자금을 지원하는 사람, 프로젝트 관리자, 설계자, 개발자, 최종이용자(End-user) 등이 포함된다. 소프트웨어 솔루션의 개발이라는 목표에 이해당사자간 이해충돌은 매우 빈번하며[5], 이에 따라 요구사항의 수는 매우 많을 수 밖에 없으며 변경도 빈번하게 발생할 수 밖에 없다. 따라서 상호간 타협가능한 요구사항의 개발이 매우 중요하다. 자본, 개발기간과 투입가능인력에 한계가 있는데 완벽한 소프트웨어를 개발할 수는 없기 때문.[6] 즉, 타협을 통해 '''첫 단추를 잘 끼워야'''한다.
특히 소프트웨어의 요구사항은 기능요구사항(Functional Requirements)와 비기능요구사항(Non-functional Requirements)로 구분되며, 이는 소프트웨어요구명세서(SRS)에 문서화하는 것이 중요하다[7]. 시스템/소프트웨어의 요구사항만을 집중적으로 연구하는 학문으로 요구공학(Requirements Engineering)이 대두될 정도로 요구사항의 개발은 매우 중요하다.
오늘날은 대부분의 소프트웨어 개발에 객체지향방법론이 활용되기 때문에 UML(Unified Modeling Language)의 유스케이스모델로 기능요구사항을 표현할 수 있다.

2.2. 설계(Design)


2.3. 시험(Testing)


2.4. 유지보수(Maintenance)


3. 정보 시스템의 구축

본 항목은 전산학적인 관점 보다는 산업공학쪽 측면에서 보는 경향이 강하다. 전산학적 측면에서는 실제로 개발되는 내용은 상대적으로 적기도 하며 전체적인 과정에서 실제 코딩이 필요한 부분은 매우 작다.
정보 시스템 역시 큰 의미에서는 소프트웨어로 볼 수 있으며 이 시스템을 구축하는 과정 역시 이미 산업공학쪽에서 많은 연구가 되어있다. 위에 기술한대로 Agile Process가 현재까지 연구된 개발 과정 중에서는 우수하다고 알려져있으나 해당 과정이 쉽게 적용하기 힘들다는 문제로 인하여 갓 시작한 밴처기업은 주로 Linear Product Development를 따르며 중견기업은 Iterative Customer Development 를 따르는 경우가 많다. Agile Process는 이름이 말해주듯 민첩하게 반응하여 변화를 추구하는 방식이다. 기존의 개발 과정이 하나 하나의 Requirement를 가지고 Analysis, Design, Coding, Test, Production과정을 해 왔다면 Agile Process는 이 방식을 90도 뒤집은 방식으로 Analysis, Design, Code, Test, Production이 동시에 Concurrent한 형태로 이루어진다. 그리고 각 Deadline마다 프로토타입을 보고 새로운 requirement나 문제에 대해서 해결하는 방식을 취한다. 사실 좋은 시스템의 개발의 난점은 코딩이 결코 아니다. 순수하게 Working Prototype을 만드는 것은 상대적으로 매우 쉬운 일로 심지어 비교적 단순한 기능을 가졌다면 1달안에 괜찮은 형태를 가진 프로토타입 제작이 가능하다. 이에 착안하여 최대한 빨리 '실제로 어느정도 구현 된' 모습을 클라이언트나 사용자들에게 보여주어 작동하는 시스템에서 필요한 requirement를 새로 받을 수 있다는것이 큰 장점으로 위에 웹 어플리케이션 개발에서 Spiral Model이 했던것처럼 잦은 프로토타입 제작으로 필요한 부분을 빠르게 매꿀 수 있다는점이 큰 강점으로 지적된다.
이 방식이 힘든 이유는 이 방식에 대한 이해가 부족하기때문으로 알려져있는데 많은 사람들이 Code and Fix와 혼동을 하는 경우가 많다. 절대 Code and Fix와는 다른 차원의 이론이다. Agile Process는 Code and Fix와는 다르게 결코 미완성품을 용납하거나 Developer혼자 모든것을 총괄하는 방식이 아니라 잦은 프로토타입 공개를 통한 Feedback을 얻어서 새로운 requirement를 늘려나가자는 방식으로 일단 해보자라는 마인드가 아닌 High level Architecture Modeling과 High level Requirement Modeling이 초기에 필요하다.
Agile Process의 과정은 크게 4단계로 나뉘는데 이를 각각 Inception, Elaboration, Construction 그리고 Transition이라고 부른다. 위에 서술한것 처럼 시작점인 Inception단계에서는 High-level 구조모델과 요구사항모델이 나와야한다. 이를 기반으로 하지 않은 상태로 순수하게 기술적 개념증명용 프로토타입이 만들어진다. 따라서 Inception단계에서는 기술적 가능성만 증명되고 테스트 역시 이에 맞춰져서 얼마나 이 기술이 실용적이며 효율적인지, 그리고 유용한지를 판단한다.
그 다음 단계인 Elaboration에서는 모델링은 기술적인 리스크와 구조적 모델, 그리고 UI의 기초가 나와야된다. 그리고 이 부분에서 구현은 Inception단계에서 나온 High-level architecture가 적용 가능한지에 대한 구현을 시도하며 실험 역시 구조증명에 집중된다. 이런 식으로 동시에 디자인-개발-테스트가 진행되면서 상호보안을 통한 개발 과정이 Agile Unified Process라는 명칭으로 불린다.

4. 관련 도구(CASE Tool)


4.1. 모델링 관련

  • UML(Unified Modeling Language)
  • UP(Unified Process)

4.2. 통합 개발 환경(IDE)

통합 개발 환경이라고 하면 수많은 종류가 있으나 일단은 프로그램 개발의 핵심인 코딩을 하는데 있어 일반적으로 사용하는 툴을 정리한다.

4.3. 텍스트 에디터

항목 참고.

4.4. DBMS

  • MySQL
  • Oracle DB
  • MS-SQL: MS사의 유명한 관계형 데이터베이스이다. 상용이긴 하나 비 상용처럼(?) 쓰이는 사례가 자주 목격된다.
  • PostgreSQL
  • MongoDB: 기존 관계형 데이터베이스와는 다른 key-value방식의 문서기반 데이터베이스 라고 한다. JSON과 비슷한 BSON의 형태의 문서를 생성한다. 또한 최근 뜨고 있는 빅데이터에서 자주 사용되는 NoSQL 계열의 DB 시스템이기도 하다. 트위터와 페이스북 등 SNS에서도 많이 쓰이는 중.

4.5. 버전 관리 시스템


5. 참고


[1] 출시예정일로부터 초시계를 카운트다운하도록 했으니 애자일 방법론에 의한 개발을 유도하긴 했다(...) [2] 개요의 서두에서 말한 각 단계들에는 수 많은 활동(Activities)와 작업(Task)가 있으며, 이에 대한 산출물로 문서화가 필히 요구된다. 수 많은 문서화 작업은 변경을 추적하고 관리하는데 매우 중요하지만, 현대의 소프트웨어 개발에서는 급변하는 시장대응이나 고객의 요구사항 변경에 효과적으로 대응하기 위하여 애자일이 널리 사용되고 있는 것.[3] 코볼(...)[4] Ada(에이다)가 미국방부에서 개발한 대표적인 군용 소프트웨어개발 언어이다.[5] 적은 자금으로 빠르게 개발하기를 원하지만, 프로젝트 관리자는 골머리가 터진다든지(...)[6] 애초에 완벽한 소프트웨어란 없다(...)[7] 관련국제표준으로 IEEE-STD-830(통상적으로 IEEE830)이 있으며, 요구사항명세화를 위한 지침을 제공한다.

분류