소프트웨어 개발 프로세스 관리

이런 글을 쓰는 게 너무 피곤해요. 만족하신다면 받아주세요. 감사합니다

남쪽의 소프트웨어 프로세스 관리에 대한 간략한 토론

"어디로 가는지 모르면 어떤 길이든 선택할 수 있습니다. 모르면 아무 길이나 선택할 수 있습니다." 당신이 있는 곳은 지도 쓸모가 없습니다." 이것은 "소프트웨어 프로세스 관리"의 첫 문장입니다. 더 깊은 의미는 모든 것은 발전의 방향이 있고, 발전하도록 놔두기보다는 유리한 방향으로 발전할 수 있도록 조절을 잘해야 한다는 것입니다. 또 다른 문장은 사물의 발전 방향을 알려면 사물의 상태도 알아야 도구와 지혜를 사용하여 올바른 개발 프로세스를 안내할 수 있다는 것입니다. 거의 10년 동안 소프트웨어를 개발한 후, 나는 종종 소프트웨어 개발의 복잡한 과정에서 길을 잃곤 합니다. 나는 항상 지혜로 인도하는 넓은 길이 있다고 생각합니다. 그러나 검색해 보면 아직 그 길을 제대로 찾지 못한 것 같습니다.

최근 몇 년 동안 Southern Software의 개발을 주의 깊게 관찰하면 우리가 개선하기 위해 열심히 노력해 온 것이 소프트웨어 개발 및 프로세스 관리 모델이라는 것을 알게 될 것입니다. 소프트웨어 개발 프로세스를 구축하든, ISO를 구현하든, 이는 모두 우리 소프트웨어의 품질을 향상시키고 개발 및 마케팅 업무를 보다 합리적이고 과학적으로 만들기 위한 것입니다.

여기에서는 소프트웨어 개발 과정에 대한 나의 견해와 생각을 간략하게 공유하고 싶습니다. 우리가 일반적으로 이야기하는 소프트웨어 개발은 ​​실제로 개발 프로세스와 관리 프로세스라는 두 가지 프로세스로 구성됩니다. 소프트웨어 엔지니어링의 전통적인 아이디어는 엔지니어링 아이디어를 기반으로 소프트웨어를 개발하는 것입니다. , 그리고 최종적으로 모두가 함께 이해할 수 있는 요구사항 분석 문서를 도출하고, 디자인, 코딩, 테스트 등 다양한 단계로 원활하게 전환하는 방법을 도출합니다. 이러한 프로세스에는 해당 방법, 모델 및 도구가 있습니다. 그러나 공학적 사고에만 의존하는 것만으로는 소프트웨어 개발 과정의 모든 문제를 해결할 수 없습니다. 기술이 발전함에 따라 소프트웨어의 복잡성은 점점 더 높아지고, 개발 과정에서 협업하는 사람들도 점점 더 어려워지고 있습니다. 이로 인해 소프트웨어 관리 프로세스가 발생합니다. 우리는 모두 함께 일하며 각자 다른 삶의 경험과 지식 배경을 갖고 있습니다. 우리 모두는 각자의 행동 습관과 표현 방식을 가지고 있지만, 여전히 서로 소통하고 이해하고 조율해야 하기 때문에 통일된 기준과 행동 강령이 필요합니다. , 이러한 표준 및 사양은 관리 시스템, 관리 기관 및 관리 프로세스를 파생시킵니다. 위의 관리 프로세스를 통해 우리는 소프트웨어 개발 관리 프로세스를 계획합니다. 여러 사람이 동일한 프로젝트를 개발하는 경우 프로젝트 요구 사항, 내용, 작업, 최종 목표 및 시간 제한 등에 대해 동일한 이해가 있어야 합니다. 통합된 기술 사양과 표준 프로세스를 사용하여 협력합니다.

