'설계'에 해당되는 글 3건

  1. 2011.12.22 제대로 된 모바일 어플리케이션 개발을 위해 필요한 역할들~ (1)
  2. 2009.05.13 소프트웨어 개발 생명주기(SDLC)에 대하여 (2)
  3. 2007.08.07 조엘 온 소프트웨어 - 유쾌한 오프라인 블로그 (2)

제대로 된 모바일 어플리케이션 개발을 위해 필요한 역할들~

|



모바일 시장이 발전하면서 개인도 모바일 App을 만들어서 돈을 벌 수 있게 되었습니다.
그러나 제대로 된 서비스를 만들려면 어떠한 역할들이 필요할 지 한번 정리해 봤습니다. 

1. 기획 (Planning)

- 새로운 서비스/시스템을 기획
- 일반적인 아이디어를 보다 실현 가능하도록 구체화 함 
- 서비스 기획안, 화면 구성 방안 및 사용자 매뉴얼 등을 작성 
 독서량이 많아야 한다. (다양한 분야의 도서를 읽어야 함)
 기존의 서비스를 많이 사용해 봐야 한다.
 기획하려는 분야의 전문가가 되어야 한다. 
 좋은 아이디어를 선별할 수 있는 판단력이 있어야 한다.
 기획하는 서비스에 대한 시장 조사 능력이 있어야 한다.
 
2. 디자인 (Design)

- 디자인은 단순히 그림을 그리는 것이 아님
- 디자인은 해당 서비스의 이미지를 구축함으로써 성공 여부를 결정함
- UI/UX에 대한 디자인을 수행 (사용자 경험 중시)
 Best Practice와 같은 좋은 디자인을 많이 봐야 한다.
 개발자가 아닌 사용자를 고려하여 서비스를 디자인 해야 한다.
 다양한 입력 방식과 같은 새로운 사용자의 경험을 반영해야 한다.
 매번 새로운 디자인 스타일을 구축해야 한다. 
 웹과 모바일은 디자인에 있어 화면의 크기를 고려해야 한다. 
 
3. 설계 (Architecture)

- IT 서비스를 위해서 개발보다 중요한 것이 설계임 (잘못된 설계는 추후 엄청난 손실을 가져옴)
- 보통 설계자는 개발자보다 많은 경험을 가지고 있음
- DB 설계, Framework 설계, 기능 설계 등을 수행함
 플랫폼(DB, 프로그래밍 언어, 시스템)에 대한 상세한 분석이 필요하다.
 새로운 기술의 등장과 함께 누구보다 먼저 연구해야 한다.
 서비스의 효율을 결정하는 분야이므로 성능 개선에 항상 관심을 가져야 한다.
 DB / OS / 네트워크 / 프레임워크 등 각 분야별로 전문가가 되어야 한다.

 4. 개발 (Development)


- 실제로 서비스나 시스템을 위한 프로그램을 개발하는 분야임
- 프로그래밍 환경은 끊임없이 변화하고 있으므로 빠른 대응이 필요함
- 서비스 가능한 프로그램을 개발함

 프로그램 개발을 위한 기술을 습득해야 한다. 
 개발 관련 기술은 끊임없이 변하므로 꾸준히 학습해야 한다. 
 기존의 API를 최대한 활용하여 개발의 생산성을 높여야 한다. 
 과거 수행한 개발 내역을 자산화 하여 유사한 프로그래밍에 재사용 해야 한다.
 
5. 테스트 (Test)

- 현대의 IT 환경에서 테스트의 중요성이 점차 강화되고 있는 분야임
- 테스트는 정상적인 상황 뿐만 아니라 비정상적 환경에서도 수행해야 함
- Black Box 테스트, 경계 테스트, 예외 처리 테스트 등을 수행함
 테스터는 상당한 끈기와 노력을 요구하는 분야이다. 
 테스트의 중요성에 비해 다른 분야보다 대우를 받지 못하기도 한다.
 테스트 시나리오를 작성하고 이에 따라 철저하게 테스트를 수행해야 한다.
 테스트에서 찾지 못한 오류를 서비스 개시 후 발생하게 되면 손실이 크다. 

6. 운영 (Operating)

- 서비스의 지속적인 발전을 위해서 운영 업무를 수행해야 함.
- IT 분야에서 운영은 하드웨어와 같은 시스템 모니터링 및 장애 대응과 같은 것을 포함함.
- VOC 운영, 시스템 운영, 유지 보수 운영 등의 업무를 수행함

 하드웨어 시스템에 대한 많은 지식을 가지고 있어야 한다.
 시스템 모니터링, 장애 대응, 네트워크 모니터링을 위한 기술들을 습득해야 한다.
 개발을 지원하기 위한 서버 구성 등도 수행해야 한다. 
 고객 대응의 경우, IT 분야는 아니지만 서비스 운영에서는 필요하다.  
 




Trackback 0 And Comment 1

소프트웨어 개발 생명주기(SDLC)에 대하여

|



