ݺߣ

ݺߣShare a Scribd company logo

소프트웨어 개발 프로세스 배경 설명

•
•
Andrew Sungjin Kim
Andrew Sungjin Kim

소프트웨어 개발이 왜 힘든지..이를 위해서 무엇이 필요한지에 대한 프로세스 배경 설명

1 of 20
Download to read offline
소프트웨어 개발 프로세스 배경 마크베이스
SWEBOK says… From www.swebok.org
소프트웨어 개발의 어려움 • 비전공자라도 누구나 개발할 수 있어 보인다. • 개발해 보면 실제로 사람마다 차이가 엄청 크다. • 유지보수가 점점 더 힘들어진다. • 같은 프로세스라도 결과가 다르다. • 개발 방법론이 수백 가지는 넘는 것 같다. • 이것 저것 해보지 않은 게 없다. • 언제나 품질 때문에 고통스럽다. (고객의 비명소리가 여기저기서 들린다.) • 아예 새로 작성하고 싶지만, 엄두가 안 난다. • 주위에 제대로 소프트웨어를 개발하는 곳도 없고, 배울 곳도 마땅치 않다.
소프트웨어 개발의 어려움 • 쓸 만 하게 키워놓으면 회사를 옮긴다. • 도대체 문서화가 되지 않는다. • 문서화가 되어도 품질이 낮거나, 유지보수가 안 된다. • 제대로 테스트를 할 수 없거나, 테스트를 해도 품질이 보장되지 않는다. • 기능을 하나 추가하면, 다른 기능이 동작하지 않는다. • 고객 마다 하나씩 버전이 존재하고, 여러 벌의 소스코드를 유지보수 해야 한다. • 개발 일정을 예측할 수 없다. • 코드가 점점 더 스파게티가 되어 간다. • 개발 경험이 조직에 습득되지 않는다.
소프트웨어 개발의 어려움 • 고객사에서 생긴 문제의 상당수를 수정할 수 없다. (재현이 불가능하거나 원인을 알 수 없다) • 개발자마다 각기 다른 스타일로 코드를 구현한다. • 언제 고객에게 전화 올지 몰라 가슴이 두근거린다.
소프트웨어 개발 프로세스의 목표
지난 시간의 시행착오와 경험 • 1999년 이후 시행착오의 연속 • 매년 새로운 시도와 조직학습의 반복 • 전혀 품질을 보증할 수 없는 수만 라인의 코드로부터 수백만 라인의 코드를 일정 품질 수준으로 관리할 수 있는 수준까지 도달 소프트웨어 개발의 멘토가 있었다면 2년 만에도 가능했을 것!
Software Triangle 프로세스 시스템사람 Good Software 채용, 훈련, 멘토링 경험, 협업… Knowledge Sharing 절차, 규약, 정책, 문서화 EPG/PAL Requirement, Bug System, Release System, QA Monitoring.. Intra Net
Triangle : 프로세스 • 하나의 업무를 달성하기 위한 단계별 행동 지침을 기술해 놓은 단위 • 개발 프로세스, 릴리즈 프로세스, 유지보수 프로세스 • 리뷰 프로세스, 코딩 룰, 릴리즈 정책… • 시사점 • 일련의 업무를 정량화된 단계를 통해 일정한 수준의 품질을 가지는 소프트웨어를 개발하자는 관점 • 매우 중요한 관점! But, 전부는 아님
Triangle : 프로세스 • Software Engineering에서 바라보는 소프트웨어의 관점 • 일정한 수준의 정량적 지표를 만족하면, 누구나 개발하더라도 일정한 수준 이상의 소프트웨어 품질이 보장된다는 공학적 접근 방식! • 그러나, 지난 30년간 공학를 통한 소프트웨어 품질향상은 크게 괄목할 만 하지 않음. • 전체가 아닌 부분이라는 관점에서 접근하는 것이 중요!! • Q) CMMI가 우리 제품의 품질을 보증할 수 있나?
Triangle : 사람 • SE에서 설명하지 못하는 부분 • Software의 복잡도가 높아질수록 공학적 효용성이 왜 떨어지는가? • 왜 동일할 프로세스를 통해서 개발을 하더라도 사람마다의 결과물이 다른가? • 균일 품질을 보장할 수 있는 개발 방법론이 존재하는가?  too many methodology • 구현 대상물의 복잡도가 증가하면 공학보다는 예술에 가까워지는 소프트웨어의 특성이 고려되어야 함
Triangle : 사람 • 훌륭한 멘토와 같이 일을 할 수 있는 환경 • 멘토 그룹의 feedback을 받을 수 있는 환경 • 깊게 문제를 고민할 수 있는 시간과 공간적 지지 필요 • 소프트웨어 개발은 생각의 크기와 깊이에 그 결과물이 달라진다는 철학적인 이해가 반드시 필요! • 좋은 인력…(누가 모르나…) • 지속적인 Training 필요
Triangle : 시스템 • 시스템  행동을 조직화 할 있는 환경 • 해당 조직이 우수한 인력, 탁월한 프로세스를 가지고 있다 하더라도 그것이 지속적으로 유지될 수 있는 환경이 없다면, 일정 시간 이후에 해당 경험들이 사라짐.  조직 경험이 남지 않음. • 업무의 시작 순간부터 마치는 순간까지 특정 환경(업무 프로세스가 자동화되도록)에서 수행, 감시, Feedback 될 수 있도록 반드시 수립해야 함.
Triangle : 시스템 • 예) 버그의 수정 • Open->Assigned->Fixing->Reviewing- >Feedback->Closing->Close • 환경 수립) 1. 버그는 반드시 버그 시스템을 사용 2. 해당 단계를 거치 않고, 다음 단계로 갈 수 없도록 3. 각 단계별로 입력해야 할 정보를 미리 정리, 부족하면 진행하지 못하도록. 4. 메일을 통해 관리자가 내용을 감시 혹은 자동화 • 조직내 관련 업무의 모든 지식이 자동으로 남게 됨  조직 학습 능력의 진화
Process for Process
PAL (Process Asset Library) • 기 정의된 제품 프로세스를 문서로 모아 놓은 라이브러리. • 기본적인 프로세스 정의 프로세스부터 세부 업무 프로세스를 차트화해서 관리 • EPG(Engineering Process Group)를 통한 프로세스 변경시 반영 및 유지 • 모든 조직 구성원들이 쉽게 찾아보고, 학습할 수 있는 공간으로서 활용. • 없다면? • 정의된 프로세스의 명문화된 저장소가 없음  모두가 암묵지화.
EPG 필요 • EPG : Engineering Process Group • 전사 프로세스를 정의하기 위한 상위 프로세스 조직 • 프로세스 Stake Holder의 대표자가 참석 • CTO, 본부장, 리더급 • 사내 프로세스 이슈에 대한 토론 및 결론 • EPG 가 없다면? • 프로세스 개선을 통한 업무 효율화를 위한 주체가 없어짐.
정책 • 특정업무의 대원칙을 기술하고, 모든 구성원들이 따라야 할 의무를 지님. •  암묵지를 형식지로 변환 • 예) • 릴리즈 정책 • 개발 정책 • 유지보수 정책
건강한 IT 조직의 조건
결론 • 프로세스 + 시스템+경험 에 집중. • 정답이 아니라, 정답을 찾아가는 경험을 공유 • 사람  정형화하기 힘든 문화적, 정서적 이슈

