(1) 소개: 본 문서를 작성하는 목적을 설명합니다. 프로젝트의 이름과 배경 이 문서에 사용된 기술 용어 및 참고 문헌.

(2) 타당성 조사 전제 조건: 타당성 조사 전제 조건. 개발 프로젝트의 기능, 성능 및 기본 요구 사항을 설명하십시오. 달성된 목표 다양한 제한 사항 실현가능성 연구 방법 및 실현 가능성을 결정하는 주요 요인.

(3) 기존 시스템 분석: 기존 시스템의 프로세스 및 데이터 프로세스를 설명합니다. 작업량 각종 비용 필요한 전문 기술 인력의 수; 필요한 다양한 장비; 기존 제도에 무슨 문제가 있습니까?

(4) 제안된 시스템의 기술적 타당성 분석: 제안된 시스템에 대한 간략한 설명 프로세스 및 데이터 프로세스 처리 기존 시스템에 비해 이점 제안 된 시스템의 사용이 사용자에게 미치는 영향; 다양한 장비, 기존 소프트웨어, 개발 환경 및 운영 환경에 미치는 영향 지출에 미치는 영향 기술 타당성 평가.

(5) 제안 시스템의 경제적 타당성 분석: 제안 시스템의 다양한 지출 및 이점을 설명하십시오. 소득 투자 비율 투자 회수 주기.

(6) 사회적 요인 타당성 분석: 법적 요소를 설명하고 계약 책임, 특허 침해, 저작권 침해 등의 문제를 분석합니다. 사용자 사용의 타당성이 사용자 행정관리, 근무제도, 인력 자질의 요구 사항을 충족하는지 설명합니다.

(7) 기타 대체구성: 다른 대체구성을 하나씩 설명하고 추천되지 않은 이유를 설명합니다.

(8) 결론: 프로젝트가 개발될 수 있는지 여부를 설명한다. 발전하기 위해서는 어떤 조건이 필요합니까? 프로젝트 목표에 어떤 변화가 있는지 등.

[분석] 소프트웨어 실현가능성 연구의 목적은 소프트웨어 프로젝트를 개발할 수 있는지, 개발할 가치가 있는지, 최소한의 비용으로 가장 짧은 시간 내에 문제를 해결할 수 있는지 여부를 결정하는 것이다. 보고서는 8 가지 기본 내용으로 나뉜다.

시스템 설계의 내용은 무엇입니까?

해결 방법: 시스템 설계 단계에서는 맨 위에서 시작하여 미세 조정합니다. 시스템 설계는 전반적인 구조와 스타일을 결정하고 사후 설계 단계에서 보다 상세한 전략 설계의 기초를 제공합니다.

(1) 시스템 분해. 시스템의 주요 구성 요소는 하위 시스템이라고 하며 객체 또는 함수가 아니라 클래스, 연관, 작업, 시간 및 제약 조건의 모음입니다. 한 번에 분해되는 하위 시스템의 수는 너무 많아서는 안 되며, 가장 낮은 하위 시스템을 모듈이라고 합니다.

(2) 동시성을 결정합니다. 분석 모델, 실제 및 하드웨어의 많은 객체가 동시에 발생합니다. 시스템 설계의 중요한 목표 중 하나는 동시에 작동해야 하는 객체와 그렇지 않은 객체를 결정하는 것입니다. 후자는 함께 배치하여 단일 제어선 또는 작업에 통합할 수 있습니다.

(3) 프로세서 및 임무 할당. 각 동시 하위 시스템은 단일 하드웨어 단위, 범용 프로세서 또는 특정 기능 단위에 할당되어야 하며, 성능 요구 사항 및 리소스 요구 사항 추정, 하위 시스템을 구현하는 하드웨어 및 소프트웨어 선택, 각 프로세서에 소프트웨어 하위 시스템 할당, 성능 요구 사항 충족 및 프로세서 간 통신 최소화, 각 하위 시스템의 각 물리적 단위 연결 결정 등의 작업을 수행해야 합니다.

