소프트웨어 개발 및 관리의 위험을 관리하는 방법

첫째, 프로젝트 개발 계획에서 위험 관리 계획을 세워야 합니다.

둘째, 프로젝트 예산에는 위험 해결에 필요한 자금이 포함되어야 합니다.

셋째, 위험을 평가할 때 위험의 영향도 프로젝트 계획에 포함되어야 합니다.

소프트웨어 개발 과정에서 자주 발생하는 위험과 우리가 취한 예방 조치에 대해 살펴보겠습니다.

1, 요구 사항이 명확하지 않습니다

수요 모호성은 소프트웨어 개발 과정에서 흔히 볼 수 있는 문제로, 수요 범위가 불분명하고, 수요가 불분명하며, 수요 묘사가 불분명하며, 수요 부족, 수요 갈등 등 여러 가지 측면을 나타내는 경우가 많습니다. 소프트웨어 개발 프로세스 수명 주기의 모든 단계에서 수요가 명확하지 않은 낭비가 가장 크며 가능한 한 빨리 해결해야 합니다. 사용자의 요구를 파악하는 것은 매우 어렵습니다. Dell 은 다음과 같은 측면에서 요구 사항이 명확하지 않은 문제를 처리하는 경우가 많습니다.

(1) 사용자가 개발에 참여하도록 합니다.

사용자가 개발 프로세스에 참여할 수 있도록 공동 개발 환경을 제공합니다. 조건이 허용되지 않는 경우 최소한 각 반복의 요구 사항 분석 및 시스템 테스트 단계에서 고객이 개발에 참여할 수 있도록 허용해야 합니다.

개발 프로세스에 참여할 사용자를 선택할 때 비즈니스 또는 컴퓨터 기술에 정통한 사용자 참여를 위해 최선을 다해야 합니다. 반면, 개발 중인 제품이 다양한 규모와 유형의 기업에 적용되어야 하는 경우 대표적인 사용자 참여를 선택해야 합니다.

사용자를 참여시키는 것만으로는 충분하지 않습니다. 사용자의 적극성을 높이기 위해 인센티브를 취해야 합니다.

(2) 사용자 인터페이스 프로토 타입 개발

사용자는 일반적으로 비즈니스 요구 사항을 정확하게 설명하지 못하며, 시스템 분석가는 화이트보드, 백지 등의 의사 소통 방식을 사용하여 사용자가 요구 사항을 명확하게 표현할 수 있도록 해야 합니다. 그런 다음 사용자가 요구 사항을 확인할 수 있도록 프로토타입 사용자 인터페이스를 개발합니다. 사용자 인터페이스 프로토타입의 역할은 사용자의 요구를 수집하는 것일 뿐, 다른 용도로 사용해서는 안 되며, 사용자 시스템이 곧 실현될 것이라는 착각을 주어서는 안 된다.

(3) 수요 세미나

사용자 분포가 광범위하고 사용자 수가 많은 프로젝트의 경우 사용자 요구 사항을 완전히 수집하기가 어려울 수 있으며, 일반적으로 요구 사항 연구회를 사용하여 요구 사항을 확인합니다. 회의 몇 주 전에 각 부서의 사용자 요구 사항에 대한 의견을 조사한 다음 각 지역 또는 각 부서의 사용자 대표를 소집하여 요구 사항 워크숍을 열고 회의를 통해 요구 사항을 수집합니다. 이 방법은 특정 정보 시스템 사용 경험이 있는 사용자에게 적합합니다.

(4) 수요 분석 및 검토를 강화한다.

첫째, 수요 분석은 프로젝트 성공의 기초이며 충분한 시간과 인력을 할당하기에 충분한 주의를 기울여야 합니다. 경험 있는 시스템 분석가는 책임져야 하고 초보자나 프로그래머는 책임져서는 안 된다. 둘째, 요구 사항 검토를 수행하고, 가능한 한 사용자를 요구 사항 검토에 참여시키고, 요구 사항 검토가 형식에 흐르지 않도록 해야 합니다. 셋째, 가장 중요한 점으로, 심사를 통과한 수요설명서를 통해 사용자 서명이 있어야 하며, 프로젝트 계약의 첨부 파일이 되어 쌍방에 구속력이 있어야 합니다. 회사 내에서 검토를 통과한 요구 사항 사양은 구성 관리에 포함되어야 합니다.

이 프로젝트는 인지도가 부족하다.

