소프트웨어 공학

소프트웨어 공학은 공학을 소프트웨어에 적용하는 것으로 소프트웨어를 개발하고, 운용, 유지보수 등을 서술적으로 다루는 학문이다. 보통 소프트웨어 하면 사람들이 프로그래밍이랑 관련이 깊은 것으로 알고 있는데 이를 벗어나 유기적으로 성장한 분야가 소프트웨어 공학이다.



소프트웨어 공학을 다루기에 앞서 프로그래밍 언어부터 얘기하면 프로그래밍 언어는 1950년대부터 나타났다. 데이빗 파르나스는 열쇠가 된 개념인 모듈성과 정보 은폐를 1972년에 소개하였고 이는 프로그래머들이 다루기 힘든 소프트웨어 시스템의 복잡성을 더 쉽게 다룰 수 있게 했다. 동시에 하드웨어를 관리해 주는 소프트웨어 시스템인 운영 체제가 소개되었고 최초의 운영체제는 유닉스였다.



소프트웨어 공학자가 되기 위해서는 프로그래밍에 관한 지식이 필수적인 요건이라 할 수 있는데 그렇다고 해서 프로그래밍 언어만 알고 있으면 안 된다. 세부적으로 보면 소프트웨어 공학에는 여러 가지 분야가 있는데 이것은 우리가 어떤 프로젝트를 진행할 때 볼 수 있는 과정에서 볼 수 있는 비슷한 것들이다. 사업을 할 때도 어떤 기업의 상품에 대한 제작 의뢰가 들어왔을 때를 보면 상품의 요구사항, 설계, 시험, 유지 보수, 품질 검수 등의 단계를 거친다. 만들어지고 판매되기 직전까지 다양한 과정을 거치는 것을 볼 수 있다. 소프트웨어 분야에서도 이러한 것이 비슷하게 있다. 요구사항, 설계, 개발, 시험, 유지 보수, 형상 관리, 공학 관리, 개발 프로세스, 공학 도구, 품질 등 약간은 다르지만 멀리서 보면 비슷하다고 할 수 있다.



소프트웨어 요구사항은 시스템을 개발할 때 필요한 조건과 갖추어야 할 능력을 제안하는 것을 말하는데 보통 이러한 요구사항들은 번호를 붙여서 발주자가 제안요청서를 작성하고, 전달받은 요구사항들을 살펴보고 거기에 맞춰 제안서를 제안자가 작성한다.



소프트웨어 설계는 설계할 때 몇 가지 원칙이 있다.



소프트웨어를 설계할 때는 너무 복잡하게 동작하거나 복잡한 기술이 들어가서는 안 된다. 정확한 목표와 기능만을 위해서 적은 기술들을 이용해 설계해야 한다. 그렇지 않고 복잡하게 개발하면 예상치 못한 오류가 나거나 실패 할 수도 있다.



소프트웨어는 사용하는 사용자에 먼저 맞춰서 설계해야 한다. 잘 만들어지고 기능이 좋다 하더라도 사용자가 사용하는 데 불편함을 느끼면 그것은 잘 만들어진 소프트웨어라 볼 수 없다.



소프트웨어는 오류 설계 원칙도 따라야 하는데 설계한 기술이 실패하더라도 그에 따른 대안이 나올 수 있도록 설계해야 한다. 개발하면서 생기는 오류는 잘못된 것이 아니다. 오류는 오히려 하나씩 잡아나가면서 견고하게 설계하면 다음에 예상치 못한 문제를 발생시키는 것을 막을 수 있다.



소프트웨어를 이용하기 위해서 이용자와 컴퓨터 사이를 연결해 주는 인터페이스를 설계할 때도 몇 가지 원칙이 있다.

사용자들은 개발하는 게 아니고 용만 하는 입장이므로 인터페이스는 최대한 단순하게 설계해야 한다. 하지만 단순하다 해서 기능이 약하거나 결과가 제대로 도출되지 않는 일은 발생하지 않아야 한다.