More Related Content

소프트웨어 개발 프로세스 배경 설명

  • 3. 소프트웨어 개발의 어려움 • 비전공자라도 누구나 개발할 수 있어 보인다. • 개발해 보면 실제로 사람마다 차이가 엄청 크다. • 유지보수가 점점 더 힘들어진다. • 같은 프로세스라도 결과가 다르다. • 개발 방법론이 수백 가지는 넘는 것 같다. • 이것 저것 해보지 않은 게 없다. • 언제나 품질 때문에 고통스럽다. (고객의 비명소리가 여기저기서 들린다.) • 아예 새로 작성하고 싶지만, 엄두가 안 난다. • 주위에 제대로 소프트웨어를 개발하는 곳도 없고, 배울 곳도 마땅치 않다.
  • 4. 소프트웨어 개발의 어려움 • 쓸 만 하게 키워놓으면 회사를 옮긴다. • 도대체 문서화가 되지 않는다. • 문서화가 되어도 품질이 낮거나, 유지보수가 안 된다. • 제대로 테스트를 할 수 없거나, 테스트를 해도 품질이 보장되지 않는다. • 기능을 하나 추가하면, 다른 기능이 동작하지 않는다. • 고객 마다 하나씩 버전이 존재하고, 여러 벌의 소스코드를 유지보수 해야 한다. • 개발 일정을 예측할 수 없다. • 코드가 점점 더 스파게티가 되어 간다. • 개발 경험이 조직에 습득되지 않는다.
  • 5. 소프트웨어 개발의 어려움 • 고객사에서 생긴 문제의 상당수를 수정할 수 없다. (재현이 불가능하거나 원인을 알 수 없다) • 개발자마다 각기 다른 스타일로 코드를 구현한다. • 언제 고객에게 전화 올지 몰라 가슴이 두근거린다.
  • 7. 지난 시간의 시행착오와 경험 • 1999년 이후 시행착오의 연속 • 매년 새로운 시도와 조직학습의 반복 • 전혀 품질을 보증할 수 없는 수만 라인의 코드로부터 수백만 라인의 코드를 일정 품질 수준으로 관리할 수 있는 수준까지 도달 소프트웨어 개발의 멘토가 있었다면 2년 만에도 가능했을 것!
  • 8. Software Triangle 프로세스 시스템사람 Good Software 채용, 훈련, 멘토링 경험, 협업… Knowledge Sharing 절차, 규약, 정책, 문서화 EPG/PAL Requirement, Bug System, Release System, QA Monitoring.. Intra Net
  • 9. Triangle : 프로세스 • 하나의 업무를 달성하기 위한 단계별 행동 지침을 기술해 놓은 단위 • 개발 프로세스, 릴리즈 프로세스, 유지보수 프로세스 • 리뷰 프로세스, 코딩 룰, 릴리즈 정책… • 시사점 • 일련의 업무를 정량화된 단계를 통해 일정한 수준의 품질을 가지는 소프트웨어를 개발하자는 관점 • 매우 중요한 관점! But, 전부는 아님
  • 10. Triangle : 프로세스 • Software Engineering에서 바라보는 소프트웨어의 관점 • 일정한 수준의 정량적 지표를 만족하면, 누구나 개발하더라도 일정한 수준 이상의 소프트웨어 품질이 보장된다는 공학적 접근 방식! • 그러나, 지난 30년간 공학를 통한 소프트웨어 품질향상은 크게 괄목할 만 하지 않음. • 전체가 아닌 부분이라는 관점에서 접근하는 것이 중요!! • Q) CMMI가 우리 제품의 품질을 보증할 수 있나?
  • 11. Triangle : 사람 • SE에서 설명하지 못하는 부분 • Software의 복잡도가 높아질수록 공학적 효용성이 왜 떨어지는가? • 왜 동일할 프로세스를 통해서 개발을 하더라도 사람마다의 결과물이 다른가? • 균일 품질을 보장할 수 있는 개발 방법론이 존재하는가?  too many methodology • 구현 대상물의 복잡도가 증가하면 공학보다는 예술에 가까워지는 소프트웨어의 특성이 고려되어야 함
  • 12. Triangle : 사람 • 훌륭한 멘토와 같이 일을 할 수 있는 환경 • 멘토 그룹의 feedback을 받을 수 있는 환경 • 깊게 문제를 고민할 수 있는 시간과 공간적 지지 필요 • 소프트웨어 개발은 생각의 크기와 깊이에 그 결과물이 달라진다는 철학적인 이해가 반드시 필요! • 좋은 인력…(누가 모르나…) • 지속적인 Training 필요
  • 13. Triangle : 시스템 • 시스템  행동을 조직화 할 있는 환경 • 해당 조직이 우수한 인력, 탁월한 프로세스를 가지고 있다 하더라도 그것이 지속적으로 유지될 수 있는 환경이 없다면, 일정 시간 이후에 해당 경험들이 사라짐.  조직 경험이 남지 않음. • 업무의 시작 순간부터 마치는 순간까지 특정 환경(업무 프로세스가 자동화되도록)에서 수행, 감시, Feedback 될 수 있도록 반드시 수립해야 함.
  • 14. Triangle : 시스템 • 예) 버그의 수정 • Open->Assigned->Fixing->Reviewing- >Feedback->Closing->Close • 환경 수립) 1. 버그는 반드시 버그 시스템을 사용 2. 해당 단계를 거치 않고, 다음 단계로 갈 수 없도록 3. 각 단계별로 입력해야 할 정보를 미리 정리, 부족하면 진행하지 못하도록. 4. 메일을 통해 관리자가 내용을 감시 혹은 자동화 • 조직내 관련 업무의 모든 지식이 자동으로 남게 됨  조직 학습 능력의 진화
  • 16. PAL (Process Asset Library) • 기 정의된 제품 프로세스를 문서로 모아 놓은 라이브러리. • 기본적인 프로세스 정의 프로세스부터 세부 업무 프로세스를 차트화해서 관리 • EPG(Engineering Process Group)를 통한 프로세스 변경시 반영 및 유지 • 모든 조직 구성원들이 쉽게 찾아보고, 학습할 수 있는 공간으로서 활용. • 없다면? • 정의된 프로세스의 명문화된 저장소가 없음  모두가 암묵지화.
  • 17. EPG 필요 • EPG : Engineering Process Group • 전사 프로세스를 정의하기 위한 상위 프로세스 조직 • 프로세스 Stake Holder의 대표자가 참석 • CTO, 본부장, 리더급 • 사내 프로세스 이슈에 대한 토론 및 결론 • EPG 가 없다면? • 프로세스 개선을 통한 업무 효율화를 위한 주체가 없어짐.
  • 18. 정책 • 특정업무의 대원칙을 기술하고, 모든 구성원들이 따라야 할 의무를 지님. •  암묵지를 형식지로 변환 • 예) • 릴리즈 정책 • 개발 정책 • 유지보수 정책
  • 20. 결론 • 프로세스 + 시스템+경험 에 집중. • 정답이 아니라, 정답을 찾아가는 경험을 공유 • 사람  정형화하기 힘든 문화적, 정서적 이슈