(4) 데이터 저장소 관리. 시스템 내부 데이터와 외부 데이터의 저장 및 관리는 중요한 작업입니다. 일반적으로 각 데이터 저장소는 데이터 구조, 파일 및 데이터베이스를 결합할 수 있으며, 서로 다른 데이터 저장소는 비용, 액세스 시간, 용량 및 안정성 간에 절충되어야 합니다.

(5) 글로벌 자원 처리. 글로벌 자원을 결정해야 하며 글로벌 자원을 확보하기 위한 전략을 세워야 합니다. 글로벌 리소스에는 프로세서 및 드라이브와 같은 물리적 리소스가 포함됩니다. 디스크 공간 및 워크스테이션 화면과 같은 공간 객체 식별자, 클래스 이름, 파일 이름 등과 같은 논리적 이름입니다.

자원이 물리적 객체인 경우 프로토콜을 설정하여 동시 시스템에 액세스하여 자율적으로 제어할 수 있습니다. 리소스가 객체 식별자와 같은 논리적 엔티티인 경우 공유 환경에서 액세스 충돌이 발생할 수 있습니다. 예를 들어 독립 트랜잭션에서 동일한 객체 식별자를 동시에 사용할 수 있는 경우 각 전역 자원에는 보호 객체가 있어야 하며 보호 객체는 해당 자원에 대한 액세스를 제어합니다.

(6) 소프트웨어 제어 메커니즘을 선택합니다. 해석 모델의 모든 상호 작용은 객체 간의 이벤트로 표시됩니다. 시스템 설계는 소프트웨어 제어를 위해 여러 가지 방법 중 하나를 선택해야 합니다.

(7) 인간-기계 인터페이스 설계. 설계에서 대부분의 작업은 정상 상태 동작과 관련이 있지만 시스템 상호 작용 인터페이스의 사용자 사용을 고려해야 합니다.

[분석] 시스템 설계는 문제 해결 및 솔루션 구축을 위한 고급 전략입니다. 이 문제를 해결할 기본 방법을 찾아야 한다. 시스템의 상위 계층 구조에는 하위 시스템의 분해, 고유의 동시성, 하위 시스템의 하드웨어 및 소프트웨어 할당, 데이터 스토리지 관리, 자원 조정, 소프트웨어 제어 구현, 인간-컴퓨터 상호 작용 인터페이스가 포함됩니다.

소프트웨어 위기란 무엇입니까? 소프트웨어 위기의 성과는 무엇입니까? 그 이유는 무엇입니까?

해결 방법: 소프트웨어 개발의 두 번째 단계 후반에 컴퓨터 하드웨어 기술의 발전으로 컴퓨터의 속도, 용량 및 안정성이 크게 향상되었으며 생산 비용이 크게 낮아져 컴퓨터의 광범위한 응용을위한 조건을 만들었습니다. 몇몇 복잡한 대형 소프트웨어 개발 프로젝트가 제기되었지만, 소프트웨어 개발 기술의 진보는 더 이상 발전의 요구를 충족시킬 수 없다. 소프트웨어 개발에서 직면한 문제는 해결되지 않아 문제가 쌓일수록 첨예한 갈등이 생겨 소프트웨어 위기를 초래하고 있다. (윌리엄 셰익스피어, 윈스턴, 소프트웨어, 소프트웨어, 소프트웨어, 소프트웨어, 소프트웨어, 소프트웨어, 소프트웨어, 소프트웨어)

소프트웨어 위기는 다음 네 가지 측면에서 나타납니다.

(1) 예산이 자주 초과되어 완료 시간이 계속 지연됩니다. 소프트웨어 개발 경험과 소프트웨어 개발 데이터의 축적이 부족해 개발 계획을 세우기가 어렵다. 주관적으로 맹목적으로 계획을 세우는데, 실행과 실제 상황의 차이가 커서, 발전 자금이 한 번에 한 번 돌파하게 되었다. 업무량과 개발의 난이도를 과소평가하여 진도를 제때에 완성할 수 없어 개발 시간이 거듭 지연되었다.