저도 처음에는 프로그래밍 언어만 할 줄 알면 프로그램을 만들 수 있다고 생각했던 적이 있었습니다.
실제로 그렇게 만들었던 프로그램도 꽤 많지요. ^^

하지만, 지금 생각해 보면 그렇게 만들었던 프로그램은 세상에 빛을 보지 못했거나 그리 오래 가지 못했던 것 같습니다.
반면에 체계적인 분석과 설계로 만들었던 몇몇 솔루션은 아직도 현업에서 잘 사용하고 있는 것을 볼 수 있었습니다.

바로 체계적인 분석과 설계라고 하는 것이 소프트웨어 개발 생명주기(Software Development Life Cycle)의 핵심이 아닌가 합니다.
여기에 추후 운영에 필요한 유지보수도 무시할 수는 없겠죠..

흔히 SDLC라고 하면 Waterfall, Prototyping, Spiral, RAD, Incremental Development, Evolutionary Development, 4 Generation 등의 모델을 들면서 어렵게 이야기 하는 경우가 많습니다.

물론 어떤 모형을 사용하는지 중요하지만, SDLC가 왜 필요한지 생각하지 않고 사용하는 것은 무의미하다고 봅니다.
단순하게 이런 모델로 개발을 진행한다고 하면서 코팅부터 하고, 프로젝트 개발이후 문서작업을 따로 하는 경우를 종종 봐왔기 때문입니다.

특정 모델들을 떠나서 가장 기본적인 또는 고전적인 SDLC의 형태는 다음과 같습니다.


프로젝트를 수행하려면 먼저 계획을 세워야 합니다. 투입될 인력이나 기간을 토대로 비용도 산정해 봐야하고 비즈니스 타당성도 검토해 봐야겠죠.. 물론 분석이나 설계 없이 이 작업을 정확하게 할 수는 없을 겁니다.
그러나 기존의 경험을 토대로 개괄적인 계획은 세워야만 프로젝트를 시작할 수 있을 겁니다.
추후 분석과 설계를 토대로 계획을 수정할 수도 있을 겁니다.

다음으로 분석과 설계입니다. 먼저 둘의 차이점에 대해서 알아보죠..
분석은 무엇(what)에 관심을 갖는 것이고 설계는 어떻게(how)에 관심을 갖는 겁니다.
만들어야 할 프로그램은 하나지만, 그것을 만드는 방법은 여러가지가 있을 수 있습니다.

즉, 분석은 만들려고 하는 프로그램을 하나로 명확하게 정의하는 과정이라고 할 수 있습니다.
설계는 프로그램을 만드는 방법을 찾아보는 것이라 할 수 있겠죠..

이것을 반대로 수행한다면 어떨까요? 어떻게 만들까를 먼저 생각하고 무엇을 만들지를 결정한다..
말이 안되는 것처럼 보이지만 의외로 현업에서 자주 발생하는 듯 합니다.
특히, 개발자의 관점에서 브레인스토밍 회의시 무엇을 만들지를 이야기 하고 있는데, 어떻게 구현할지를 걱정해서 "이건 안된다, 저건 안된다" 하는 경우를 종종 볼 수 있었습니다.

앞에서도 이야기 했듯이 분석에서 만들려고 하는 프로그램을 명확하게 정의해야 합니다.
그것을 어떻게 구현할 지는 설계 단계에서 결정하면 되는 것이죠..

"개발하지 못할 것이 어디 있겠는가?"하는 마인드가 분석 단계에서 중요하다고 볼 수 있겠죠..

설계 단계에서는 가장 효율적이고, 사용자가 편리하고, 개발을 빠르게 할 수 있는 방법을 찾아서 정리하고 모듈별로 나누는 작업까지 해야 겠죠..

코딩및 구현은 프로그램 개발에 있어 기본적인 사항이라 할 수 있습니다.

테스트의 중요성이 요즘 커져서 Test Driven Development라고 하는 방법도 나오고 있고, JUnit과 같은 단위 테스트 도구도 많이 발달한 상태입니다.
통합 테스트에 대해서는 좀 더 고려가 필요하겠죠...

마지막으로 유지보수입니다. 실제 보면, 개발 기간보다 시스템을 운영하는 기간이 더 길기 때문에 유지보수의 중요성이 점차 커지고 있습니다. 천만원에 개발했는데, 유지보수에 억단위가 들어간다면 좋은 시스템은 아니겠지요..

기본적인 SDLC의 단계를 나열해보니, 그리 어렵지 않다는 생각이 들겁니다.
물론 실제 적용하다 보면, 구현 단계에서 특정 부분을 변경할 경우 해당하는 분석/설계 산출물까지 변경해야 하는 번거로움이 존재할 수 있습니다.
이런 문제들은 반복이나 자동화 툴을 이용하는 다양한 SDLC의 모델들을 통해서 해결해 나갈 수 있을 것입니다.

중요한 것은 소프트웨어 개발 생명주기가 단순히 문서 작업을 늘리고, 이론적일 뿐인 방법론이 아니라 제대로 된 소프트웨어를 개발하기 위한 필수 사항이라는 것을 이해해야 한다고 봅니다.

