ANMIAN

프로젝트도 중반이 되자 프로젝트 자체의 어려움보다 팀원 관리가 힘들었다. 팀이 원하는 사람들끼리 하면 잘하는 사람들끼리 모인다는 불만이 많아서 랜덤으로 모았더니 의욕이 없는 사람이 많았다. 의욕적인사람 4명 + 의욕없는 사람 2명으로 6명이서 작업하는 것보다 의욕있는 사람 3명이서 작업하는 것이 훨씬 진행도 빠르고 의욕적이다.
한명은 아예 나오지 않았는데 팀에 속해있다는 것만으로 의욕이 저하되었다.
만약 실무였다면 다 제거하고 3명이서 작업했을 것이다.

이 작업은 중심이 시스템구조도였다. 이건 DFD에서 지적받은 내용을 수정하고 DFD대로 설계만 하면 되는 작업이라 비교적 쉽게 했다.(물론 시간은 많이 걸렸다. 밤을 새면서도 다 끝내지 못해 발표하기 직전까지 작업했던 내용이다. 구조도를 그리기위해 A4를 약 4권가량 허비했던 기억이 난다.)

모듈설명서는 program language만 알고 있으면 누구든 보고 구현할 수 있을 정도까지 만들었다. 뿐만 아니라 구현 한 후에도 함수들에 대한 설명서가 될 수 있도록 만들었다.
하지만 모듈설명서를 발표 직전에 만들었으며 내가 작성하는 요령을 가르쳐주고는 알아서 하라고 던져줬기 때문에 양식과 내용이 부분적으로 일치하지 않는다.
더욱 심각한 문제는 기껏 다 만들어놓고서도 막상 구현할 때는 엉뚱하게 해버렸다는 것이다. 이유는 우리가 작업한 언어는 C#으로 객체지향언어였으며 구현할 때도 객체지향적 사고에 맞추어 구현했기 때문이다. GUI환경은 객체지향 프로그래밍이 훨씬 자연스럽기 때문이다. 만약 콘솔환경의 프로그램이었다면 모듈설명서대로 작업하지 않았을까 하는 생각이 든다. (이 작업을 하면서 객체지향 소프트웨어공학을 수강해야 겠구나 하는 생각이 들었다. 하지만 수강하기 전에 휴학을 했다는...)

UI는 경남이가 담당했다. 색상디자인 책까지 뒤지며 건강과 관련된 프로그램은 푸른 색 계열로 하는 것이 좋다며 색상과 모양까지 모두 디자인했다. 확실히 요즘 프로그램은 기능도 중요하지만 그에 못지않게 디자인도 중요하니까.. 이쁜 디자인과 거리가 먼 나로서는 부러운 능력이다. 실제 구현에서는 UI의 디자인이 제출 자료보다 더 이쁘게 완성되었다.
기능적인 부분으로 가면 디자인이 좀 불편하게 되었다. 입력부분은 한곳에 모으는 것이 좋은데 자료를 검색후 리스트에서 클릭으로 하는 것으로 많이 해놨기 때문에 익숙한 유저는 불편함을 느낄 수도 있다.
사용자가 입력하는 부분은 한곳에 모으는 것이 좋다. 한국의 경우 참고사항은 왼쪽, 입력사항은 오른쪽에 하는 것이 일반적이다. 자료를 검색 후 입력해야 한다면 다양한 방법으로 입력하는 것을 지원하라. 검색 후 클릭으로 입력, 검색 없이 입력, 검색 후 키보드로 입력 등 모든 사항을 고려해주는 것이 좋다.

DB schema는 별로 고민할 필요도 없이 혼자서 주욱 써서 내려갔고 ER diagram은 모두들 포기해서 역시 혼자서 작업했다. 그룹화는 가능한 피하려고 했으나 결국 그룹화가 나와버렸다. DB시간에 나름대로 열심히 공부했으나 역시 ERD는 경험이 많이 필요한 것 같다.

고생은 고생대로 하고 만족도는 떨어졌던 요구분석 명세서..
제약사항을 제대로 이해하지 못해 어떤 내용을 적어야 하는 지 고민했었다. 결국 이런저런 자료들 찾아보고 적긴 했는데 엉뚱한 내용들이었다. 실질적인 내용들이 공개된 곳도 없을 뿐더러 자세한 설명도 제대로 찾기 힘들었다.

DFD(Data Flow Diagram)는 정말 끔찍하게 고생했다. 팀원은 6명이었으나 벌써 2명은 나가 떨어지고 실질적인 작업은 4명이서 하고 있었다. 그나마도 나중에 한명이 안해서 3명이서 구현했다는 슬픈 전설이 이어져 내려온다.

