[컴퓨터 전공][과목 : 소프트웨어공학][내용 : 아키텍트, SWEBOK 분석]

소개글

컴퓨터 전공 소프트웨어공학 과정에서 진행한 아키텍트, SWEBOK 분석입니다.

목차

1.아키택트 직업적 특성
2.세계적 전망
3.아키텍트가 되려면?
4.아키텍트 관련 자격증과 취득 방법
5.소프트웨어 아키텍트 관련 인물
6.SWEBOK 자격증
7.국내외 활용도
8.관련 자격증과 취득 방법
9.SWEBOK의 주요 요소
10.SWEBOK의 목차

본문내용

아키텍트는 특성을 2가지로 분류해보면 다음과 같다.
하나는 아키텍트는 경험이 많아야 하고 하루 아침에 만들어지는 것이 아니라 서서히 키워지는 것이란 점이다.
두 번째는 아키텍트는 역할이지 등급이 아니란 점이다.
위의 2가지 분류로 아키텍트의 특성을 표현하기 위해서는 부족한 면이 있어 아키텍트를 정의하는 측면과 구현하는 측면으로 나눠 이야기 해볼까 한다.
1. Management of non-functional requirements
고객은 요구사항을 매우 모호하게 주거나 아니면 아예 주지 않는다. 온라인 어플리케이션은 예상 사용자 규모에 따라 성능을 산정해야 하는 기술적 어려움이 따르고, 업무 프로세스와 관계된 배치업무는 실제 업무 방식을 모르면 성능 기준을 수립조차 하기 어렵다. `잘하는 법`을 교육하기는 어렵지만, 잘 다듬어진 템플릿과 예제가 도움을 주긴 한다. 종종 몇몇 조직에서 EA나 프로세스 관련 프로젝트를 수행하고 나서 (다른 산출물은 유명무실하게 버려두지만) 비 기능 요구사항에 대한 체크리스트를 널리 재사용하는 경우를 본다.
2. Architecture definition
적절한 수준으로 비 기능 요구사항의 설정하면 아키텍처를 정의한다. 하지만 모든 시스템 아키텍처를 갖기는 하겠지만 항상 아키텍처를 정의하는 것은 아니란 점, 신규 시스템이냐 기존 시스템 수정이냐에 따라 크게 다르다는 점을 생각해보아야 한다.
3. Technology selection
기술 선택을 할 때 고려할 다양한 사항을 열거한다. 또, 기술 선택에는 위험이 따르기 때문에 검토와 평가가 필요하다. 위에 열거한 항목 외에도 흔한 일은 아니지만, 법적 문제나 기술 제공 업체(vendor)의 경제력이 문제가 되는 일도 있다. 국내 솔루션이 외산 솔루션 복제 소송에 휘말린 경우가 있고, 직원 월급을 지급하지 못해 솔루션 커스터마이징 인력이 안정적으로 일하지 못하는 경우가 발생한 바 있다.
역시 신규 시스템이냐 기존 시스템 수정이냐에 따라 기술 선택도 달라진다.
4. Architecture evaluation
소프트웨어가 갖는 복잡함과 추상적 성격 탓에 이해관계자에게 `구현할 소프트웨어가 어떤 것`인지 보여주기 어렵다. 시스템뿐 아니라 아키텍처도 테스트해야 한다. 요즘은 많은 프로젝트에서 파일럿을 통해 아키텍처를 검증한다. 주어진 제약(기간, 자원, 예산)하에서 무엇을 검증하느냐가 결국 관건이다. 막연히 잘 되기를 바라지 말고, 위험요소에 대해 적극적으로 대처해야 한다.

참고 자료

없음