소프트웨어 개발 프로세스를 구현하는 현재 목표는 표준 프로세스를 확립하고 이 표준을 지속적으로 개선하여 이 표준 프로세스가 향후 소프트웨어 개발 작업의 품질과 효율성을 향상시킬 수 있도록 하는 것입니다. 효율성 향상이라는 목적을 달성하는 것입니다. 나는 마 회장이 2006년 말 수출입부에 대해 설명하면서 “수출입부 직원 몇 명이 1년에 이렇게 많은 생산량을 생산할 수 있다”고 했던 말을 아직도 기억한다. 이것이 바로 남부인들이 추구해야 할 목표인 고효율이며, 우리 소프트웨어인들이 추구해야 할 목표이기도 합니다. 이쯤 되면 우리가 어디로 가는지 이해가 될 것 같습니다. 그럼 어떻게 해야 할까요? 소프트웨어 프로세스 관리의 현황과 앞으로 해야 할 작업을 분석해 보겠습니다. 나는 다음 네 가지 측면에 더 많은 관심을 기울입니다.

첫째, 수요관리입니다. 요구사항은 끊임없이 변화하고 있으며, 소프트웨어 엔지니어링의 폭포수 모델이 현재 소프트웨어 개발에 적응하기 어렵게 만드는 것은 바로 이러한 변화하는 요구사항입니다. 수요 관리의 첫 번째 목표는 변화하는 수요를 제어하고, 보다 안정적인 부품 개발의 우선순위를 정하며, 반복적인 개발 프로세스를 통해 수요 변화의 위험과 영향을 줄이는 것입니다. 또 다른 목표는 개발 프로세스를 시스템 요구 사항에 맞추는 것입니다. 이는 요구사항 추적 시트 또는 추적 매트릭스를 사용하여 수행할 수 있습니다.

간단히 말하면, 실현해야 할 요구 사항을 적는 목록을 만들고, 모든 사람의 작업을 정기적으로 확인하여 소프트웨어에서 요구하는 작업을 수행하고 있는지 확인하고, 요구 사항 추적표와 비교하여 누락된 작업이 있는지 확인합니다.

둘째, 프로젝트 계획입니다. 우리는 많은 프로젝트 계획을 세웠고 그 중 일부는 상당히 훌륭했습니다. 프로젝트 기획의 목적은 참여자들의 업무를 조정하기 위한 합리적이고 실행 가능한 계획을 수립하는 것입니다. 계획할 때는 먼저 프로젝트의 범위, 규모, 작업량을 추정해야 합니다. 범위 추정은 WBS 분해 기능을 사용하여 수행할 수 있습니다. 규모 추정은 WBS 결과를 기반으로 하여 각 구성원이 다양한 기능 모듈 또는 구성 요소에 필요한 코드 줄 수 또는 클래스, 개체 수 등을 추정할 수 있도록 합니다. 프로젝트 관리자는 각 추정 결과를 설정합니다. 각 프로젝트에 대한 구성원의 친밀도 계수를 가중평균으로 사용합니다. 노력 추정은 규모 추정 결과를 사람/일 또는 사람/월로 대체하는 것입니다. 마친 후에는 WBS 작업을 세분화하고 프로젝트에 필요한 시간에 따라 작업량을 간트 차트에 정리하면 됩니다. 프로젝트 경험이 축적되면 계획의 정확성이 향상되며, 더 많은 계획을 세울수록 경험이 풍부해지고 정확성도 높아집니다.

셋째, 프로젝트 추적입니다. 우리의 프로젝트 추적은 주로 주간 기록과 로그를 기반으로 합니다. 주간 로그를 통해 프로젝트의 상태가 정상인지 확인할 수 있습니다. 로그를 통해 프로젝트의 실제 작업량과 주요 비용을 계산할 수 있습니다. 프로젝트 추적 측면에서 우리는 많은 데이터를 수집했으며 이 데이터를 사용하여 이후 프로세스를 개선하여 프로젝트 계획 및 위험 예측의 정확성을 높일 수 있습니다. 프로젝트 추적의 또 다른 기능은 프로젝트 관리자가 프로젝트 계획을 추적 결과와 비교할 수 있다는 것입니다. 실제 작업이 계획에서 심각하게 벗어난 것이 발견되면 시기적절하게 계획에 대한 일부 시정 조치 또는 변경을 취할 수 있습니다. 모든 사람의 작업을 다시 조정하고 동기화할 수 있습니다.