(2) 개발 된 소프트웨어는 사용자의 요구 사항을 충족시킬 수 없습니다. 개발 초기에는 사용자의 요구에 대한 명확한 이해가 없어 명확하게 표현할 수 없었다. 개발 작업이 시작된 후, 소프트웨어 인력과 사용자가 적시에 의견을 교환하지 못해 일부 문제가 제때에 해결되지 않아 개발된 소프트웨어가 사용자의 요구 사항을 충족하지 못해 개발에 실패하게 되었습니다.

(3) 개발 된 소프트웨어의 서비스 용이성이 열악합니다. 개발 과정에서 만장일치로 인정된 규범은 없다. 소프트웨어 개발자는 자체 스타일에 따라 작동하며 개발 과정에서 완전한 사양의 문서가 없습니다. 문제를 발견하면 마구 수정하다. 프로그램 구조가 좋지 않아 실행 중 발견된 오류를 수정하기 어려워 서비스 용이성이 떨어진다.

(4) 개발 된 소프트웨어의 신뢰성이 떨어집니다. 개발 과정에서 소프트웨어 품질을 보장하는 제도와 조치가 없기 때문에, 소프트웨어 테스트에는 엄격하고 충분하며 완전한 테스트가 없으며, 사용자에게 제출된 소프트웨어의 품질이 좋지 않아 운영중에 대량의 문제가 드러났다.

소프트웨어 위기의 원인은 다음과 같습니다.

(1) 소프트웨어의 규모가 점점 커지고 구조가 점점 복잡해지고 있습니다.

(2) 소프트웨어 개발 관리가 어렵고 복잡합니다.

(3) 소프트웨어 개발 비용이 증가하고 있습니다.

(4) 소프트웨어 개발 기술이 낙후되다.

(5) 낙후된 생산 방식.

(6) 개발 도구가 낙후되어 생산성 향상이 느리다.

소프트웨어 위기의 출현으로 사람들은 엔지니어링 아이디어로 소프트웨어를 개발하기 시작했고, 그 이후로 소프트웨어 생산은 소프트웨어 엔지니어링 시대로 접어들었다.

소프트웨어 품질 보증은 어떤 측면을 잘 해야 합니까?

해결책: 소프트웨어 품질 보증은 소프트웨어 엔지니어링 관리의 중요한 부분이며 소프트웨어 품질 보증에서 다음과 같은 작업을 수행해야 합니다.

(1) 기술적 수단과 도구를 사용합니다. 개발 프로세스를 수행하기 위해서는 품질 보증 활동이 기술적 수단과 도구, 특히 소프트웨어 개발 환경을 채택해야 합니다.

(2) 공식 기술 검토를 조직하십시오. 소프트웨어 개발의 각 단계가 끝나면 공식적인 기술 검토를 조직해야 합니다. 국가 표준은 각 부서가 심사, 문서 심사, 설계 심사, 심사 및 테스트와 같은 구체적인 수단을 취하여 품질을 보장할 것을 요구한다.

(3) 소프트웨어 테스트를 강화합니다. 소프트웨어 테스트는 품질 보증의 중요한 수단입니다. 테스트에서 소프트웨어의 잠재적 오류를 대부분 발견할 수 있기 때문입니다.

(4) 소프트웨어 엔지니어링 사양 (표준) 을 구현하십시오. 사용자는 자신의 소프트웨어 엔지니어링 사양 (표준) 을 개발할 수 있지만 표준이 확인되면 시행해야 합니다.

(5) 제어 소프트웨어의 변화. 소프트웨어 수정 및 변경으로 인해 잠재적 오류가 발생하는 경우가 많기 때문에 소프트웨어 수정 및 변경을 엄격하게 통제해야 합니다.

(6) 소프트웨어 품질 측정. 즉, 소프트웨어 품질을 추적하고, 적시에 소프트웨어 품질을 기록하고 보고하는 것입니다.

소프트웨어 품질 보증은 사용자와 사회에 만족스러운 고품질 제품을 제공하고, 탄생부터 소멸에 이르는 모든 단계의 소프트웨어 제품 품질을 보장하는 활동으로 소프트웨어 엔지니어링 관리의 중요한 부분입니다.