프로젝트 관리자 또는 개발자가 작업의 80% 를 완료했다고 말할 때 신중해야 합니다. 나머지 20% 는 시간의 80% 를 차지할 수 있기 때문에 [1] 을 (를) 완성하지 못할 수도 있습니다. 소프트웨어 개발 프로젝트는 일반적으로 프로젝트 진행 및 소프트웨어 품질에 대한 가시성이 부족합니다. 항목의 가시성이 낮을수록 통제하기가 더 어렵고 실패할 가능성이 높다. Dell 은 반복 개발, 기술 검토 및 지속적인 통합을 통해 프로젝트 가시성을 높일 수 있습니다.

(1) 반복 개발

반복 개발 모델을 사용하여 제품 제공 프로세스를 여러 단계로 나누어 기능에 따라 증분 방식으로 제품을 제공합니다. 다음은 몇 가지 일반적인 반복입니다.

규모와 전망을 수립하고 비즈니스 원인에 대한 단기 사전 반복을 결정합니다.

안정된 프레임에 대한 기준선을 그리는 반복을 정련합니다.

구축 반복, 이 기간 동안 사용 사례가 구현되고 아키텍처가 풍부해질 것입니다.

몇 차례의 제품화 반복으로 제품을 사용자 기반으로 옮기다.

매번 반복될 때마다 사용자의 의견을 충분히 받고 자가 수정을 해야 한다. 점진적 기능 전달은 개발자의 부담을 줄이고 사용자 만족도를 높이며 프로젝트 가시성을 향상시키는 데 도움이 되는 최고의 진행 보고서입니다.

(2) 기술 검토

기술 검토는 소프트웨어 품질을 보장하는 중요한 부분입니다. 기술 검토에는 코드 연습, 회의 검토 및 동료 전문가 검토가 포함됩니다. 코드 검토는 개발자 간의 교차 평가이거나 일반 개발자에 대한 선임 개발자의 평가일 수 있습니다. 일반적으로 2 주마다 적어도 한 번씩 회의 심사를 진행하며, 매번 심사 시간이 너무 길어서는 안 된다. 동행전문가 심사에는 기술 전문가와 업무 전문가가 모두 포함되며, 정기적으로 업무를 아는 사용자 전문가를 프로젝트 심사에 참여시키는 것은 프로젝트 성공의 중요한 보증이다.

또한 품질 검토를 위한 도구 소프트웨어를 최대한 활용하는 것도 코드 품질을 향상시키는 데 도움이 됩니다. 예를 들어 Eclipse 개발 환경에서는 Findbug, Checkstyle 및 PMD 플러그인을 통합하여 코드 작성의 품질을 확인할 수 있습니다.

(3) 지속적인 통합

지속적인 통합은 최종 대규모 통합 디버깅 프로세스를 매주, 매일 또는 매시간 프로젝트 개발 일정에 배포할 수 있습니다. 프로젝트의 모든 직원이 현재 전체 진행 상황을 적시에 파악하고 통합 프로세스 중 문제를 신속하게 파악하고 해결할 수 있도록 합니다 [1].

개발팀은 지속적으로 통합된 시스템을 개발해야 한다. 일반적으로 야간 빌드에서는 Ant 및 기타 빌드 도구를 사용하여 Java 응용 프로그램을 빌드할 수 있습니다. 팀 구성원은 각 기능 개발이 완료된 후 즉시 CVS 와 같은 버전 제어 시스템에 코드를 제출해야 하며, 문제가 있는 코드 (컴파일 실패) 는 버전 제어 시스템에 제출하면 안 됩니다.

야간 구축 및 지속적인 통합을 통해 프로젝트 진행 상황을 쉽게 추적할 수 있습니다. 프로젝트 팀이 매일 시스템을 재컴파일할 때, 완성된 기능과 완료되지 않은 기능이 분명하게 드러나고, 팀 구성원은 소프트웨어의 성능에서도 전체 완료까지 얼마나 남았는지 쉽게 알 수 있다.

3. 신기술 도입

기술 혁신은 일종의 탐구적이고 창조적인 기술 경제 활동이다. 개발 과정에서 신기술을 도입하면 각종 위험에 부닥칠 수밖에 없다. 신기술의 위험은 T 형 소프트웨어 개발, 충분한 논증, 다단계 평가 및 동료 경험을 통해 줄일 수 있습니다.

