소프트웨어 공학

  • BOUNDED CONTEXT

    세포가 생존할 수 있는 것은 세포막에서 세포의 내부에 존재할 수 있는 것과 외부에 존재해야 하는 것을 정의하고 어떤 물질이 세포막을 통과할 수 있는지를 결정하기 때문이다. 규모가 큰 프로젝트에는 다수의 모델이 공존하며, 많은 경우 다수의 모듈을 토대로 작업을 순조롭게 진행할 수 […]
  • 도시 목록에서 화물의 목적지를 선택하는 것과 같이 간단한 사용자 행위를 지원하는 해운 애플리케이션에도 (1) 위젯을 화면에 그리고 (2) 선택 가능한 모든 도시 목록을 데이터베이스에서 조회하며 (3) 사용자가 입력한 내용을 해석하고 유효성을 검증하고 (4) 선택된 도시를 화물과 연결하며 (5) 변경내역을 데이터베이스에 […]
  • 위험 요소: 프로젝트 가시성의 부재 사람이 직접 의사소통 메커니즘을 수행할 때는, 프로젝트의 정보를 적절한 시기에 올바른 사람에게 전달하려면 조정을 많이 해야 합니다. 옆 자리에 앉은 개발자에게 다가가 최신 소스 코드를 공유 드라이브에 올려놨다고 말하면 좀더 효율적이긴 하겠지만, 그래도 여전히 […]
  • 품질이란 누가 보지 않을 때에도 제대로 돌아가는 걸 뜻한다 > > — 헨리 포드 프로젝트를 하다 보면 일이 꼬이기 마련입니다. 지속적인 통합을 효과적으로 실천하면 무엇이 문제인지 바로바로 알 수 있게 됩니다-개발 막바지에 아는 게 아니구요, 지속적인 통합은 위험 요소가 […]
  • 7대 낭비

    린 제조lean manufacturing를 공부한 사람이라면 누구나 신고 시게오(新郷 重雄)의 제조 7대 낭비를 배웠을 것이다.[^10] 이 책보다 앞서 낸 책에서, 우리는 이러한 7대 낭비를 소프트웨어 개발 7대 낭비로 옮겼었다. 이 절에서 그 내용을 다시 한번 살펴보자. 표 4.1을 보면 앞의 책과 […]
  • 만약 우리가 소프트웨어 개발에서 발생하는 낭비의 근본 원인을 찾는다고 하면, 복잡도가 정말 좋은 후보가 될 것이다. 복잡도는 우리의 코드를 경화시켜서 깨지기 쉽게 만든다. 『Conquering Complexity in Your Business』에서 마이클 조지Michael George는 복잡성이 콜레스테롤과 같다고 이야기한다. 다시 말해서 복잡성이 조직의 동맥을 […]
  • 어떤 사람은 체계와 창의력을 기묘한 단짝이라 칭했다. 두 단어가 우리 마음속에 완전히 다른 이미지를 떠올리기 때문이다. 그런데 어떻게 두 가지를 한꺼번에 고려하란 말인가? 체계라고 하면, 한 가지 목표를 향하여 똑같은 자세로 발맞춰 행군하는 획일주의 군대가 떠오른다. 창의력이라 하면, 자기 박자에 […]
  • 더 나은 업무 배치 예제를 활용한 명세의 또 한 가지 중요한 이점은 다양한 소프트웨어 개발 활동을 짧은 반복주기에 배치할 수 있다는 것이다. 개인적인 경험과 이 책에 실린 사례를 봤을 때 스크럼을 적용하려는 팀이 겪는 가장 흔한 걸림돌은 작업을 한 […]
  • 재작업 감소 일반적으로 자주 배포할수록 피드백을 신속하게 받을 수 있어 개발팀은 좀 더 일찍 실수를 찾아 문제를 해결할 수 있다. 하지만 이터레이션을 짧게 한다고 해서 실수가 방지되는 것은 아니다. 보통 개발팀에서는 기능 하나를 구현할 때마다 서너 차례에 걸쳐 재작업하곤 […]
  • 높은 제품 품질 예제를 활용한 명세는 팀원 간의 협업을 증진하고 비즈니스 사용자의 참여를 촉진한다. 또한 개발하는 제품의 목적을 분명히 함으로써 제품의 품질 향상에 크게 이바지한다. 두 연구 사례가 이를 보여준다. 사브르 홀딩스(Sabre Holdings )의 애자일 코치인 웨스 윌리엄스(Wes Williams […]