넷째, 구성 관리입니다. 구성 관리는 버전 관리, 구성 제어, 변경 관리, 문제 추적의 네 부분으로 구성됩니다. 버전 관리는 소프트웨어를 구성하는 다양한 파일의 기록 버전을 관리하므로 실수로 파일을 수정하더라도 이전 버전을 복원할 수 있습니다. 버전 관리 측면에서는 일부 관리 도구를 오랫동안 사용해 왔기 때문에 코드 관리가 매우 좋습니다. 우리는 현재 구성 제어, 변경 관리 및 문제 추적을 위한 솔루션을 계획하고 구축하고 있습니다. 구성 제어는 단순히 동일한 소프트웨어입니다. 사용자 정의 및 업그레이드 요구 사항이 다르기 때문에 다른 구성 방법이 필요합니다. 예를 들어, 베이징의 XX 소프트웨어 고객은 XX 베이징 버전이라고 하는 특별한 기능을 요청합니다. 상하이의 고객은 이 기능을 원하지 않지만 동시에 XX 상하이 버전이라고 하는 다른 기능을 추가하고 싶어합니다. XX 소프트웨어는 지속적으로 업그레이드되어야 합니다. 이것들은 모두 다양한 버전의 XX 소프트웨어를 기반으로 합니다. 이렇게 다양한 버전을 관리하는 방법은 무엇입니까? 구성 관리는 XX 소프트웨어의 파일 라이브러리에서 베이징 버전에서 어떤 파일과 버전이 사용되는지, 상하이 버전에서 어떤 파일과 버전이 사용되는지, 업그레이드 버전에서 어떤 버전이 사용되는지 식별하는 것입니다. 이러한 방식으로 우리는 소프트웨어 제공, 복원 및 유지 관리를 용이하게 하기 위해 요구 사항에 따라 다양한 버전의 소프트웨어를 구성할 수 있습니다. 앞서 요구사항이 수시로 변경된다고 말씀드렸습니다. 실제로 소프트웨어 개발에서는 요구사항뿐만 아니라 디자인과 코드도 변경됩니다. 소위 변경 관리란 변경이 발생할 때 적절한 처리 프로세스를 갖추고 상황에 따라 다른 처리 방법과 승인 수준을 사용하는 것을 의미합니다. 소프트웨어 변경을 막을 수는 없으므로 이러한 변경을 제어하고 변경이 소프트웨어 품질 및 프로젝트 구현에 미치는 부정적인 영향을 최소화하는 방법을 찾아야 합니다. 이슈 추적은 가장 가벼운 프로젝트 추적으로 볼 수 있습니다. 변경 요청이 승인되거나 소프트웨어 결함이 발견되면 이를 해결할 사람, 언제 해결될 것인지, 어떤 검토 방법을 사용할 것인지, 결과에 대한 상태 기록 등이 간단한 문제 추적 프로세스로 구성됩니다. .

위는 소프트웨어 프로세스 관리에 대한 몇 가지 관점입니다. 소프트웨어 개발 프로세스에는 요구사항 분석 방법, 소프트웨어 설계 방법, 테스트 방법 등이 있습니다. 이러한 방법을 올바르게 사용하면 특정 수준에서 소프트웨어 품질과 개발 효율성을 향상시킬 수 있습니다. 소프트웨어 개발 프로세스와 관련하여 우리 회사에는 권위 있는 기술 전문가가 많이 있으므로 여기서는 자세히 설명하지 않겠습니다.

목표를 설정하고 올바른 방향을 찾으십시오. 남쪽 사람들의 공동 노력으로 남쪽의 소프트웨어가 점점 더 좋아질 것이라고 굳게 믿습니다!