(1) T 형 소프트웨어 개발

프로젝트 개발 전, 개발팀은 시스템 아키텍처를 구축하고, 주요 기술 문제를 해결하고, 시스템의 기본 구성 요소를 개발하고, 시스템이 적용해야 할 기술에 대해 심도 있게 탐구해야 한다. 예를 들어, JavaEE5 를 기반으로 분산 트랜잭션 처리, 대용량 데이터 저장소, 이기종 플랫폼 상호 연결 등의 주요 문제를 다루는 전국 온라인 발권 시스템을 구축했습니다. , 우선 순위를 부여해야합니다; 개발 관련 기술 (예: EJB3, JSF, JBoss Seam, Eclipse RCP 등) 은 심층적인 논의가 필요합니다.

프로젝트가 기술적으로 복잡할수록 기술 문제는 더 빨리 해결해야 한다. 프로젝트 개발 중후반에 아키텍처 문제가 있거나 주요 기술 문제를 해결할 수 없는 것으로 밝혀지면 너무 늦을 것이다.

(2) 충분한 논증

신기술 개발은 탐구성이 강한 작업이며 잠재적인 실패 위험이 많다. 실현가능성 분석 단계에서는 관련 자료를 광범위하게 수집하고, 다양한 실행 가능한 방안을 설계하고, 충분한 논증을 해야 한다. 결정을 내릴 때 정보의 양과 질은 매우 중요하다. 정보가 많을수록 정확한 결정을 내릴 수 있고 프로젝트 실패의 위험도 상대적으로 낮아진다. 반대로, 위험은 증가할 것이다.

(3) 동료 경험

신기술의 경우, 참고할 만한 경험이 없기 때문에, 탐구 과정에서 인터넷을 충분히 활용해야 하며, 동업자의 경험을 검색함으로써 종종 적은 노력으로 더 많은 일을 할 수 있다. (윌리엄 셰익스피어, 윈스턴, 과학명언) 이 평평한 세상을 최대한 활용하기 위해, 우리는 가능한 한 빨리 해결할 수 없는 문제를 방치할 수 있으며, 며칠 후에 인터넷에서 비슷한 문제에 대한 해결책이 있을 수 있다.

4, 기술 호환성 위험

하드웨어 제품, 시스템 소프트웨어 (운영 체제, 미들웨어, 데이터베이스 관리 시스템) 및 호스트 디바이스, 시스템 소프트웨어, 애플리케이션 소프트웨어 및 시스템 소프트웨어, 애플리케이션 소프트웨어 간에 호환성 문제가 있을 수 있습니다. 일반적으로 시스템 통합 프로젝트가 복잡할수록 호환성 문제가 더 쉽게 발생합니다.

(1) 설계가 우선이다

시스템의 전반적인 설계 방안을 개발할 때 관련 제품의 선택을 보장하고 네트워크, 호스트, 시스템 소프트웨어, 애플리케이션 간에 큰 기술 호환성 문제가 없도록 해야 합니다. 네트워크 플랫폼 구축 시나리오에서는 관련 장비의 기술 매개변수 및 구성 요구 사항이 명확합니다.

(2) pre-sales 제품 테스트

프로젝트를 입찰할 때 입찰자는 프로젝트 구현 중 기술 호환성 문제가 노출되지 않도록 판매 전에 제품 호환성 테스트를 제공해야 합니다. 애플리케이션 소프트웨어 개발과 관련된 통합 프로젝트의 경우, 프로젝트 개발 후 기술 호환성 문제가 노출되지 않도록 개발 작업 초기에 기술 호환성 테스트를 수행해야 합니다.

예를 들어, 심천 버스 터미널 티켓 네트워크 스케줄링 시스템을 개발할 때 기술 호환성을 보장하기 위해 하드웨어 입찰에서 소형 폼 팩터 장비 공급업체에 사전 판매 기술 호환성 테스트를 제공하고 테스트 결과를 평가 지표로 요청합니다. 심천 소프트웨어 테스트 센터에서 IBM, SUN 및 HP 가 제공하는 소형 폼 팩터를 테스트하는 동안 많은 애플리케이션 소프트웨어, 애플리케이션 서버, 데이터베이스 및 운영 체제 간의 기술 호환성 문제가 드러났습니다. 시스템 구현 중 이러한 문제가 노출되거나 처리되면 프로젝트 진행이 지연됩니다.

5. 성능 문제

