posted by bluelimn 2008.02.27 11:57
구현부분은 소스를 공개할 수가 없다.
C#은 객체의 속성들을 hardcoding할 수도 있지만 대부분 속성창에서 클릭으로 설정해버린다. 그런 경우 다른 곳에서 같은 설정을 할 경우 다시 클릭해야 하기 때문에 불편했다. 그래서 설정들을 모두 코딩한 다음 복사해서 바로 사용할 수 있도록 통일시켰다.
DB와 연동하는 부분이 어려웠다.
특히 실제 사용하는 사람들이 순서에 맞추어 사용하지 않기 때문에 유연성이 가장 문제가 되었다. 가령 사물함을 신청하고 제거할 때 수강기간이 만료되고 회원이 탈퇴하면 사물함이 비는 것이 정석이다. 하지만 실제로는 그렇지 않은 경우가 있다. 회원은 탈퇴하였으나 그 속에 짐들이 그대로 들어 있어 관리작 짐을 따로 보관하거나 혹은 그대로 얼마간 보관해주는 경우가 그러하다. DB에 회원이 없지만 사물함에서는 회원ID가 외래키(foreign key)로 지정되어 있었기 때문에 함부러 삭제할 수가 없었다. 어쩔 수 없이 꼼수로 해결하긴 했지만 지금 생각해보면 회원ID를 살려두면 된다는 생각이 든다. DB는 엄청난 자료를 가지고 있는 것이 보통이다. 회사 입장에서도 회원이 탈퇴를 하더라도 한번 수강한 회원이라면 우선순위가 높은 잠정적 고객이므로 정보를 유지하는 것이 더욱 유리하다. 그리고 회원ID를 그대로 살려두면 나중에 그 물건이 어떤 회원의 물건인지 알 수 있고 연락을 취할 수도 있다.
생각이 한쪽으로 굳어지면 고민 끝에 악수를 두는 경우가 많다.

구현만 하고 최종보고서를 작성하지 않은 것이 조금 아쉽다.
최종보고서는 시스템의 성능을 측정한 결과가 들어가야 할 것이다.
TAG
posted by bluelimn 2008.02.27 11:41
프로젝트도 중반이 되자 프로젝트 자체의 어려움보다 팀원 관리가 힘들었다. 팀이 원하는 사람들끼리 하면 잘하는 사람들끼리 모인다는 불만이 많아서 랜덤으로 모았더니 의욕이 없는 사람이 많았다. 의욕적인사람 4명 + 의욕없는 사람 2명으로 6명이서 작업하는 것보다 의욕있는 사람 3명이서 작업하는 것이 훨씬 진행도 빠르고 의욕적이다.
한명은 아예 나오지 않았는데 팀에 속해있다는 것만으로 의욕이 저하되었다.
만약 실무였다면 다 제거하고 3명이서 작업했을 것이다.

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

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

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

DB schema는 별로 고민할 필요도 없이 혼자서 주욱 써서 내려갔고 ER diagram은 모두들 포기해서 역시 혼자서 작업했다. 그룹화는 가능한 피하려고 했으나 결국 그룹화가 나와버렸다. DB시간에 나름대로 열심히 공부했으나 역시 ERD는 경험이 많이 필요한 것 같다.
TAG
posted by bluelimn 2008.02.27 11:06
고생은 고생대로 하고 만족도는 떨어졌던 요구분석 명세서..
제약사항을 제대로 이해하지 못해 어떤 내용을 적어야 하는 지 고민했었다. 결국 이런저런 자료들 찾아보고 적긴 했는데 엉뚱한 내용들이었다. 실질적인 내용들이 공개된 곳도 없을 뿐더러 자세한 설명도 제대로 찾기 힘들었다.

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

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

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



TAG
posted by bluelimn 2008.02.27 10:24
개발언어 : C#
DB :  MySQL

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

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

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