[읽을만한 자료]
소프트웨어 개발 생명 주기의 이해
코딩보다 먼저 할 일 ‘분석과 설계’
설계도가 우선, 그 다음이 구현이다




Trackback 0 And Comment 2

조엘 온 소프트웨어 - 유쾌한 오프라인 블로그

|



조엘 온 소프트웨어
조엘 스폴스키 지음, 박재호.이해영 옮김/에이콘출판

어느날 FineApple(http://fineapple.org/)이 한번 읽어보라고 준 책입니다.
(좋은 책 소개해 준 FineApple님에게 감사드립니다. ^^)

처음 받았을 때는 표지도 좀 별루고~ 다른 볼 책들도 있었기에.. 한쪽에 두고 있었슴다. 그러다가 "이거 한 번 읽어볼까.." 하고 봤더니..
오~~ 처음부터 내용이 너무 괜찮은 거예요..

개발자에 대한 이야기들..
유니코드~~
기능명세 관련 글..

내용이 너무 괜찮아 웹에서 찾아봤더니.. 2006년인가 베스트셀러에 강컴 어워드였더군요.. (그동안 책을 너무 안읽었어 -.-)

끝까지 읽어보니 첫 느낌대로 책의 내용은 괜찮았습니다.
이것저것 블로그 글을 모아둔 것이라서 그런지.. 뒤로 갈수록 약간 산만한 감은 있지만..
전체적으로 좋은 내용이었구.. 번역도 나름 매끄러웠습니다.

그래서 앞으로는 직접 블로그를 방문해서 읽어보려구.. 사이트를 북마크도 해 두었습니다.
http://www.joelonsoftware.com/

일단 기억에 남는 내용을 좀 적어보면..

개발자 선발하는 부분이 첫번째로 떠오릅니다.
"조금이라도 아닌 것 같다." 혹은 "글쎄.. 라는 답이 나온다.. "
또는 "다른 팀에서는 괜찮을 것 같은데.. 우리팀은 아냐.."

이런 경우, 무조건 No라는 겁니다.
솔직히 실질적인 개발자가 부족한 우리 현실에서는 상당히 어려운 문제죠.. -.-
그러나.. 잘못 뽑은 개발자 한명이 프로젝트를 망칠 수 있으니..
절대적으로 조엘의 말에 공감하는 부분이었슴다..

두번째는 한 장에 걸쳐 언급된 유니코드...
한글과 같은 멀티바이트를 처리할 때는 꼭 알아둬야 하는데요~
솔직히 저도 정확히 몰랐다는..

특히, IE가 자동으로 언어인코딩을 처리한다는 점.. (음.. 한국어 자동감지가 그거였던 것 같습다.)
항상 보면서도 몰랐네요.. -.- (어쩐지 불여우에서는 가끔 내 홈피가 이상한 문자로 나오더라니.. )

세번째로는 조엘 테스트..
12개 항목 중.. 7점 정도~~

10점 이하는 심각하다고 하니.. 쩝~~ 심각한 편이네요 -.-
참고로 12개 항목은 다음과 같습니다.

1. 소스코드 관리시스템을 사용하고 있습니까?
2. 한방에 빌드를 만들어 낼 수 있습니까?
3. 일일 빌드를 하고 있습니까?
4. 버그 추적시스템을 운영하고 있습니까?
5. 코드를 새로 작성하기 전에 버그를 수정합니까?
6. 일정을 업데이트하고 있습니까?
7. 명세서를 작성하고 있습니까?
8. 조용한 작업 환경에서 일하고 있습니까?
9. 경제적인 범위 내에서 최고 성능의 도구를 사용하고 있습니까?
10. 테스터를 별도로 두고 있습니까?
11. 프로그래머 채용 인터뷰 때 코딩 테스트를 합니까?
12. 무작위 사용편의성 테스트를 수행하고 있습니까?


그외에도..
닭이 먼저냐 달걀이 먼저냐~ 하는 부분에 대한 이야기~~
마이크로소프트의 API 전쟁 관련 이야기에서의 하위 호환성 문제...
성과급이나 측정이 오히려 해가 된다는 이야기 ~~ (역시 공감.. ㅋㅋㅋ)
종이 프로토타이핑.. (음.. 어떤 교수님이 프로그래밍에서 손뮬레이션이 중요하다고 하셨는데.. 일맥상통)

그러나.. 설계를 최대한 늦춰야 한다는 부분은 XP하고도 약간 상충된다고 나와있는데요..
제 경험상으로는 XP식으로 빠른 개발을 들어가는 것이 설계를 늦추는 것보다 낫기는 했는데~~
설계문서로 버그를 줄일 수 있다면, 조엘의 방식이 맞을 수 있겠으나~~
추상화된 설계를 보고 버그를 찾아낼 수 있는 사람이 과연 몇이나 될까요??
그래서 전 빠른 설계.. 빠른 수행.. 그리고 반복의 XP가 더 낫다고 보네요~~




Trackback 1 And Comment 2
prev | 1 | next