그 중에서 DFD는 우리 팀이 처음으로 부딧힌 장벽이었다. 며칠동안 매일 모여서 밤늦게까지 회의했지만 사공은 많고 체계는 없어서 오락가락하다가 결국 원점으로 돌아가길 반복했다. 결국 다 엎어버리고 며칠동안 밤새면서 DFD를 혼자 A4에 그리고 그 내용을 권순형이 모두 PPT로 옮겼다. 그렇게 하니 진도가 빨라졌다.
의견도 내지 않으면서 문제점만 지적하는 것은 팀의 속도와 의욕을 떨어뜨린다.

DFD에서 대부분의 팀인 심한 감점을 당했는데 우리 팀은 거의 감점이 없었다.
2점이 감점되었는데 하나는 제약사항이 부실하다는 점에서 감점당했고, 1점은 DFD에서 중심 process가 호출하는 process를 기록하는 것은 맞지만 중심 process를 호출하는 caller까지 기록해버려서 감정당했다. (여기서 말하는 중심process란 대항 페이지에서 표현하고자하는 process다.)

invalid-file

개발언어 : C#
DB :  MySQL

소프트웨어공학1(이하 소공1) 과목에서 term project로 작업한 내용이다. 개인 과제만 받아오다가 처음으로 team report를 시작했고 팀장으로 있으면서 배우는 것도 많았다. 소공 1에서는 구조적 프로그래밍 기법에 의한 프로젝트를 했다. 아직까지도 구조적 기법을 많이 사용하고 있고 담당 교수님의 전문 분야가 구조적 프로그래밍과 DB였으니 한번 배울만 하긴 했다.

수업 내용만으로 프로젝트를 진행시킨 다는 것은 무리가 많았다. 수업시간이 짧아서 제대로 배울 수도 없을 뿐 아니라 직접 해보지 않고서는 무슨 이야기를 하는지 감이 오질 않아서 더욱 그랬다. 2주에 한번 진행과정을 발표했는데 발표가 다가오면 항상 밤을 새고 있었고 팀원들과 매일 만나서 의논하고 이틀에 A4한권 분량을 날렸다.
보고서 작성이 엄청 힘들게 느껴졌는데 작성하고 있을 시간도 부족했을 뿐 아니라 지식에 체계가 잡히지 않았으며 내가 생각하기에 조금 불필요하다 싶은 내용들도 다 보고서에 포함시켜야 했기 때문에 더욱 힘들었다.(내용 자체가 불필요하다는 것이 아니라 참여인원도 적고 프로젝트 규모도 적은 경우엔 필요하지 않은 내용도 있었단 말이다.)

처음 발표는 별 준비없이 시작한 주제발표였다. 선배들의 이야기를 들으니 다들 관리 프로그램만 만든다고 해서 우린 뭔가 새로운 것을 시도하려고 했으나 새로운 분야의 기술을 끌어들이면 그것을 공부해야 하는 시간도 들고 발표준비까지 하려면 시간이 부족해서 반도 못할 것 같아 결국 관리 시스템으로 정했다. 어떠한 관리 시스템이건 다 비슷했던 것 같다.
만약 지금 했다면 웹과 연동시켜 좀더 확장된 프로젝트를 했겠지만 그당시엔 실력 부족때문에 많이 소극적이었다.

아직 프로젝트는 시작하지 않았고 사전 자료 수집과 준비작업 중이다.
아래는 보컬로이드라는 소프트웨어인데 설명에 나오는 것처럼 일본 애니애니메이션 음악 생성기란다.
오타구들을 15750엔이라는 부담스런 가격에도 일본아마존에서 판매 1위였다는 내용이 언뜻 보인다.

이 SW는 기본적으로 발음을 하나씩 입력해두는 방식을 채택하여 음성합성을 하고 있다.
이러한 방식은 우리나라에서도 음성안내 시스템에서 적용하고 있는 것으로 알고있다.
각 발음들을 독립적으로 녹음하여 그러한 발음들을 이어붙여서 말을 만들어내는 것이다.

거기에 음의 높낮이를 선택하여 노래를 만든다...
이러한 기술도 연재 대량생산용 가수들에게 많이 사용되고 있는 것으로 알고 있다. 불안정한 음을 기계적으로 맞추어 주는 기술이다.

결국 SW는 음이 변하지 않으면서 발음도 변하지 않는 것을 기준으로 나누어야 하고 발음이나 음의 높이중 하나라도 바뀌면 그곳을 기준으로 다시 나누어줘야 한다. 각 객체는 발음, 음의 높이, 길이를 속성으로 가지고 있으며 대부분은 그것을 사실감있게 재생하는 코드로 예상된다.

노래를 부르는 소프트웨어라... 꽤 효율적인걸..

=================================================================================================================

VOCALOID 2: The Japanese Anime Song Generator