5개월전쯤에 요양원 관리 프로그램 질문드렸던 햏자입니다.^^;
원글은 아래와 같습니다.
http://kldp.org/node/124802
당시 여러 익명님과 jachin,snowall님의 조언에 힘입어 야심차게 준비작업을 진행하여...
경고해주셨던 문제점들을 직접 체험했습니다..장난 아니네요...ㅠ.ㅜ
어떻게된게 150여명중에(물론 대부분 고령인분들이 대부분이시지만) 가장 엄선된 3명에게만 설명하는데도 완전히 이해시키는게 거의 불가능에 가까웠습니다.
특히나 전산화 요구사항을 정리 총괄해야하는 ***팀장은 완전히 백기를 들었고 아마도 불가능한 업무를 맡겼던것 같습니다..ㅡ.ㅜ
기획총괄을해야하는 저조차도 종이에 기본개념도를 작성할때와 달리 MySQL 데이터베이스및 테이블을 작성할때 요구사항들이 계속 늘어나다가 여러 테이블사이의 참조관계때문에 작성자인 저조차도 파악이 힘들정도가 됐었습니다....ㅠ.ㅠ
그레서 방향을 과감히 전환하여....ㅡㅡ+
해당분야를 물품구매및 재고관리 부문에만 한정시키고 필요할지도 몰라 넣었던 군더더기를 모두뺐습니다.
웹서버 구동에 필요한 최소한의 기능만 작성(이 아니라 다른 책에 있는 소스코드들을 copy&paste하고 간신히 돌아가는정도로만 손보기)하여 메뉴구성하였습니다.
왜냐하면 기획자(?)와 작성자(?)가 동일한 상황에서 단순히 데이터베이스 테이블만 작성하는중에도 여러가지 요구사항과 아이디어가 나올 정도이니 간신히나마 돌아가는 프로토타입(?)을 시연하면 실무직원들을 이해시키고 의견 취합하는게 가능할것 같아서였습니다.
이같은 의견이 취합되고 실제 적용해봐서 계속 요구사항을 수정보완한다음에 업무처리 flow를 완성해서 전문 개발자에게 의뢰하면 돼지 않을까 십어서요.
비슷하게나마(^^;)프로토타입을 제작한 경험이 있는 입장에서 개발자들과의 의견교환이나 핸들링도 더 용이하리라 생각돼구요.
12:04익명님, snowall님 말씀데로 처음 적용분야는 물품구매및 재고관리에만 한정시켜서 인터페이스하구 기본 DB연결만 보여줬는데...일단 반응은 꽤 신기해하고있습니다.ㅡㅡㅋ
이렇게 글을 쓰는 이유는 과거 도움을 주셨던 익명분들께서 조언해주셨는데
"당신의 조언을 받고 나는 아직 포기하지 않고 있으며 이러이러하게 진행중이다."라는 말을 하고 십었기 때문입니다.^^;;;;;
그리고 아마도 국내에서 IT와 가장 먼 산업분야에서 자체적으로 주도하는 사례로는 드문케이스라 생각되서 다른 나름 흥미롭게 보실수도 있을것 같아서요^^;
(잘모르는 원청업체에서 이렇게 생각하다가 변해가는구나 라는...^^)
지금 LAMP에서 시작하다가 동적콤보박스때문에 자바스크립트책을 빌려오는 길입니다.ㅡ.ㅡ
이거 어디까지 확대가 될지...ㅜ.ㅜ
시나리오가 중요합니다.
우선, 처음 올리셨던 쓰레드를 지금도 기억하고 있을 정도로 관심을 두고 있었습니다.
실제로 진행을 하시고 계시다니 존경을 표합니다.
프로토타입을 먼저 만들고 조금씩 확장해가면서 전체 시스템을 만들어가는 접근 방법은 매우 좋은 방법입니다.
중요한 것은 프로토타입은 프로토타입일 뿐이라는 것입니다.
경험이 많고 실력이 좋은 전문 개발자는 프로토타입을 크게 변경하지 않고 그대로 재사용할 수 있습니다. 하지만 대부분 프로토타입은 사용자의 요구사항을 수집하기 위한 도구 이상으로 사용하려고 하면 오히려 전체 시스템적으로 봤을 때 큰 무리가 됩니다.
아.. 뭔가 좀 두서가 없는 문장인데요.
예를 들면 전체 시스템이 "ABCDEFG"로 구성되어야 하고 개발의 전략을 A를 먼저 만들고 확장해서 B를 붙이고 확장해서 C를 붙이고 확장해서 D를 붙이고... 최종적으로 ABCDEFG를 만들겠다로 세웠다고 가정해 봅니다.
이럴 때 개별적인 A, AB, ABC, ABCD를 만들어 감에 있어서,
A를 만들 때는 BCDEFG가 나중에 붙어야 할 부분을 고려해야 하고,
AB를 만들 때는 CDEFG가 나중에 붙어야 할 부분을 고려해야 합니다.
그것이 아니라면 개별적인 A, B, C, D, E, F, G가 모두 완전히 독립적으로 동작해서 다른 모듈을 상관하지 않고 개발해도 될 정도로 설계를 잘 해야 합니다.
확장을 고려한 개별 모듈의 개발이 제대로 되지 않는다면, A를 개발할 때는 그냥 잘 되고 A에 B를 붙일때에 임시방편 코드가 조금 들어가고, AB에 C를 붙일 때 미봉책으로 이리저리 끼워 맞춘 코드가 또 삽입되고... 나중에 ABCDEF 정도까지 갔을 때는 아주 누더기에 여기저기 임시 코드들이 흘러 넘치는...
한 번 만들고 다시는 유지보수하지 못하는 프로그램이 되고 맙니다.
물론 한 번 만들고 절대 수정도 하지 않고 계속 그 시스템만 쓸거라면 상관없겠지요.
이런 부분을 제대로 고려해서 시스템을 만들려면 최소한 초반에 도메인(여기에서는 노인 요양원)에 대한 요구사항 분석과 업무 프로세스에 대한 시나리오가 구성이 되어야 합니다.
그러기 위해서는 실사용자들에게 IT 시스템을 이해시키려고 하기 보다는 "그들의 언어"로 된 시나리오를 먼저 구성해야 합니다.
코드나 설계는 전체 시스템에 대한 것이 아직 없다 하여도, 시나리오는 전체 시스템에 대한 것이 완성되어 있어야만 이후에 큰 삽질을 줄일 수 있습니다.
별 도움도 안되는 글을 길게도 썼는데요. half4u님께서 꼭 성공하시길 바라는 마음에서 댓글 남깁니다.
----------------------
얇은 사 하이얀 고깔은 고이 접어서 나빌레라
길게 작성했던 그 익명입니다. 지치지 않고
길게 작성했던 그 익명입니다.
지치지 않고 진행하시고 계신 그 열정 정말 존경합니다.
글로 봐서는, 문제가 생겼을때 요구 사항을 한정하고 촛점을 맞추어서 작은 발걸음과 피드백으로 가는 것은 말은 쉽지만 실제로 행하는건 정말 어렵다는 사실을 알고 있어서 더 감동 받았습니다.
IT 전공이 아니시라면, 좀 더 긴호흡을 지치지 않고 즐기면서 가시길 기원합니다.
옙. 미미하나마(진짜 미미ㅜ.ㅜ) 실물로 작동시키게 됐습니다^^
2월경에 인트라넷 형태로 시범가동 시작할 예정입니다.^^
(아쉽게도 개인정보들이 다수 포함되있고 해킹에대한 방어가 거의 '0'에 가까워서 격려해주셨는데도 인터넷에 공개를 못하네요....^^;;;;;)
기본구조는 정말 간단합니다.^^;
로그인 인증과 물품구입기안메뉴와 입소어르신정기정보전달메뉴, 소모품사용기록메뉴, 스케줄표...달랑 3개입니다.
로직은 최대한 간단하게하고 사용자들이 마우스 클릭만으로 대부분의 기능을 사용할 수 있도록 했습니다.
(사용자분들이 컴퓨터 써본적없는 50대시라서...ㅡㅡ; 구인광고도 컴퓨터대신에 벼룩시장을 주로 보시더라구요...ㅜ.ㅜ)
나빌레라님의 말씀에 다시한번 고민하게 돼네요...'그들의 언어...ㅡㅡ;;;'
악전고투가 예상돼지만 두분의 추가격려를 가슴속에 세겨두고 정진하도록 하겠습니다.^.^