초기 설계 부족으로 인해 시스템 전환 또는 신규 시스템 사용 후 성능 문제가 노출되는 경우가 많습니다. 성능 문제는 많은 최적화 작업, 심지어 부분적으로 또는 전체적으로 재설계해야 하는 경우가 많습니다. 사용자와 개발자 모두 성능 문제를 원하지 않습니다.

(1) 성과 계획

시스템을 설계할 때, 초기 성능 계획을 잘 세워서 성능 문제가 발생할 수 있는 부분을 충분히 예측해야 한다. 데이터베이스를 설계 할 때 DBA 의 참여를 위해 노력해야합니다.

또한 기술적인 접근 방식에서는 DTO, AJAX, 지연 로드 등과 같은 성능 최적화 모드를 사용해 보았습니다. , 가능한 한 개발 프로세스의 성능 문제를 해결하십시오. 프로젝트 후반이 되어서야 성능 문제를 해결할 수 있어서 비싸지도, 시간도 많이 걸리지 않을 것이다.

(2) 성능 테스트

개발 과정에서 성능 테스트와 스트레스 테스트를 중시하고, 가능한 실제 사용 환경을 시뮬레이션하고, 테스트 플랫폼을 구축해야 합니다. 또한 개발 환경의 컴퓨터는 종종 생산 환경의 구성보다 높기 때문에 구성이 낮고 네트워크 대역폭이 작은 기계를 찾아 테스트해야 합니다.

(3) 충분한 디버깅 시간

프로젝트 개발 계획에는 사후 성능 최적화를 위한 공간이 있습니다. 시스템 성능을 최적화한 후 성능 테스트 및 스트레스 테스트가 필요하며 몇 차례 회귀 테스트를 할 수 있습니다. 그래서 충분한 시간과 인력을 확보해야 한다.

6, 온라인으로 돌진

프로젝트 구현 과정에서 시스템 전환 온라인 링크가 가장 쉽게 잘못될 수 있습니다. 프로젝트가 마침내 개발되었지만 마지막 순간에 무너졌다. 프로젝트가 작으면 영향이 좁다는 것은 중요하지 않다. 영향력이 큰 프로젝트라면 문제없을 것이다. 시스템을 전환하기 전에 발생할 수 있는 모든 문제를 충분히 고려하고 위험 대책을 취해야 한다.

(1) 비상 계획

각종 예측할 수 없는 위험에 직면하여 응급계획을 잘 세워야 한다. 역 발권 시스템의 정상적인 운영은 춘윈 최고봉과 관광 골든 위크 기간 동안 비상 계획을 세울 것이다. 새 시스템이 전환될 때는 비상 계획을 세워야 한다. 비상 계획 중 최악의 계획을 잘 세워야 한다. 발권 시스템이 제대로 작동하지 않을 때 수동 발권 준비는 최악의 계획이다.

(2) 단계별 전환

위험의 영향을 줄이기 위해 시스템은 점진적으로 전환할 수 있습니다. 예를 들어, 발권 시스템이 전환될 때, 종종 새로운 시스템으로 예매권을 판매하거나, 새로운 시스템으로 장거리 역을 판매하고, 오래된 시스템으로 단거리 차표를 임시로 판매한다. 새 시스템이 안정적으로 작동한 후 완전히 새 시스템으로 전환하다. 여러 사용자 단위의 시스템 전환도 단위별로 수행할 수 있습니다.

(3) 교차 훈련

이전 시스템과 새 시스템을 전환하는 과정에서 사용자는 모두 적응을 하는 과정을 가지고 있습니다. 전환 전 운영 교육 외에 신구 시스템 전환 과정의 교차 교육도 해야 한다. 사용자가 일정 기간 앞당겨 출근하도록 하고, 아침 사용자가 중반 사용자를 교육하고, 중반 사용자가 야간 사용자를 훈련시킬 수 있도록 합니다. 교차 훈련을 잘하면 시스템을 균형 있게 전환할 수 있다.

7, 가용성 문제

소프트웨어 가용성에는 소프트웨어의 사용 효율성, 배우기, 기억하기, 즐거움, 실수 등 여러 가지 요소가 포함됩니다. 소프트웨어 가용성이 떨어지면서 사용자 불만이 발생하거나 시장에서 탈락하는 경우가 많습니다. 프로젝트 개발에서는 가용성 문제에 주의를 기울여 소프트웨어 가용성 위험을 방지해야 합니다.

