'컴퓨터공학/소프트웨어공학'에 해당되는 글 4건
- 2011/10/01 소프트웨어공학의 3R(Reverse-Engineering, Re-Engineering, Re-Use)에 대하여
- 2010/06/28 Agile 이야기
- 2010/06/25 ITSM(IT Service Managment)에 대하여
- 2009/05/13 소프트웨어 개발 생명주기(SDLC)에 대하여 (2)
프로젝트 수행을 하다보면 많은 Know-How가 쌓이게 됩니다.
그래서인지 가끔 이런 이야기를 듣기도 합니다.
이 부분은 지난번에 만든 것과 비슷하잖아. 그대로 가져다가 사용하면 금방 하겠네!소프트웨어공학적으로는 분명히 맞는 이야기이지만 현실적으로는 쉽지 않은 것이 사실입니다.
바로 소프트웨어의 재사용성(Re-Use)에 대한 고려 없이 프로젝트를 진행하기 때문인데요.
프로젝트 수행 기간의 단축에 따른 충분한 설계 없이 개발에 들어가는 현실 때문인 것 같기도 합니다.
소프트웨어 3R의 정의
- 완성된 소프트웨어 프로그램을 기반으로 역공학(Reverse-Engineering), 재공학(Re-Engineering), 재사용(Re-Use)를 통해 소프트웨어의 생산성을 극대화 하는 기법
소프트웨어 3R의 필요성
- 소프트웨어 유지보수 효율성 향상 및 비용 절감
- 소프트웨어 개발 생산성 향상
- 소프트웨어 이해, 변경, 테스트 용이
- 소프트웨어 변경 요구사항에 대한 신속한 대응
- 소프트웨어 위기 (소프트웨어 개발 대형화, 복잡화, Life-Cycle 감소) 극복
소프트웨어 3R의 개념도
소프트웨어 3R 구성
1) 역공학 (Reverse-Engineering)
- 기존 개발된 시스템을 CASE를 이용하여 사양서, 설계서 등의 문서로 추출하는 작업
- 개발 단계를 역으로 올라가 기존 개발된 시스템의 코드나 데이터로부터 설계 명세서나 요구 분석서 등을 도출하는 작업
2) 재공학 (Re-Engineering)
- 기존 시스템을 널리 사용되는 프로그래밍 표준에 맞추거나 고수준의 언어로 재구성하거나 타 하드웨어에서 사용할 수 있도록 변환하는 작업
3) 재사용 (Re-Use)
- 이미 개발되어 기능, 성능, 품질을 인정받았던 소프트웨어의 전체 또는 일부분을 다시 사용
- 다른 시스템에 이용되고 있는 소프트웨어를 파악하고 재구성하여 새로운 시스템에 적용하기 위한 작업
소프트웨어 3R의 활성화 방안
1) 재사용에 대한 비전 공유
- 경영자, 관리자, 개발자 간의 공통된 이해 필요
- 재사용의 필요성 및 장점에 대한 비전 제시
- 재사용 가능한 모듈을 회사의 자산으로 인식할 수 있도록 노력
2) 재사용 Infrastructure 구성
- 재사용을 위한 공동 Repository, Matrix, 활용 시스템 구축
- 재사용 프로세스의 구축 및 활용 관리
- 체계적이고 지속적인 교육 실시 및 CBD, 객체지향방법론을 활용
역공학(Reverse Engineering)과 코드 난독화(Code Obfuscation)의 관계
역공학이라고 하면 우선 떠오르는 것이 다른 사람이 만든 프로그램에서 소스 코드를 생성해서 여기에 악성코드를 추가하는 것을 생각하기 쉬울 것 같습니다.
역공학의 이러한 문제점을 방지하기 위해 코드 난독화라는 기법이 있는데요.
역공학을 했을 때, 소스코드를 거의 해석하기 어려운 상태로 만드는 방법이 바로 코드 난독화(Code Obfuscation) 입니다.
여기에서 이야기하는 3R과는 차이가 있지만 실제 자바나 닷넷의 경우, 이런 코드 난독화 기법을 사용해서 프로그램을 변환합니다.
'컴퓨터공학 > 소프트웨어공학' 카테고리의 다른 글
| 소프트웨어공학의 3R(Reverse-Engineering, Re-Engineering, Re-Use)에 대하여 (0) | 2011/10/01 |
|---|---|
| Agile 이야기 (0) | 2010/06/28 |
| ITSM(IT Service Managment)에 대하여 (0) | 2010/06/25 |
| 소프트웨어 개발 생명주기(SDLC)에 대하여 (2) | 2009/05/13 |
Trackback 0 And
Comment 0
예전에 부분적으로 다룬 적은 있는데 오랜만에 Agile에 대해서 정리해 보려고 합니다.
방법론 하면 떠오르는 것이 매우 많습니다.
폭포수모델, 나선형모델, 점진적프로토타입, CBD 등 여러가지 개발방법론이 있었습니다.
각 모델의 장점과 단점이 있지만 요즘에는 개발 방법론 중 애자일이 가장 관심을 받고 있습니다.
그 이유는 빠르고 지속적으로 변화하는 S/W 개발 환경에 있다고 볼 수 있습니다.
사용자의 다양한 요구사항과 시스템을 필요로하는 순간에 배포해야 하는 환경에서는
기존의 문서 위주, 절차 위주의 방법론으로는 빠르게 대응할 수 없기 때문이죠.
Agile 방법론은 "절차보다는 사람이 중심이 되어 변화에 유연하고 신속하게 적응하면서 효율적으로 시스템을 개발할 수 있는 방법론"이라고 할 수 있습니다.
Aigle 방법론의 특징은 다음과 같이 이야기 할 수 있습니다.
- 프로세스보다 사람 중심
- 문서나 절차보다 개개인의 상호작용이 중요
- 고객의 적극적인 참여 필요
- Predictive 보다 Adaptive 함 (가변적 요구에 대응)
그렇다면, 기존의 개발 방법론과 Agile 방버론의 차이를 살펴보면 다음과 같습니다.
| 항목 | 기존 개발 방법론 | Agile 개발 방법론 |
| 계획수준 | 각 단계별 세부 계획 수립 | 반복적인 주기 설정 다음 주기에 대해서만 세부계획 수립 |
| 요구사항 | 초기 요구사항에 대한 기준 설정 요구사항 변경시 절차에 따른 형상관리 필요 |
요구사항의 변경, 추가가 용이 |
| 시스템 개발 | 분석 및 설계단계에서 구체적인 시스템 설계, 개발 | 실제 구현된 기능을 통해 실현가능성, 효과 확인 후 구현 |
| 테스트 | 단위, 통합, 시스템 테스트순으로 진행 | 작은 단위의 기능별 구현/테스트를 반복 |
| 표준 프로세스 | 개발 전 표준화된 프로세스 제정 모든 실행 계획에 따라 구현 |
반복적인 iteration 강조 프로세스는 유연하게 적용 |
프로세스나 방범론에서 현재 키워드로 자리잡고 있는 것은 6 Sigma, CMMI, Agile 입니다.
서로 다른 영역에서 프로젝트의 성공을 위해 활용되고 있는데요. 개발자는 Agile 방법론으로 개발을 진행하고, 조직은 CMMI라는 프레임워크로 관리하고, 경영은 6 Sigma를 활용하면 프로젝트의 실패를 초래하는 위험 요소를 최소화 할 수 있다는 것입니다.
다른 곳에서 발췌한 자료에서 이 세가지를 비유적으로 설명한 것이 있어 옮겨봅니다.
하늘에서 내리는 비를 프로젝트의 실패를 초래하는 위험요소라고 하였을 때, 6시그마와 CMMI, 그리고 Agile 프로세스는 실패를 막아주는 우산이 됩니다.
Agile프로세스는 우산의 살과 지주가되고, CMMI는 살을 하나로 모아 비를 막아줍니다. 가장 정점의 꼭지에는 6시그마가 존재합니다.
이들은 하나가 되어 우리가 비를 맞지 않고, 맞더라도 최대한 적은 양의 비를 맞도록 해줍니다.
6시그마와 CMMI, Agile프로세스는 만든이가 다릅니다. 6시그마는 산업공학, 다시 말해 경영학도에 가까운 사람들이 만들어 낸 방법론입니다. CMMI는 개발에 가까운 관리자들이 만들어낸 방법론이며, Agile은 개발자들이 만들어낸 방법론입니다. 이런 태생적 차이로 이들은 서로 다르지만 모이면 하나가 됩니다.
CMMI의 대 전제는 "조직 고유의 프로세스가 존재한다."입니다. 조직 고유의 프로세스를 CMMI라는 하나의 통합 프레임워크에 통합시키고 직관적으로 관리가능하게 하고, 최상의 프로세스로 개선시켜 줍니다. 대부분의 실패한 CMMI프로젝트는 CMMI를 통하여 조직에 프로세스를 만드려고 하기 때문입니다.
조직내의 고유한 프로세스는 Agile 개발 프로세스로 충분히 가능합니다. Agile 방법론으로 각 프로젝트 별로 구성된 프로세스는 CMMI에 의하여 조직자체가 통합적으로 관리하게 됩니다. 물론 TSP/PSP나 RUP등과 같은 기존의 다른 프로세스들도 마찬가지 입니다. (하지만, 현대사회는 Agility가 중요합니다.) Agile프로세스가 팀이나 프로젝트에서 개인적으로 사용하는 관행을 탈피해야 합니다.
마지막으로, 6시그마는 CMMI레벨 4 이상의 환경에서 정확히 동작합니다. 뒤집어 이야기 하면, CMMI레벨 2,3을 만족하는 조직에서 최적의 퍼포먼스를 낼 수 있습니다. 실제 CMMI레벨 4,5에는 프로세스 영역이 몇개 존재 하지 않습니다. 보잉의 존부씨의 말로는 CMMI개발자들이 레벨4/5환경을 잘 알수 없기 때문이라고 말하기도 하였습니다. 이 부분은 개발이나 관리의 영역이 아닌, 수치화와 유기적인 조직이 중시되는 경영의 영역이 됩니다. 6시그마는 이하 모든 프로세스를 기반으로 완전한 정형적 환경을 구축하게 해줄 것입니다.
'컴퓨터공학 > 소프트웨어공학' 카테고리의 다른 글
| 소프트웨어공학의 3R(Reverse-Engineering, Re-Engineering, Re-Use)에 대하여 (0) | 2011/10/01 |
|---|---|
| Agile 이야기 (0) | 2010/06/28 |
| ITSM(IT Service Managment)에 대하여 (0) | 2010/06/25 |
| 소프트웨어 개발 생명주기(SDLC)에 대하여 (2) | 2009/05/13 |
Trackback 0 And
Comment 0
ITSM 정의
ITSM은 시스템이나 어플리케이션 그리고 네트워크 보안등과 같이 특정 영역별로 이루어졌던 IT 관리 방식에서 벗어나 전체 프로세스를 표준화하고, 서비스 관점에서 보다 체계적으로 IT 인프라를 관리하자는데서 출발했습니다.
ITSMF의 CEO 에이든 로즈는 "ITSM은 수준 높은 품질의 IT 서비스를 개발하고 제공하는데 관계된 전체 라이프 사이클에 관련된 모든 활동을 포함하는 것"이라고 했습니다.
가트너 그룹에서는 "ITSM을 합리적이고 예상 가능한 IT 서비스를 제공하는데 필요한 프로세스, 조직 역량, 기술의 집합체라고 정의하고 주어진 비용을 통해 요구되는 성과를 창출하기 위한 IT 서비스의 비즈니스적 가치를 극대화하는 것이 목적"이라고 했습니다.
즉, ITSM은 합리적 비용 범위내에서 합의된 품질 수준의 서비스를 제공할 수 있도록 프로세스, 자원, 기술을 종합적으로 관리하기 위한 선진적인 IT 관리체계입니다.
ITSM 구성 프레임워크
이러한 ITSM을 위한 모델로 CMMi, MOF, ITIL, eSCM등이 있는데요.
각각의 구성을 살펴보면 다음 그림과 같습니다.
<그림 1> ITSM의 구성 프레잌워크
이중에서 업계 표준으로 인정받고 있는 ITIL에 대해서 살펴보려고 합니다.
ITIL (IT Infrastructure Library)
ITIL은 1989년 영국의 CCTA에 의해 만들어진 IT 서비스 운영 관련 사례들을 책으로 발간한 라이브러리 입니다.
IT 서비스를 관리하기 위한 일련의 Best Practice로서 ITIL에서 제시하는 SLA(Service Level Agreement) 프로세스는 사전준비, SLA 개발, 운영 및 개선 단계의 생명주기를 거치며 반복됩니다.
ITIL은 다음 그림과 같이 두 가지 영역으로 IT 서비스 관리 프로세싱을 구분하고 있습니다.
<그림 2> ITIL 구성도
- Service Delivery: IT 서비스의 품질향상과 비용절감에 목표를 두면서 SLA를 달성하는 동시에 SLA를 측정하기 위한 프로세스들로 구성됩니다.
- Service Support: IT 서비스 사용자가 비즈니스 관련 IT 서비스를 항상 받을 수 있도록 보장하는 데 필요한 관련 프로세스를 포함하고 있습니다.
- Application Management: S/W 개발 라이프 사이클을 포함하고 있으며 소프트웨어 라이프 사이클 지원 및 IT 서비스 테스팅까지 확장하여 다루고 있습니다.
- ICT Infrastructure Management: IT Infrastructure를 운영 관리하기 위해 필요한 주요 프로세스를 포함하고 있습니다.
ITSM의 특징 및 구성요소
ITSM은 타 프로세스 및 품질모델과 비교해 볼 때 보다 구체적인 모습을 제시하는 것이 특징입니다. 이것은 다음과 같은 3가지 요소가 명확하게 정의되어 있기 때문에 가능합니다.
- ITSM의 표준 참조모델인 ITIL이 구체적인 실체를 제공 (Best Practice를 제공)
- ITSM 적용은 IT 조직에 대한 명확한 역할과 정의를 요구 (ITSM 적용 목적은 IT 생산성 향상과 IT 품질 개선)
- ITSM은 사용화된 기술을 제공 (ROI 효과를 얻기 위해)
ITSM이 성공적으로 이루어지려면 프로세스, 조직, 제반 시스템의 구축 뿐만 아니라 기업의 문화에 단기, 중기, 장기적으로 적응할 수 있는 방안을 제공하는 것이 중요하다고 합니다.
<그림 3> ITSM의 구성요소
ITSM의 구성요소는 위 그림과 같으며 일반적으로 여기에 조직(Organization)을 추가하기도 합니다.
|
주요요소 |
설 명 |
|
프로세스 (Process) |
서비스를 계획, 개발
및 적용할 수 있도록 체계적인 지원 및 관리 절차 제공 |
|
인력 (People) |
인력 개발 및 프로세스 중심적인 조직 구성을 통해 새로운
서비스를 창출하는 인적 자원 관리 |
|
기술 (Technology) |
프로세스 자동화, 서비스
제공 및 모니터링, 리포팅 하는 기술 솔루션 및 아키텍처 |
|
조직 (Organization) |
IT에 영향을 끼치는 내/외부의
비즈니스적인 요소 및 문화 |
ITSM 도입효과 및 고려사항
ITSM의 가장 큰 목적은 IT 업무 프로세스 개선을 통해 서비스 품질 개선과 서비스 비용 절감에 있습니다.
고객에게는 SLA에 기초한 고객 맞춤형 IT 서비스 제공이 가능해지며 서비스의 일관성을 보장 받을 수 있습니다.
이를 통해 IT 서비스에 대한 신뢰가 개선되고 품질, 가용성, 서비스 비용 관리가 개선됩니다.
IT 조직에서는 효율성을 높이고 변화 관리가 용이해집니다. 또한 효과적인 아웃소싱이 가능하고 체계적인 IT 서비스 품질관리가 가능해집니다.
성공적인 ITSM의 구축을 위해서 수행되어야 할 과제는 다음과 같이 요약할 수 있습니다.
- ITSM 추진을 위한 TFT 구성은 적절히 검토되고 최선의 선택을 했는가?
- ITSM 구축 기간은 조직의 역량 및 업무 범위에 맞게 수립되었는가?
- To-Be 설계에 대한 오너십을 TFT에서 갖고 있는가?
- 구축된 ITSM의 이행 조직은 프로세스에서 정의되고 요구하는 역할만을 수행하고 있는가?
ITSM 향후 전망
현재 ITSM이 가장 활발하며, 향후 ITAM, 그 이후 IT Governance로 IT 관리의 흐름이 변할 것으로 예상됩니다.
실제로 해외에서는 ITAM과 ITSM, 그리고 IT Governance가 하나의 고리를 이루면 구축되고 있는 상황이라고 합니다.
ITAM (IT Asset Management)
- ITAM은 기업 내 각종 IT 자산을 구입부터 폐기까지의 전 라이프사이클을 관리한다는 개념입니다.
IT Governance
- IT Governance는 IT 자원과 정보, 조직을 회사 전체의 경영 전략이나 목표와 연계해 경쟁 우위를 확보할 수 있는 것을 말합니다.
'컴퓨터공학 > 소프트웨어공학' 카테고리의 다른 글
| 소프트웨어공학의 3R(Reverse-Engineering, Re-Engineering, Re-Use)에 대하여 (0) | 2011/10/01 |
|---|---|
| Agile 이야기 (0) | 2010/06/28 |
| ITSM(IT Service Managment)에 대하여 (0) | 2010/06/25 |
| 소프트웨어 개발 생명주기(SDLC)에 대하여 (2) | 2009/05/13 |
Trackback 0 And
Comment 0
저도 처음에는 프로그래밍 언어만 할 줄 알면 프로그램을 만들 수 있다고 생각했던 적이 있었습니다.
실제로 그렇게 만들었던 프로그램도 꽤 많지요. ^^
하지만, 지금 생각해 보면 그렇게 만들었던 프로그램은 세상에 빛을 보지 못했거나 그리 오래 가지 못했던 것 같습니다.
반면에 체계적인 분석과 설계로 만들었던 몇몇 솔루션은 아직도 현업에서 잘 사용하고 있는 것을 볼 수 있었습니다.
바로 체계적인 분석과 설계라고 하는 것이 소프트웨어 개발 생명주기(Software Development Life Cycle)의 핵심이 아닌가 합니다.
여기에 추후 운영에 필요한 유지보수도 무시할 수는 없겠죠..
흔히 SDLC라고 하면 Waterfall, Prototyping, Spiral, RAD, Incremental Development, Evolutionary Development, 4 Generation 등의 모델을 들면서 어렵게 이야기 하는 경우가 많습니다.
물론 어떤 모형을 사용하는지 중요하지만, SDLC가 왜 필요한지 생각하지 않고 사용하는 것은 무의미하다고 봅니다.
단순하게 이런 모델로 개발을 진행한다고 하면서 코팅부터 하고, 프로젝트 개발이후 문서작업을 따로 하는 경우를 종종 봐왔기 때문입니다.
특정 모델들을 떠나서 가장 기본적인 또는 고전적인 SDLC의 형태는 다음과 같습니다.
프로젝트를 수행하려면 먼저 계획을 세워야 합니다. 투입될 인력이나 기간을 토대로 비용도 산정해 봐야하고 비즈니스 타당성도 검토해 봐야겠죠.. 물론 분석이나 설계 없이 이 작업을 정확하게 할 수는 없을 겁니다.
그러나 기존의 경험을 토대로 개괄적인 계획은 세워야만 프로젝트를 시작할 수 있을 겁니다.
추후 분석과 설계를 토대로 계획을 수정할 수도 있을 겁니다.
다음으로 분석과 설계입니다. 먼저 둘의 차이점에 대해서 알아보죠..
분석은 무엇(what)에 관심을 갖는 것이고 설계는 어떻게(how)에 관심을 갖는 겁니다.
만들어야 할 프로그램은 하나지만, 그것을 만드는 방법은 여러가지가 있을 수 있습니다.
즉, 분석은 만들려고 하는 프로그램을 하나로 명확하게 정의하는 과정이라고 할 수 있습니다.
설계는 프로그램을 만드는 방법을 찾아보는 것이라 할 수 있겠죠..
이것을 반대로 수행한다면 어떨까요? 어떻게 만들까를 먼저 생각하고 무엇을 만들지를 결정한다..
말이 안되는 것처럼 보이지만 의외로 현업에서 자주 발생하는 듯 합니다.
특히, 개발자의 관점에서 브레인스토밍 회의시 무엇을 만들지를 이야기 하고 있는데, 어떻게 구현할지를 걱정해서 "이건 안된다, 저건 안된다" 하는 경우를 종종 볼 수 있었습니다.
앞에서도 이야기 했듯이 분석에서 만들려고 하는 프로그램을 명확하게 정의해야 합니다.
그것을 어떻게 구현할 지는 설계 단계에서 결정하면 되는 것이죠..
"개발하지 못할 것이 어디 있겠는가?"하는 마인드가 분석 단계에서 중요하다고 볼 수 있겠죠..
설계 단계에서는 가장 효율적이고, 사용자가 편리하고, 개발을 빠르게 할 수 있는 방법을 찾아서 정리하고 모듈별로 나누는 작업까지 해야 겠죠..
코딩및 구현은 프로그램 개발에 있어 기본적인 사항이라 할 수 있습니다.
테스트의 중요성이 요즘 커져서 Test Driven Development라고 하는 방법도 나오고 있고, JUnit과 같은 단위 테스트 도구도 많이 발달한 상태입니다.
통합 테스트에 대해서는 좀 더 고려가 필요하겠죠...
마지막으로 유지보수입니다. 실제 보면, 개발 기간보다 시스템을 운영하는 기간이 더 길기 때문에 유지보수의 중요성이 점차 커지고 있습니다. 천만원에 개발했는데, 유지보수에 억단위가 들어간다면 좋은 시스템은 아니겠지요..
기본적인 SDLC의 단계를 나열해보니, 그리 어렵지 않다는 생각이 들겁니다.
물론 실제 적용하다 보면, 구현 단계에서 특정 부분을 변경할 경우 해당하는 분석/설계 산출물까지 변경해야 하는 번거로움이 존재할 수 있습니다.
이런 문제들은 반복이나 자동화 툴을 이용하는 다양한 SDLC의 모델들을 통해서 해결해 나갈 수 있을 것입니다.
중요한 것은 소프트웨어 개발 생명주기가 단순히 문서 작업을 늘리고, 이론적일 뿐인 방법론이 아니라 제대로 된 소프트웨어를 개발하기 위한 필수 사항이라는 것을 이해해야 한다고 봅니다.
[읽을만한 자료]
소프트웨어 개발 생명 주기의 이해
코딩보다 먼저 할 일 ‘분석과 설계’
설계도가 우선, 그 다음이 구현이다
'컴퓨터공학 > 소프트웨어공학' 카테고리의 다른 글
| 소프트웨어공학의 3R(Reverse-Engineering, Re-Engineering, Re-Use)에 대하여 (0) | 2011/10/01 |
|---|---|
| Agile 이야기 (0) | 2010/06/28 |
| ITSM(IT Service Managment)에 대하여 (0) | 2010/06/25 |
| 소프트웨어 개발 생명주기(SDLC)에 대하여 (2) | 2009/05/13 |
Trackback 0 And
Comment 2