그리고 개발한 시스템이나 웹사이트를 보는 기기들은 현재 다양하게 있기 때문에 가능한 한 다양한 기기에 맞춰 사용자가 정상적으로 이용할 수 있도록 설계가 되어야 한다. 그리고 따르기 쉬운 지침과 시스템과 상호 작용을 할 때 알아보기 쉽게 정보를 전달할 수 있도록 해야 한다. 



개발된 소프트웨어는 유지보수도 잘 되게 설계해야 한다. 유지보수란 쉽게 말해 설계 이후 제품을 다 제작한 다음 결함이 생기면 수정을 할 수 있어야 한다. 하지만 소프트웨어에서 유지보수란 수정의 목적도 있지만 추가 작업을 하는 듯의 수정과는 다른 목적으로 사용되는 경우가 많은 편이다.



소프트웨어는 설계하면서 하루 만에 한 개의 파일로 만들어지거나 그럴 수는 없다.

수많은 다양한 종류의 파일들과 함께 개발되며, 또 개발을 한 사람이 하지 않고 수십명, 많게는 수백명의 사람들이 함께 프로젝트를 진행하는 경우가 있다. 그런데 개발할 때 사람들은 같은 시간에 각자 맡은 업무를 하며 개발할 것이다.

그런데 어떤 한 파일을 5명이 동시에 공유하면서 사용해야 하는 파일이라 치고, 5명 각자가 그 파일의 내용을 수정하거나 삭제하고 난 뒤 저장하면 어떻게 되겠는가? 파일은 엉망진창으로 꼬이게 되고 실행 파일은 결국 제대로 실행이 되지 않고 오류가 날 것이다.



위와 같은 사태를 방지하기 위해 생긴 것이 바로 형상 관리이다.

형상 관리란 소프트웨어의 개발 과정에서 소프트웨어의 변경 사항을 관리하기 위해 개발된 일종의 시스템이라 볼 수 있겠다. 이것은 소프트웨어 개발의 첫 단계부터 완료 단계까지 하는 활동이다. 



그래서 형상 관리를 하면 얻게 되는 이점이 무엇이냐고 물어보는 사람들도 있을 것이다. 형상 관리를 하면 소프트웨어의 변경 사항을 체계적으로 관리할 수 있는데 이걸 좀 자세히 설명하면 변경된 날짜, 변경한 사람, 변경된 내용 비교 등

파일이 누구로 인해 어떻게 수정이 되었고 어디까지 수정이 된 건지 정확하게 알 수가 있게 된다. 그리고 수정을 잘못했거나 이전 파일로 복구해야 한다고 하면 그 버전의 파일로 복구도 하여 관리할 수도 있다.



형상 관리 시스템을 이용할 때 쓰이는 용어가 여러 가지가 있는데 대표적으로  쓰이는 몇 가지를 알아보자.



저장소 : 이전 버전이나 최신 버전의 파일들과 변경 내용에 관한 정보들이 저장되어 있는 곳을 말한다.

체크아웃 : 보통 체크아웃은 프로그램에 개발 인력으로 투입이 되는 가장 처음에 하는 건데 쉽게 말하면 서버의 저장소에 있는 최신 파일을 로컬저장소로 가져오는 것을 말한다.

동기화(update) : 체크아웃을 한 뒤로부터 업데이트하면 이것은 저장소에 있는 최신 버전의 파일을 가져와 자신의 로컬저장소를 동기화하는 것을 말한다.

커밋 : 개발자가 파일을 수정하고 저장소에 자신이 수정한 파일을 올리는 행위를 말하는데 커밋을 하기 전에는 항상 update를 하고 충돌 하는 것이 없는지 확인을 한 후에 커밋을 해야 한다.



형상 관리를 이용할 때 위에서 아래 순서로 기능을 이용하는 게 일반적이다.