(1) 사용자 이해

사용자의 작업 현장에 가서 대상 사용자가 소프트웨어를 사용하는 실제 목적을 이해하고, 사용자의 관점과 입장에서 사용자 업무 처리 프로세스에서 가장 번거롭고, 가장 쉽게 문제가 발생하거나, 대량의 반복적인 작업을 소프트웨어 시스템으로 대체하는 방법을 이해합니다. 소프트웨어가 사용자의 생산성과 효율성을 향상시킬 수 있도록 합니다. 예를 들어, 발권 시스템에서 가장 많이 사용되는 인터페이스는 발권 인터페이스이며, 열차 승무원의 가장 큰 관심사는 돈을 잘못 내지 않는 것이다 (몰수 배상이 적다). (알버트 아인슈타인, Northern Exposure (미국 TV 드라마), 스포츠명언) 따라서 외상 매출금의 전시와 변경 서체는 두드러지고 눈에 띄어야 한다. 마찬가지로 운임과 도착도 강조해야 합니다. 바로 가기 키, 1 버튼 리셋, 숫자 키패드 등을 통한 디자인. , 지휘자가 키보드를 두드리는 횟수를 최소화하십시오. 그렇지 않으면 하루 78 만 8 천 명의 대형 여객터미널에서 사용자 인터페이스가 제대로 설계되지 않으면 하루 동안 열차 승무원이 일을 하면 손가락이 무감각해질 수 있다. (데이비드 아셀, Northern Exposure (미국 TV 드라마), 여객명언)

(2) 참여 설계

사용자와 협력하여 사용자가 사용자 인터페이스의 설계, 검토 및 테스트에 참여할 수 있도록 하여 사용자가 가용성 문제를 포괄적이고 조기에 발견하고 적시에 수정할 수 있도록 합니다.

고객 설계를 시키는 대신 고객을 설계에 참여시키는 것은 프로젝트 관리자 또는 수석 디자이너가 주도해야 합니다.

(3) 경쟁력 분석

시장에 나와 있는 유사 경쟁 제품에 대한 분석이나 실험 테스트를 통해 이들 제품의 사용자 인터페이스 문제를 파악함으로써 새로운 시스템 개발에 대한 계시를 제공합니다. 경쟁 분석은 다른 사람의 디자인을 훔칠 수 있다는 것이 아니라 경쟁 제품의 장단점을 분석해 이전 디자인보다 더 잘할 수 있다는 것이다 [5].

(4) 일관성

사용자가 동일한 명령이나 동일한 조작이 항상 동일한 효과를 낼 수 있다는 것을 알고 있다면, 그들은 시스템을 사용할 때 더욱 자신감을 갖게 될 것이며, 또한 시스템의 새로운 부분을 사용하는 기본 지식 [Lewis er al. 1989] 을 이미 갖추고 있기 때문에 탐구적인 학습을 하도록 독려할 것이다.

개발팀은 회사나 팀이 제정한 사용자 인터페이스 표준을 준수해야 여러 방면에서 일관성을 유지하고 한 시스템에 여러 가지 인터페이스 스타일이 있는 것을 금지할 수 있다.

정주 관치 전자상거래, 자원 효과, 성공 사례, 제작 수준 전문, 마이크로선물 플랫폼 건설, 유통 시스템 개발, 낚시 게임 개발, 제 3 자 지불 소프트웨어 개발, 쇼핑몰 웹 사이트 건설, 전자상거래 웹 사이트 건설, 웹 사이트 맞춤형 개발, 모바일 앱 소프트웨어 개발, 위챗 애플릿 개발, 전자상거래 시스템 개발, 사무용 시스템 소프트웨어 제공 엘리트 팀이 당신의 미래를 호위합니다!

8. 결론

정보 시스템 통합 프로젝트에서는 위험이 다양하고 유비쿼터스입니다. 프로젝트 관리 활동에서 우리는 적극적으로 위험에 직면하고 위험을 키워야 한다. 위험을 빨리 식별하고 관리할수록 위험을 피하거나 위험 발생 시 영향을 줄일 가능성이 높아집니다. 특히 참여인원이 많고, 적용 범위가 넓고, 영향이 크고, 과학기술 함량이 높은 복잡한 프로젝트는 위험 관리를 강화해야 한다. 위험을 능동적으로 통제하지 않으면 위험에 직면하게 된다.