시스템 분석 및 설계-퀵 가이드

시스템 개발은 계획, 분석, 설계, 배포 및 유지 관리와 같은 단계를 포함하는 체계적인 프로세스입니다. 여기,이 튜토리얼에서 우리는 주로-

• 시스템 분석
• 시스템 설계

시스템 분석

사실을 수집하고 해석하고 문제를 식별하며 시스템을 구성 요소로 분해하는 프로세스입니다.

시스템 분석은 목표를 식별하기 위해 시스템 또는 그 부품을 연구 할 목적으로 수행됩니다. 시스템을 개선하고 시스템의 모든 구성 요소가 목적을 달성하기 위해 효율적으로 작동하도록 보장하는 문제 해결 기술입니다.

분석은 지정합니다 what the system should do.

시스템 설계

특정 요구 사항을 충족시키기 위해 구성 요소 또는 모듈을 정의하여 새로운 비즈니스 시스템을 계획하거나 기존 시스템을 교체하는 프로세스입니다. 계획하기 전에 이전 시스템을 철저히 이해하고 효율적으로 작동하기 위해 컴퓨터를 가장 잘 사용할 수있는 방법을 결정해야합니다.

시스템 설계는 how to accomplish the objective of the system.

시스템 분석 및 설계 (SAD)는 주로 다음에 중점을 둡니다.

• Systems
• Processes
• Technology

시스템이란?

System이라는 단어는 그리스어 Systema에서 파생되었으며, 이는 공통된 원인이나 목표를 달성하기 위해 모든 구성 요소 집합 간의 조직적인 관계를 의미합니다.

시스템은 "특정 목표를 달성하기위한 계획에 따라 서로 연결된 상호 의존적 구성 요소를 순서대로 그룹화 한 것"입니다.

시스템의 제약

시스템에는 세 가지 기본 제약이 있어야합니다.

• 시스템에는 structure and behavior 미리 정의 된 목표를 달성하도록 설계되었습니다.

• Interconnectivity 과 interdependence 시스템 구성 요소 사이에 존재해야합니다.

• 그만큼 objectives of the organization 가지고있다 higher priority 하위 시스템의 목표보다.

예를 들어 교통 관리 시스템, 급여 시스템, 자동 도서관 시스템, 인사 정보 시스템.

시스템의 속성

시스템에는 다음과 같은 속성이 있습니다.

조직

조직은 구조와 질서를 의미합니다. 미리 결정된 목표를 달성하는 데 도움이되는 구성 요소의 배열입니다.

상호 작용

구성 요소가 서로 작동하는 방식으로 정의됩니다.

예를 들어, 조직에서 구매 부서는 생산 부서와 상호 작용하고 인사 부서와 급여를 받아야합니다.

상호 의존

상호 의존성은 시스템의 구성 요소가 서로 의존하는 방식을 의미합니다. 적절한 기능을 위해 구성 요소는 지정된 계획에 따라 조정되고 함께 연결됩니다. 한 하위 시스템의 출력은 다른 하위 시스템에서 입력으로 필요합니다.

완성

통합은 시스템 구성 요소가 함께 연결되는 방식과 관련이 있습니다. 이는 각 부분이 고유 한 기능을 수행하더라도 시스템의 각 부분이 시스템 내에서 함께 작동 함을 의미합니다.

중심 목표

시스템의 목표는 중심이되어야합니다. 실제 또는 명시적일 수 있습니다. 조직이 목표를 명시하고 다른 목표를 달성하기 위해 운영하는 것은 드문 일이 아닙니다.

사용자는 성공적인 설계 및 변환을 위해 분석 초기에 컴퓨터 응용 프로그램의 주요 목적을 알아야합니다.

시스템의 요소

다음 다이어그램은 시스템의 요소를 보여줍니다-

출력 및 입력

• 시스템의 주요 목적은 사용자에게 유용한 출력을 생성하는 것입니다.

• 입력은 처리를 위해 시스템에 입력되는 정보입니다.

• 출력은 처리의 결과입니다.

프로세서

• 프로세서는 입력을 출력으로 실제 변환하는 시스템의 요소입니다.

• 시스템의 운영 구성 요소입니다. 프로세서는 출력 사양에 따라 입력을 전체적으로 또는 부분적으로 수정할 수 있습니다.

• 출력 사양이 변경되면 처리도 변경됩니다. 어떤 경우에는 프로세서가 변환을 처리 할 수 ​​있도록 입력도 수정됩니다.

제어

• 제어 요소는 시스템을 안내합니다.

• 입력, 처리 및 출력을 관리하는 활동의 패턴을 제어하는 ​​것은 의사 결정 하위 시스템입니다.

• 컴퓨터 시스템의 동작은 운영 체제와 소프트웨어에 의해 제어됩니다. 시스템의 균형을 유지하기 위해 필요한 입력 내용과 양은 출력 사양에 따라 결정됩니다.

피드백

• 피드백은 동적 시스템에서 제어를 제공합니다.

• 긍정적 인 피드백은 본질적으로 시스템의 성능을 장려하는 일상적인 것입니다.

• 부정적인 피드백은 본질적으로 정보 제공 용으로 컨트롤러에 조치 정보를 제공합니다.

환경

• 환경은 조직이 운영되는 "수퍼 시스템"입니다.

• 시스템을 공격하는 외부 요소의 소스입니다.

• 시스템이 작동해야하는 방식을 결정합니다. 예를 들어, 조직 환경의 공급 업체 및 경쟁 업체는 비즈니스의 실제 성과에 영향을 미치는 제약 조건을 제공 할 수 있습니다.

경계 및 인터페이스

• 시스템은 경계로 정의되어야합니다. 경계는 다른 시스템과 상호 작용할 때 구성 요소, 프로세스 및 상호 관계를 식별하는 제한입니다.

• 각 시스템에는 영향 및 제어 범위를 결정하는 경계가 있습니다.

• 주어진 시스템의 경계에 대한 지식은 성공적인 설계를 위해 다른 시스템과의 인터페이스 특성을 결정하는 데 중요합니다.

시스템 유형

시스템은 다음 유형으로 나눌 수 있습니다-

물리적 또는 추상적 인 시스템

• 물리적 시스템은 유형의 실체입니다. 우리는 그들을 만지고 느낄 수 있습니다.

• 물리적 시스템은 본질적으로 정적이거나 동적 일 수 있습니다. 예를 들어 책상과 의자는 컴퓨터 센터의 물리적 인 부분이며 정적입니다. 프로그래밍 된 컴퓨터는 프로그램, 데이터 및 응용 프로그램이 사용자의 요구에 따라 변경 될 수있는 동적 시스템입니다.

• 추상 시스템은 실제 시스템의 공식, 표현 또는 모델 일 수있는 비 물리적 실체 또는 개념입니다.

개방형 또는 폐쇄 형 시스템

• 개방형 시스템은 환경과 상호 작용해야합니다. 시스템에서 입력을 수신하고 시스템 외부로 출력을 전달합니다. 예를 들어, 변화하는 환경 조건에 적응해야하는 정보 시스템.

• 폐쇄 형 시스템은 환경과 상호 작용하지 않습니다. 환경 적 영향으로부터 격리됩니다. 완전히 닫힌 시스템은 실제로 드뭅니다.

적응 형 및 비 적응 형 시스템

• Adaptive System은 성능을 향상시키고 생존하기 위해 환경 변화에 대응합니다. 예를 들어, 인간, 동물.

• Non Adaptive System은 환경에 반응하지 않는 시스템입니다. 예를 들어, 기계.

영구 또는 임시 시스템

• 영구 시스템은 오랫동안 지속됩니다. 예를 들어, 비즈니스 정책.

• 임시 시스템은 지정된 시간 동안 만들어지고 그 후 철거됩니다. 예를 들어, DJ 시스템은 프로그램에 대해 설정되고 프로그램 후에 분해됩니다.

자연 및 제조 시스템

• 자연계는 자연에 의해 만들어집니다. 예를 들어, 태양계, 계절 시스템.

• Manufactured System은 인공 시스템입니다. 예를 들어 로켓, 댐, 기차.

결정 론적 또는 확률 적 시스템

• 결정 론적 시스템은 예측 가능한 방식으로 작동하며 시스템 구성 요소 간의 상호 작용은 확실하게 알려져 있습니다. 예를 들어, 두 분자의 수소와 한 분자의 산소가 물을 만듭니다.

• 확률 적 시스템은 불확실한 행동을 보여줍니다. 정확한 출력은 알려져 있지 않습니다. 예를 들어, 날씨 예보, 메일 배달.

사회, 인간-기계, 기계 시스템

• 사회 시스템은 사람으로 구성됩니다. 예를 들어, 사교 클럽, 사회.

• 인간-기계 시스템에서는 인간과 기계가 모두 특정 작업을 수행하는 데 관여합니다. 예를 들어, 컴퓨터 프로그래밍.

• 기계 시스템은 인간의 간섭이 무시되는 곳입니다. 모든 작업은 기계에서 수행됩니다. 예를 들어, 자율 로봇.

사람이 만든 정보 시스템

• DMC (Direct Management Control) 하에서 특정 조직의 데이터를 관리하기위한 상호 연결된 정보 리소스 집합입니다.

• 이 시스템에는 조직의 필요에 따라 정보를 생성하기위한 하드웨어, 소프트웨어, 통신, 데이터 및 응용 프로그램이 포함됩니다.

  인공 정보 시스템은 세 가지 유형으로 나뉩니다.

• Formal Information System − 상위 수준에서 하위 수준까지 메모, 지침 등의 정보 흐름을 기반으로합니다.

• Informal Information System − 일상 업무 관련 문제를 해결하는 직원 기반 시스템입니다.

• Computer Based System−이 시스템은 비즈니스 응용 프로그램을 관리하기 위해 컴퓨터에 직접 의존합니다. 예를 들어, 자동 도서관 시스템, 철도 예약 시스템, 은행 시스템 등

시스템 모델

회로도 모델

• 도식 모델은 시스템 요소와 그 연결을 보여주는 2D 차트입니다.

• 정보 흐름, 재료 흐름 및 정보 피드백을 표시하기 위해 다른 화살표가 사용됩니다.

흐름 시스템 모델

• 흐름 시스템 모델은 시스템을 함께 유지하는 재료, 에너지 및 정보의 질서있는 흐름을 보여줍니다.

• 예를 들어 프로그램 평가 및 검토 기술 (PERT)은 실제 시스템을 모델 형태로 추상화하는 데 사용됩니다.

정적 시스템 모델

• 활동-시간 또는 비용-수량 과 같은 한 쌍의 관계를 나타냅니다 .

• 예를 들어 Gantt 차트는 활동-시간 관계에 대한 정적 인 그림을 제공합니다.

동적 시스템 모델

• 비즈니스 조직은 동적 시스템입니다. 동적 모델은 분석가가 처리하는 조직 또는 응용 프로그램의 유형에 가깝습니다.

• 지속적이고 지속적으로 변화하는 시스템 상태를 보여줍니다. 그것은-

  • 시스템에 들어가는 입력

  • 변환이 이루어지는 프로세서

  • 처리에 필요한 프로그램

  • 처리 결과 출력입니다.

정보의 범주

관리자 수준 및 의사 결정 관리자와 관련된 세 가지 범주의 정보가 있습니다.

전략적 정보

• 이 정보는 향후 몇 년 동안 장기 계획 정책을 위해 최고 경영진이 필요로합니다. 예를 들어, 수익, 금융 투자, 인적 자원, 인구 증가 추세가 있습니다.

• 이러한 유형의 정보는 의사 결정 지원 시스템 (DSS)의 도움으로 얻을 수 있습니다.

경영 정보

• 이러한 유형의 정보는 월 단위의 단기 및 중기 범위 계획을 위해 중간 관리자에게 필요합니다. 예를 들어, 판매 분석, 현금 흐름 예측 및 연간 재무 제표.

• 이는 MIS (Management Information Systems)의 도움으로 달성됩니다.

운영 정보

• 이러한 유형의 정보는 일상적인 운영 활동을 시행하기위한 일일 및 단기 계획을위한 낮은 관리에 필요합니다. 예를 들어, 직원 출석 기록, 기한이 지난 구매 주문 및 현재 재고 보유.

• 이는 데이터 처리 시스템 (DPS)의 도움으로 이루어집니다.

효과적인 SDLC (System Development Life Cycle)는 고객 기대치를 충족하고 시간 및 비용 평가 내에서 완료에 도달하며 현재 및 계획된 정보 기술 인프라에서 효과적이고 효율적으로 작동하는 고품질 시스템을 생성해야합니다.

시스템 개발 수명주기 (SDLC)는 수명주기 동안 시스템을 개발하거나 변경하기위한 정책과 절차를 포함하는 개념적 모델입니다.

SDLC는 분석가가 정보 시스템을 개발하는 데 사용합니다. SDLC에는 다음 활동이 포함됩니다.

• requirements
• design
• implementation
• testing
• deployment
• operations
• maintenance

SDLC의 단계

시스템 개발 라이프 사이클은 새로운 정보 시스템이나 수정 된 정보 시스템을 구현하는 데 필요한 단계로 작업을 명시 적으로 분류하는 체계적인 접근 방식입니다.

타당성 조사 또는 계획

• 기존 시스템의 문제와 범위를 정의합니다.

• 새 시스템을 개요하고 목표를 결정합니다.

• 프로젝트 타당성을 확인하고 프로젝트 일정을 작성합니다.

• 이 단계에서는 시스템의 위협, 제약, 통합 및 보안도 고려됩니다.

• 이 단계가 끝나면 전체 프로젝트에 대한 타당성 보고서가 생성됩니다.

분석 및 사양

• 정보를 수집, 분석 및 검증합니다.

• 새 시스템에 대한 요구 사항과 프로토 타입을 정의합니다.

• 대안을 평가하고 요구 사항의 우선 순위를 지정합니다.

• 최종 사용자의 정보 요구를 검토하고 시스템 목표를 향상시킵니다.

• 시스템의 소프트웨어, 하드웨어, 기능 및 네트워크 요구 사항을 지정하는 소프트웨어 요구 사항 사양 (SRS) 문서는이 단계가 끝날 때 준비됩니다.

시스템 디자인

• 애플리케이션, 네트워크, 데이터베이스, 사용자 인터페이스 및 시스템 인터페이스의 디자인을 포함합니다.

• SRS 문서를 프로그래밍 언어로 구현할 수있는 상세하고 완전한 사양 집합을 포함하는 논리적 구조로 변환합니다.

• 비상 사태, 교육, 유지 보수 및 운영 계획을 작성하십시오.

• 제안 된 설계를 검토하십시오. 최종 설계가 SRS 문서에 명시된 요구 사항을 충족해야합니다.

• 마지막으로 다음 단계에서 사용할 디자인 문서를 준비합니다.

이행

• 코딩을 통해 디자인을 소스 코드로 구현합니다.

• 모든 모듈을 오류와 결함을 감지하는 교육 환경으로 결합합니다.

• 오류가 포함 된 테스트 보고서는 테스트 케이스 생성, 테스트 기준 및 테스트를위한 리소스 할당과 같은 테스트 관련 작업을 포함하는 테스트 계획을 통해 준비됩니다.

• 정보 시스템을 환경에 통합하고 새 시스템을 설치하십시오.

유지 보수 / 지원

• 시스템이 설치되면 필요한 사용자를위한 전화 지원 또는 물리적 현장 지원과 같은 모든 활동을 포함합니다.

• 소프트웨어가 일정 기간 동안 겪을 수있는 변경 사항을 구현하거나 소프트웨어가 고객 위치에 배포 된 후 새로운 요구 사항을 구현합니다.

• 또한 잔여 오류를 처리하고 테스트 단계 후에도 시스템에 존재할 수있는 문제를 해결하는 것도 포함됩니다.

• 대형 시스템의 경우 더 긴 시간 동안, 소규모 시스템의 경우 짧은 시간 동안 유지 관리 및 지원이 필요할 수 있습니다.

시스템 분석 및 설계의 수명주기

다음 다이어그램은 분석 및 설계 단계 동안 시스템의 전체 수명주기를 보여줍니다.

시스템 분석가의 역할

시스템 분석가는 시스템을 철저히 파악하고 올바른 방향을 제시하여 시스템 개발 프로젝트를 안내하는 사람입니다. 그는 각 단계에서 필요한 개발 작업을 수행하는 기술 및 대인 관계 기술을 보유한 전문가입니다.

그는 정보 시스템의 목표와 조직 목표를 일치시키기 위해 노력합니다.

주요 역할

• 다양한 Fact Finding 기법을 통해 사용자의 요구 사항을 정의하고 이해합니다.

• 사용자 합의를 얻어 요구 사항의 우선 순위를 지정합니다.

• 사실 또는 정보를 수집하고 사용자의 의견을 습득합니다.

• 보다 사용자 친화적 인 적절한 시스템에 도달하기 위해 분석 및 평가를 유지합니다.

• 많은 유연한 대체 솔루션을 제안하고 최상의 솔루션을 선택하며 비용과 이점을 정량화합니다.

• 사용자와 프로그래머가 쉽게 이해할 수있는 특정 사양을 정확하고 상세한 형식으로 그립니다.

• 모듈 식이어야하는 시스템의 논리적 설계를 구현했습니다.

• 일정 기간 사용한 후 평가주기를 계획하고 필요에 따라 시스템을 수정합니다.

시스템 분석가의 특성

다음 그림은 시스템 분석가가 소유해야하는 속성을 보여줍니다.

대인 관계 기술

• 사용자 및 프로그래머와의 인터페이스.
• 그룹을 촉진하고 소규모 팀을 이끄십시오.
• 기대치 관리.
• 좋은 이해, 의사 소통, 판매 및 교육 능력.
• 질문을 해결할 수있는 자신감을 가진 동기 부 여자.

분석 기술

• 시스템 연구 및 조직 지식
• 문제 식별, 문제 분석 및 문제 해결
• 건전한 상식
• 절충점에 접근하는 능력
• 새로운 조직에 대해 배우려는 호기심

관리 기술

• 사용자의 전문 용어와 관행을 이해합니다.
• 자원 및 프로젝트 관리.
• 변경 및 위험 관리.
• 관리 기능을 철저히 이해합니다.

기술 능력

• 컴퓨터와 소프트웨어에 대한 지식.
• 현대적인 발전을 따라 잡으십시오.
• 시스템 설계 도구를 알고 있습니다.
• 신기술에 대한 폭 넓은 지식.

요구 사항 결정이란 무엇입니까?

요구 사항은 데이터 처리 또는 캡처, 비즈니스 활동 제어, 정보 생성 및 관리 지원을 포함 할 수있는 새로운 시스템의 중요한 기능입니다.

요구 사항 결정에는 기존 시스템을 연구하고 세부 정보를 수집하여 요구 사항이 무엇인지, 어떻게 작동하는지, 개선해야 할 부분을 파악하는 것이 포함됩니다.

요구 사항 결정의 주요 활동

요구 사항 예상

• 새로운 시스템에 대한 특정 문제 또는 기능 및 요구 사항을 포함하는 이전 경험을 기반으로 시스템의 특성을 예측합니다.

• 경험이없는 분석가가 알아 채지 못할 영역에 대한 분석으로 이어질 수 있습니다. 그러나 지름길을 택하고 조사를 수행하는 데 편견이 도입되면 요구 사항 예측이 반쯤 될 수 있습니다.

요구 사항 조사

• 현재 시스템을 연구하고 추가 분석을 위해 기능을 문서화하고 있습니다.

• 분석가가 사실 발견 기술, 프로토 타이핑 및 컴퓨터 지원 도구를 사용하여 시스템 기능을 문서화하고 설명하는 시스템 분석의 핵심입니다.

요구 사항 사양

• 여기에는 요구 사항 사양을 결정하는 데이터 분석, 새 시스템의 기능 설명 및 제공 될 정보 요구 사항 지정이 포함됩니다.

• 여기에는 사실 데이터 분석, 필수 요구 사항 식별 및 요구 사항 충족 전략 선택이 포함됩니다.

정보 수집 기법

사실 발견 기술의 주요 목표는 분석가가 사용자가 이해하는 정확한 SRS를 준비하는 데 사용하는 조직의 정보 요구 사항을 결정하는 것입니다.

이상적인 SRS 문서는-

• 완전하고 모호하지 않으며 전문 용어가 없어야합니다.
• 운영, 전술 및 전략적 정보 요구 사항을 지정합니다.
• 사용자와 분석가 간의 가능한 분쟁을 해결합니다.
• 이해와 디자인을 단순화하는 그래픽 보조 도구를 사용하십시오.

다양한 정보 수집 기술이 있습니다-

인터뷰

시스템 분석가는 인터뷰를 통해 개인 또는 그룹으로부터 정보를 수집합니다. 분석가는 공식적이거나, 합법적이거나, 정치적인 행동을하거나, 비공식적 일 수 있습니다. 면접의 성공 여부는 면접관으로서의 분석가의 능력에 달려 있습니다.

두 가지 방법으로 수행 할 수 있습니다.

• Unstructured Interview − 시스템 분석가는 시스템의 기본 정보를 얻기 위해 질의 응답 세션을 진행합니다.

• Structured Interview − 사용자가 닫기 (목표) 또는 공개 (설명) 형식으로 응답해야하는 표준 질문이 있습니다.

Advantages of Interviewing

• 이 방법은 종종 정 성적 정보를 수집하는 가장 좋은 소스입니다.

• 서면으로 효과적으로 의사 소통하지 못하거나 설문지를 작성할 시간이없는 사람들에게 유용합니다.

• 정보는 쉽게 검증되고 즉시 교차 확인 될 수 있습니다.

• 복잡한 주제를 다룰 수 있습니다.

• 의견을 구하여 핵심 문제를 쉽게 발견 할 수 있습니다.

• 오해 영역의 격차를 해소하고 향후 문제를 최소화합니다.

설문지

이 방법은 분석가가 많은 사람으로부터 시스템의 다양한 문제에 대한 정보를 수집하는 데 사용됩니다.

설문지에는 두 가지 유형이 있습니다.

• Open-ended Questionnaires− 쉽고 정확하게 해석 할 수있는 질문으로 구성되어 있습니다. 그들은 문제를 탐구하고 구체적인 답변 방향으로 이어질 수 있습니다.

• Closed-ended Questionnaires − 시스템 분석가가 상호 배타적 인 가능한 모든 응답을 효과적으로 나열 할 때 사용되는 질문으로 구성됩니다.

Advantages of questionnaires

• 같은 위치에 있지 않은 사용자의 관심사, 태도, 감정 및 신념을 조사하는 데 매우 효과적입니다.

• 주어진 그룹에서 제안 된 시스템의 특정 기능을 승인 또는 비 승인하는 비율을 아는 것은 상황에서 유용합니다.

• 시스템 프로젝트에 특정 방향을 제시하기 전에 전반적인 의견을 결정하는 것이 유용합니다.

• 더 신뢰할 수 있으며 정직한 답변에 대해 높은 기밀성을 제공합니다.

• 사실 정보를 선택하고 이메일로 보내고 우편으로 보낼 수있는 통계 데이터 수집에 적합합니다.

기록, 절차 및 양식 검토

기존 기록, 절차 및 양식을 검토하면 현재 시스템 기능, 운영 또는 활동을 설명하는 시스템에 대한 통찰력을 찾는 데 도움이됩니다.

Advantages

• 사용자가 다른 사람에게 부과하기 전에 스스로 조직 또는 운영에 대한 지식을 얻을 수 있도록 도와줍니다.

• 절차 매뉴얼과 양식이 현재 시스템의 형식과 기능을 설명하므로 짧은 시간 내에 현재 작업을 문서화하는 데 도움이됩니다.

• 조직에서 처리되는 트랜잭션에 대한 명확한 이해를 제공하고 처리를위한 입력을 식별하고 성능을 평가할 수 있습니다.

• 분석가가 지원해야하는 운영 측면에서 시스템을 이해하는 데 도움이 될 수 있습니다.

• 문제, 영향을받는 부분 및 제안 된 솔루션을 설명합니다.

관측

사람, 사건, 사물을인지하고 관찰하여 정보를 수집하는 방법입니다. 분석가는 조직을 방문하여 현재 시스템의 작동을 관찰하고 시스템의 요구 사항을 이해합니다.

Advantages

• 정보를 수집하는 직접적인 방법입니다.

• 수집 된 데이터의 신뢰성이 의심되는 상황이나 시스템의 특정 측면의 복잡성으로 인해 최종 사용자가 명확한 설명을 할 수없는 상황에서 유용합니다.

• 더 정확하고 신뢰할 수있는 데이터를 생성합니다.

• 불완전하고 오래된 문서의 모든 측면을 생성합니다.

공동 애플리케이션 개발 (JAD)

소유자, 사용자, 분석가, 설계자 및 건축업자가 체계적이고 집중적 인 워크숍을 사용하여 시스템을 정의하고 설계 할 수 있도록 IBM에서 개발 한 새로운 기술입니다. JAD 교육을받은 분석가는 전문 기술을 보유한 워크샵의 진행자 역할을합니다.

Advantages of JAD

• 수개월 간의 기존 인터뷰 및 후속 회의를 대체하여 시간과 비용을 절약합니다.

• 공동 문제 해결을 지원하는 조직 문화에 유용합니다.

• 여러 수준의 직원 간의 공식적인 관계를 촉진합니다.

• 창의적인 디자인 개발로 이어질 수 있습니다.

• 신속한 개발을 가능하게하고 정보 시스템의 소유권을 향상시킵니다.

이차 연구 또는 배경 읽기

이 방법은 수집 된 정보에 액세스하여 정보 수집에 널리 사용됩니다. 여기에는 마케팅 담당자가 내부 또는 외부 소스에서 사용하는 이전에 수집 한 정보가 포함됩니다.

Advantages

• 인터넷의 가용성으로 더 공개적으로 액세스됩니다.

• 저렴한 비용과 시간으로 귀중한 정보를 제공합니다.

• 1 차 연구의 선구자 역할을하며 1 차 연구의 초점을 맞 춥니 다.

• 연구자는 사용 된 절차 및 수집 문제와 함께 사용할 수 있으므로 연구가 가치가 있는지 결론을 내리는 데 사용됩니다.

타당성 조사

타당성 조사는 시스템 연구가 개발에 타당해야하는지 여부를 경영진이 결정하는 데 도움이되는 예비 조사로 간주 할 수 있습니다.

• 기존 시스템을 개선하고 새로운 시스템을 개발할 가능성을 식별하고 시스템의 추가 개발을위한 정제 된 견적을 생성합니다.

• 문제의 개요를 얻고 실행 가능하거나 적절한 솔루션이 있는지 여부를 결정하는 데 사용됩니다.

• 타당성 조사의 주요 목적은 문제를 해결하는 대신 문제 범위를 획득하는 것입니다.

• 타당성 조사의 결과는 제안 된 시스템의 완전한 특성과 범위를 포함하는 결정 문서로서의 공식 시스템 제안 행위입니다.

타당성 분석에 포함 된 단계

타당성 분석을 수행하는 동안 다음 단계를 따라야합니다.

• 프로젝트 팀을 구성하고 프로젝트 리더를 임명합니다.

• 시스템 흐름도를 개발합니다.

• 현재 시스템의 결함을 식별하고 목표를 설정합니다.

• 목표를 달성하기 위해 대체 솔루션 또는 잠재적 후보 시스템을 열거합니다.

• 기술적 타당성, 운영 타당성 등과 같은 각 대안의 타당성을 결정합니다.

• 각 후보 시스템의 성능과 비용 효율성에 가중치를 둡니다.

• 다른 대안의 순위를 매기고 가장 적합한 후보 시스템을 선택하십시오.

• 승인을 위해 경영진에 대한 최종 프로젝트 지침의 시스템 제안을 준비합니다.

타당성 유형

경제성

• 비용 / 이익 분석 방법을 사용하여 후보 시스템의 효과를 평가하고 있습니다.

• 조직에 대한 이익과 비용 측면에서 후보 시스템의 순 이익을 보여줍니다.

• 경제적 타당성 분석 (EFS)의 주요 목표는 투자 자금이 제안에 투입되기 전에 후보 시스템의 경제적 요구 사항을 추정하는 것입니다.

• 후보 시스템 개발과 관련된 가장 낮은 수준의 위험과 함께 가장 빠르고 높은 자금 회수로 조직의 순 가치를 극대화하는 대안을 선호합니다.

기술적 타당성

• 각 구현 대안의 기술적 타당성을 조사합니다.

• 솔루션이 기존 기술로 지원 될 수 있는지 여부를 분석하고 결정합니다.

• 분석가는 새로운 요구 사항을 충족하는 현재 기술 리소스를 업그레이드할지 추가할지 결정합니다.

• 후보 시스템이 기술 향상을 지원할 수있는 정도까지 적절한 응답을 제공하도록합니다.

운영 타당성

• 시스템이 개발되고 구현되면 시스템이 효과적으로 작동하는지 여부를 결정합니다.

• 이는 경영진이 제안 된 시스템과 현재 조직 환경에서 가능한 작업을 지원해야 함을 보장합니다.

• 사용자가 영향을 받을지 여부를 분석하고 가능한 시스템 이점에 영향을 미치는 수정 된 또는 새로운 비즈니스 방법을 수락합니다.

• 또한 후보 시스템의 컴퓨터 리소스와 네트워크 아키텍처가 실행 가능한지 확인합니다.

행동 타당성

• 새로운 시스템 개발에 대한 사용자의 태도 또는 행동을 평가하고 추정합니다.

• 새로운 업무 수행 방식에 대해 직원의 직무 상태를 교육, 재교육, 이전 및 변경하기 위해 시스템에 특별한 노력이 필요한지 여부를 결정하는 데 도움이됩니다.

일정 타당성

• 주어진 시간 제약이나 일정 내에 프로젝트를 완료해야합니다.

• 또한 프로젝트 기한이 합리적인지 여부를 확인하고 검증합니다.

분석가는 다양한 도구를 사용하여 정보 시스템을 이해하고 설명합니다. 한 가지 방법은 구조화 된 분석을 사용하는 것입니다.

구조화 분석이란 무엇입니까?

구조화 분석은 분석가가 시스템과 그 활동을 논리적으로 이해할 수 있도록하는 개발 방법입니다.

기존 시스템의 목표를 분석하고 개선하는 그래픽 도구를 사용하여 사용자가 쉽게 이해할 수있는 새로운 시스템 사양을 개발하는 체계적인 접근 방식입니다.

그것은 다음과 같은 속성이 있습니다-

• 응용 프로그램의 표현을 지정하는 그래픽입니다.

• 시스템 흐름에 대한 명확한 그림을 제공하도록 프로세스를 분할합니다.

• 물리적이 아니라 논리적입니다. 즉, 시스템의 요소가 공급 업체 나 하드웨어에 의존하지 않습니다.

• 높은 수준의 개요에서 낮은 수준의 세부 정보까지 작동하는 접근 방식입니다.

구조화 된 분석 도구

구조화 분석 중에는 시스템 개발에 다양한 도구와 기술이 사용됩니다. 그들은-

• 데이터 흐름 다이어그램
• 데이터 사전
• 의사 결정 트리
• 의사 결정 테이블
• 구조화 된 영어
• Pseudocode

데이터 흐름 다이어그램 (DFD) 또는 거품 형 차트

래리 콘스탄틴이 시스템의 요구 사항을 그래픽 형식으로 표현하기 위해 개발 한 기술입니다.

• 시스템의 다양한 기능 간의 데이터 흐름을 보여주고 현재 시스템이 어떻게 구현되는지 지정합니다.

• 요구 사항 사양을 가장 낮은 수준의 세부 수준으로 기능적으로 나누는 설계 단계의 초기 단계입니다.

• 그래픽 특성으로 인해 사용자와 분석가 또는 분석가와 시스템 설계자 간의 훌륭한 커뮤니케이션 도구입니다.

• 시스템에서 처리하는 데이터, 수행되는 변환, 저장되는 데이터, 생성되는 결과 및 흐름 위치에 대한 개요를 제공합니다.

DFD의 기본 요소

DFD는 필요한 디자인이 명확하지 않고 사용자가 커뮤니케이션을위한 표기 언어를 원하는 경우 이해하기 쉽고 매우 효과적입니다. 그러나 가장 정확하고 완전한 솔루션을 얻으려면 많은 반복이 필요합니다.

다음 표는 DFD 설계에 사용되는 기호와 그 의미를 보여줍니다.

기호 이름	상징	의미
광장		데이터 소스 또는 대상
화살		데이터 흐름
원		데이터 흐름을 변환하는 프로세스
열린 직사각형		데이터 저장소

DFD의 유형

DFD에는 물리적 DFD와 논리적 DFD의 두 가지 유형이 있습니다. 다음 표에는 물리적 DFD와 논리적 DFD를 구별하는 점이 나열되어 있습니다.

물리적 DFD	논리적 DFD
구현에 따라 다릅니다. 어떤 기능이 수행되는지 보여줍니다.	독립적 인 구현입니다. 프로세스 간의 데이터 흐름에만 중점을 둡니다.
하드웨어, 소프트웨어, 파일 및 사람에 대한 낮은 수준의 세부 정보를 제공합니다.	시스템의 이벤트와 각 이벤트에 필요한 데이터를 설명합니다.
현재 시스템이 작동하는 방식과 시스템이 구현되는 방식을 설명합니다.	비즈니스 운영 방식을 보여줍니다. 시스템 구현 방법이 아닙니다.

컨텍스트 다이어그램

컨텍스트 다이어그램은 시스템 개요를 제공하는 하나의 DFD로 전체 시스템을 이해하는 데 도움이됩니다. 세부 사항이 거의없는 주요 프로세스를 언급하는 것으로 시작하여 하향식 접근 방식으로 프로세스에 대한 세부 정보를 제공합니다.

다음은 엉망 관리의 컨텍스트 다이어그램입니다.

데이터 사전

데이터 사전은 시스템에있는 데이터 요소의 구조화 된 저장소입니다. 모든 DFD 데이터 요소의 설명, 즉 데이터 흐름, 데이터 저장소, 데이터 저장소에 저장된 데이터 및 프로세스의 세부 정보 및 정의를 저장합니다.

데이터 사전은 분석가와 사용자 간의 의사 소통을 향상시킵니다. 데이터베이스 구축에 중요한 역할을합니다. 대부분의 DBMS에는 표준 기능으로 데이터 사전이 있습니다. 예를 들어, 다음 표를 참조하십시오-

Sr. 아니.	데이터 이름	기술	문자 수
1	ISBN	ISBN 번호	10
2	표제	표제	60
삼	보결	책 주제	80
4	이름	저자명	15

의사 결정 트리

의사 결정 트리는 의사 결정을 설명하고 의사 소통의 문제를 피하여 복잡한 관계를 정의하는 방법입니다. 의사 결정 트리는 수평 트리 프레임 워크 내에서 대체 작업 및 조건을 보여주는 다이어그램입니다. 따라서 첫 번째, 두 번째 등 고려할 조건을 설명합니다.

의사 결정 트리는 각 조건과 허용 가능한 조치의 관계를 나타냅니다. 정사각형 노드는 동작을 나타내고 원은 조건을 나타냅니다. 분석가는 결정 순서를 고려하고 실제 결정을 내려야합니다.

의사 결정 트리의 주요 한계는 테스트를 위해 취할 수있는 다른 조건 조합을 설명하는 형식의 정보가 없다는 것입니다. 이것은 조건과 행동 사이의 관계에 대한 단일 표현입니다.

예를 들어, 다음 결정 트리를 참조하십시오-

의사 결정 테이블

의사 결정 테이블은 복잡한 논리적 관계를 쉽게 이해할 수있는 정확한 방식으로 설명하는 방법입니다.

• 결과 조치가 하나 또는 여러 개의 독립 조건 조합 발생에 의존하는 상황에서 유용합니다.

• 문제와 조치를 정의하기위한 행 또는 열을 포함하는 행렬입니다.

의사 결정 테이블의 구성 요소

• Condition Stub − 검사 할 모든 조건을 나열하는 왼쪽 상단 사분면에 있습니다.

• Action Stub − 이러한 조건을 충족하기 위해 수행해야하는 모든 작업의 ​​개요는 왼쪽 아래 사분면에 있습니다.

• Condition Entry − 상태 스텁 사분면에서 질문에 대한 답변을 제공하는 오른쪽 상단 사분면에 있습니다.

• Action Entry − 조건 입력 사분면의 조건에 대한 답변으로 인한 적절한 조치를 나타내는 오른쪽 아래 사분면에 있습니다.

의사 결정 테이블의 항목은 조건 조합과 조치 과정 간의 관계를 정의하는 의사 결정 규칙에 의해 제공됩니다. 규칙 섹션에서

• Y는 조건의 존재를 나타냅니다.
• N은 충족되지 않은 조건을 나타냅니다.
• 공백-조치에 대해 무시해야 함을 나타냅니다.
• X (또는 확인 표시가 수행됨)가 수행 될 작업 상태에 대해 표시됩니다.

예를 들어, 다음 표를 참조하십시오-

정황	규칙 1	규칙 2	규칙 3	규칙 4
선불 결제	와이	엔	엔	엔
구매 금액 = Rs 10,000 /-	-	와이	와이	엔
일반 고객	-	와이	엔	-
ACTIONS
5 % 할인 제공	엑스	엑스	-	-
할인 안 함	-	-	엑스	엑스

구조화 된 영어

구조 영어는 구조화 된 프로그래밍 언어에서 파생되어 프로세스를보다 이해하기 쉽고 정확하게 설명합니다. 이는 동작을위한 연산을 수행하도록 설계된 구성 및 명령문을 사용하는 절차 적 논리를 기반으로합니다.

• 프로그램의 시퀀스와 루프를 고려해야하고 문제가 결정과 함께 일련의 작업을 필요로 할 때 가장 잘 사용됩니다.

• 엄격한 구문 규칙이 없습니다. 순차 결정 구조 및 반복 측면에서 모든 논리를 표현합니다.

예를 들어, 다음 작업 순서를 참조하십시오.

if customer pays advance 
   then 
      Give 5% Discount 
   else 
      if purchase amount >=10,000 
         then 
            if  the customer is a regular customer 
               then Give 5% Discount 
            else  No Discount
         end if 
      else No Discount  
   end if 
end if

의사 코드

의사 코드는 프로그래밍 언어를 따르지 않으며 논리를 일반 영어로 표현합니다.

• 물리적 설계 도중과 이후에 실제 코딩없이 물리적 프로그래밍 로직을 지정할 수 있습니다.

• 구조화 된 프로그래밍과 함께 사용됩니다.

• 프로그램의 순서도를 대체합니다.

적절한 도구 선택 지침

요구 사항에 가장 적합한 도구를 선택하려면 다음 지침을 사용하십시오.

• 좋은 시스템 문서를 제공하기 위해 높은 수준 또는 낮은 수준의 분석에서 DFD를 사용합니다.

• 데이터 사전을 사용하여 시스템의 데이터 요구 사항을 충족하기위한 구조를 단순화합니다.

• 루프가 많고 작업이 복잡한 경우 구조화 된 영어를 사용합니다.

• 확인할 조건이 많고 논리가 복잡한 경우 의사 결정 테이블을 사용합니다.

• 조건 순서 지정이 중요하고 테스트 할 조건이 거의없는 경우 의사 결정 트리를 사용합니다.

System design관리 가능한 방식으로 문제 도메인과 기존 시스템 간의 격차를 해소하는 단계입니다. 이 단계는 솔루션 영역, 즉 "구현 방법" 에 중점을 둡니다.

SRS 문서가 구현 가능한 형식으로 변환되고 시스템 작동 방식을 결정하는 단계입니다.

이 단계에서 시스템 개발의 복잡한 활동은 여러 개의 작은 하위 활동으로 나뉘며 시스템 개발의 주요 목표를 달성하기 위해 서로 조정됩니다.

시스템 설계에 대한 입력

시스템 설계는 다음과 같은 입력을받습니다.

• 작업의 문

• 요구 사항 결정 계획

• 현재 상황 분석

• 개념적 데이터 모델, 수정 된 DFD 및 메타 데이터 (데이터에 대한 데이터)를 포함한 제안 된 시스템 요구 사항.

시스템 설계를위한 출력

시스템 설계는 다음과 같은 출력을 제공합니다.

• 제안 된 시스템의 인프라 및 조직 변경.

• 데이터 스키마, 종종 관계형 스키마.

• 테이블 / 파일 및 열 / 데이터 항목을 정의하는 메타 데이터입니다.

• 프로그램 구조를 그래픽으로 설명하는 기능 계층 다이어그램 또는 웹 페이지 맵입니다.

• 프로그램의 각 모듈에 대한 실제 또는 의사 코드.

• 제안 된 시스템의 프로토 타입.

시스템 설계 유형

논리적 설계

논리적 설계는 시스템의 데이터 흐름, 입력 및 출력의 추상적 인 표현과 관련이 있습니다. 입력 (소스), 출력 (대상), 데이터베이스 (데이터 저장소), 프로 시저 (데이터 흐름)를 모두 사용자 요구 사항을 충족하는 형식으로 설명합니다.

시스템의 논리적 설계를 준비하는 동안 시스템 분석가는 시스템 및 필수 데이터 소스로 들어오고 나가는 정보 흐름을 가상으로 결정하는 세부 수준에서 사용자 요구를 지정합니다. 데이터 흐름도, ER 다이어그램 모델링이 사용됩니다.

물리적 디자인

물리적 설계는 시스템의 실제 입력 및 출력 프로세스와 관련이 있습니다. 데이터가 시스템에 입력되고 검증되고 처리되고 출력으로 표시되는 방법에 중점을 둡니다.

후보 시스템이 수행하는 작업을 정확히 지정하는 설계 사양을 정의하여 작업 시스템을 생성합니다. 사용자 인터페이스 디자인, 프로세스 디자인 및 데이터 디자인과 관련이 있습니다.

다음 단계로 구성됩니다-

• 입 / 출력 매체 지정, 데이터베이스 설계 및 백업 절차 지정.

• 계획 시스템 구현.

• 테스트 및 구현 계획을 고안하고 새로운 하드웨어 및 소프트웨어를 지정합니다.

• 비용, 이점, 전환 날짜 및 시스템 제약을 업데이트합니다.

건축 설계

시스템 아키텍처 설계에 초점을 맞춘 고수준 설계라고도합니다. 시스템의 구조와 동작을 설명합니다. 시스템 개발 프로세스의 다양한 모듈 간의 구조와 관계를 정의합니다.

세부 설계

그것은 건축 설계를 따르고 각 모듈의 개발에 중점을 둡니다.

개념적 데이터 모델링

모든 주요 엔터티 및 관계를 포함하는 조직 데이터의 표현입니다. 시스템 분석가는 제안 된 시스템의 범위와 요구 사항을 지원하는 현재 시스템에 대한 개념 데이터 모델을 개발합니다.

개념적 데이터 모델링의 주요 목적은 가능한 한 많은 데이터의 의미를 포착하는 것입니다. 오늘날 대부분의 조직은 데이터에 대한 많은 의미를 표현하기 위해 특수 표기법을 사용하는 ER 모델을 사용하는 개념적 데이터 모델링을 사용합니다.

엔티티 관계 모델

조직의 다양한 엔터티 간의 관계를 설명하는 데 도움이되는 데이터베이스 디자인에 사용되는 기술입니다.

ER 모델에서 사용되는 용어

• ENTITY− 응용 프로그램에서 고유 한 실제 항목을 지정합니다. 예 : 공급 업체, 항목, 학생, 코스, 교사 등

• RELATIONSHIP− 이들은 엔티티 간의 의미있는 종속성입니다. 예를 들어, 공급 업체는 품목을 공급하고 교사는 과정을 가르치고 용품과 과정은 관계입니다.

• ATTRIBUTES− 관계의 속성을 지정합니다. 예 : 공급 업체 코드, 학생 이름. ER 모델에서 사용되는 기호와 각각의 의미-

다음 표는 ER 모델에 사용 된 기호와 그 의미를 보여줍니다.

상징	의미
	실재
	약한 개체
	관계
	신원 관계
	속성
	주요 속성
	다중 값
	복합 속성
	파생 된 속성
	R에서 E2의 총 참여
	R의 E1 : E2에 대한 카디널리티 비율 1 : N

두 데이터 세트 사이에는 일대일, 일대 다 및 다 대다의 세 가지 유형의 관계가 존재할 수 있습니다.

파일 구성

레코드가 파일 내에 저장되는 방법을 설명합니다.

네 가지 파일 구성 방법이 있습니다-

• Serial − 기록은 시간순 (입력 또는 발생 순서)으로 저장됩니다. Examples − 전화 요금, ATM 거래, 전화 대기열 기록.

• Sequential − 레코드는 레코드를 고유하게 식별하는 값을 포함하는 키 필드를 기준으로 순서대로 저장됩니다. Examples − 전화 번호부.

• Direct (relative)− 각 기록은 장치의 물리적 주소 또는 위치를 기반으로 저장됩니다. 주소는 레코드의 키 필드에 저장된 값에서 계산됩니다. 무작위 루틴 또는 해싱 알고리즘이 변환을 수행합니다.

• Indexed − 인덱스를 사용하여 레코드를 순차적으로 또는 비 순차적으로 처리 할 수 ​​있습니다.

비교

파일 액세스

순차 액세스 또는 임의 액세스를 사용하여 파일에 액세스 할 수 있습니다. 파일 액세스 방법을 사용하면 컴퓨터 프로그램이 파일의 레코드를 읽거나 쓸 수 있습니다.

순차 액세스

파일의 모든 레코드는 EOF (파일 끝)에 도달 할 때까지 첫 번째 레코드부터 처리됩니다. 주어진 시간에 파일의 많은 레코드에 액세스해야하는 경우 효율적입니다. 테이프에 저장된 데이터 (순차 액세스)는 순차적으로 만 액세스 할 수 있습니다.

직접 (무작위) 액세스

레코드는 다른 레코드와 관련된 위치가 아닌 장치의 물리적 위치 또는 주소를 아는 방식으로 찾습니다. CD 장치 (직접 액세스)에 저장된 데이터는 순차적으로 또는 무작위로 액세스 할 수 있습니다.

조직 시스템에서 사용되는 파일 유형

다음은 조직 시스템에서 사용되는 파일 유형입니다-

• Master file− 시스템에 대한 현재 정보를 포함합니다. 예를 들어, 고객 파일, 학생 파일, 전화 번호부.

• Table file− 드물게 변경되고 표 형식으로 저장되는 마스터 파일 유형입니다. 예를 들어, 우편 번호 저장.

• Transaction file− 여기에는 비즈니스 활동에서 생성 된 일상적인 정보가 포함됩니다. 마스터 파일을 업데이트하거나 처리하는 데 사용됩니다. 예를 들어, 직원의 주소.

• Temporary file − 시스템에서 필요할 때마다 생성하여 사용합니다.

• Mirror file− 다른 파일과 정확히 중복됩니다. 원본을 사용할 수 없게되는 경우 다운 타임 위험을 최소화 할 수 있습니다. 원본 파일이 변경 될 때마다 수정해야합니다.

• Log files− 여기에는 마스터 파일의 변경 사항을 기록하기 위해 마스터 및 트랜잭션 레코드의 사본이 포함됩니다. 감사를 용이하게하고 시스템 장애시 복구 메커니즘을 제공합니다.

• Archive files − 다른 파일의 기록 버전이 포함 된 백업 파일.

문서 관리

문서화는 참조 또는 운영 목적으로 정보를 기록하는 프로세스입니다. 이를 필요로하는 사용자, 관리자 및 IT 직원에게 도움이됩니다. 시스템의 진행 상황을 쉽게 추적하려면 준비된 문서를 정기적으로 업데이트해야합니다.

시스템 구현 후 시스템이 부적절하게 작동하는 경우 문서는 관리자가 시스템의 데이터 흐름을 이해하여 결함을 수정하고 시스템을 작동시키는 데 도움이됩니다.

프로그래머 또는 시스템 분석가는 일반적으로 프로그램 및 시스템 문서를 작성합니다. 시스템 분석가는 일반적으로 사용자가 시스템을 배우는 데 도움이되는 문서를 준비합니다. 대기업에서는 기술 작성자가 포함 된 기술 지원 팀이 사용자 문서 및 교육 자료 준비를 지원할 수 있습니다.

장점

• 시스템 다운 타임을 줄이고 비용을 절감하며 유지 보수 작업의 속도를 높일 수 있습니다.

• 현재 시스템의 형식적인 흐름에 대한 명확한 설명을 제공하고 입력 데이터의 유형과 출력을 생성하는 방법을 이해하는 데 도움이됩니다.

• 시스템에 대한 기술 사용자와 비 기술 사용자 간의 효과적이고 효율적인 커뮤니케이션 방법을 제공합니다.

• 새로운 사용자의 교육을 용이하게하여 시스템의 흐름을 쉽게 이해할 수 있습니다.

• 사용자가 문제 해결과 같은 문제를 해결하고 관리자가 조직 시스템에 대한 더 나은 최종 결정을 내릴 수 있도록 도와줍니다.

• 시스템의 내부 또는 외부 작업을 더 잘 제어 할 수 있습니다.

문서 유형

시스템 설계와 관련하여 다음 네 가지 주요 문서가 있습니다.

• 프로그램 문서
• 시스템 문서
• 운영 문서
• 사용자 문서

프로그램 문서

• 모든 프로그램 모듈에 대한 입력, 출력 및 처리 논리를 설명합니다.

• 프로그램 문서화 프로세스는 시스템 분석 단계에서 시작하여 구현 중에 계속됩니다.

• 이 문서는 쉽게 이해하고 유지 관리 할 수있는 내부 및 외부 주석과 설명에 의해 잘 지원되는 모듈을 구성하는 프로그래머를 안내합니다.

운영 문서

운영 문서에는 온라인 및 인쇄 된 출력물을 처리하고 배포하는 데 필요한 모든 정보가 포함되어 있습니다. 운영 문서는 명확하고 간결하며 가능하면 온라인에서 사용할 수 있어야합니다.

다음 정보를 포함합니다-

• 프로그램, 시스템 분석가, 프로그래머 및 시스템 식별.

• 보고서, 실행 빈도 및 기한과 같은 인쇄 된 출력에 대한 일정 정보.

• 입력 파일, 소스, 출력 파일 및 대상.

• 전자 메일 및 보고서 배포 목록.

• 온라인 양식을 포함한 특수 양식이 필요합니다.

• 운영자에게 오류 및 정보 메시지를 보내고 절차를 다시 시작합니다.

• 보안 요구 사항과 같은 특별 지침.

사용자 문서

여기에는 시스템과 상호 작용할 사용자에 대한 지침 및 정보가 포함됩니다. 예를 들어 사용 설명서, 도움말 가이드 및 자습서가 있습니다. 사용자 문서는 사용자 교육 및 참조 목적으로 유용합니다. 명확하고 이해하기 쉬우 며 모든 수준의 사용자가 쉽게 액세스 할 수 있어야합니다.

사용자, 시스템 소유자, 분석가 및 프로그래머는 모두 사용자 가이드를 개발하기 위해 힘을 합쳤습니다.

사용자 문서에는 다음이 포함되어야합니다.

• 모든 주요 시스템 기능, 기능 및 제한 사항을 명확하게 설명하는 시스템 개요.

• 소스 문서 내용, 준비, 처리 및 샘플에 대한 설명.

• 메뉴 및 데이터 입력 화면 옵션, 내용 및 처리 지침 개요.

• 샘플을 포함하여 정기적으로 생성되거나 사용자의 요청에 따라 사용 가능한 보고서의 예입니다.

• 보안 및 감사 추적 정보.

• 특정 입력, 출력 또는 처리 요구 사항에 대한 책임 설명.

• 변경 요청 및 문제보고 절차.

• 예외 및 오류 상황의 예.

• 자주 묻는 질문 (FAQ).

• 사용자 설명서 업데이트에 대한 도움말 및 절차에 대한 설명.

시스템 문서

시스템 문서는 IS에 대한 기술 사양과 IS의 목표를 달성하는 방법으로 사용됩니다. 사용자, 관리자 및 IS 소유자는 시스템 문서를 참조 할 필요가 없습니다. 시스템 문서는 수정이 이루어질 때 IS의 기술적 측면을 이해하기위한 기초를 제공합니다.

• IS 내의 각 프로그램과 전체 IS 자체를 설명합니다.

• 시스템의 기능, 구현 방법, 실행 순서, 프로그램에서 전달되는 정보 및 전체 시스템 흐름과 관련하여 전체 IS 내에서 각 프로그램의 목적을 설명합니다.

• 여기에는 데이터 사전 항목, 데이터 흐름 다이어그램, 개체 모델, 화면 레이아웃, 소스 문서 및 프로젝트를 시작한 시스템 요청이 포함됩니다.

• 대부분의 시스템 문서는 시스템 분석 및 시스템 설계 단계에서 준비됩니다.

• 시스템을 구현하는 동안 분석가는 시스템 문서가 완전하고 정확하며 최신 상태인지 확인하고 구현 프로세스 중 변경된 사항을 포함하는지 확인해야합니다.

하향식 전략

하향식 전략은 모듈 식 접근 방식을 사용하여 시스템 설계를 개발합니다. 최상위 또는 최상위 모듈에서 시작하여 최하위 모듈로 이동하기 때문에 그렇게 호출됩니다.

이 기술에서는 소프트웨어 개발을위한 최상위 모듈 또는 메인 모듈이 식별됩니다. 메인 모듈은 각 모듈이 수행하는 작업에 따라 더 작고 간단한 여러 하위 모듈 또는 세그먼트로 나뉩니다. 그런 다음 각 하위 모듈은 다음 하위 수준의 여러 하위 모듈로 더 세분화됩니다. 각 모듈을 여러 하위 모듈로 나누는이 프로세스는 더 이상 세분화 할 수없는 가장 낮은 수준의 모듈이 식별되지 않을 때까지 계속됩니다.

상향식 전략

상향식 전략은 모듈 식 접근 방식을 따라 시스템 설계를 개발합니다. 가장 기본적인 수준의 모듈부터 시작하여 가장 높은 수준의 모듈로 이동하기 때문에 그렇게 불립니다.

이 기술에서

• 가장 기본적인 또는 가장 낮은 수준의 모듈이 식별됩니다.

• 그런 다음 이러한 모듈은 각 모듈이 수행하는 기능에 따라 그룹화되어 다음 상위 수준 모듈을 형성합니다.

• 그런 다음 이러한 모듈이 추가로 결합되어 다음 상위 수준 모듈을 형성합니다.

• 더 높은 수준의 모듈을 형성하기 위해 더 간단한 여러 모듈을 그룹화하는이 프로세스는 시스템 개발 프로세스의 주요 모듈이 달성 될 때까지 계속됩니다.

구조화 된 디자인

구조화 된 설계는 개발 시스템의 입력 및 출력을 식별하는 데 도움이되는 데이터 흐름 기반 방법론입니다. 구조화 된 설계의 주요 목적은 복잡성을 최소화하고 프로그램의 모듈성을 높이는 것입니다. 구조화 된 설계는 시스템의 기능적 측면을 설명하는데도 도움이됩니다.

구조화 된 설계에서 시스템 사양은 DFD의 도움을 받아 소프트웨어 개발과 관련된 데이터 흐름 및 프로세스 시퀀스를 그래픽으로 표현하기위한 기초 역할을합니다. 소프트웨어 시스템 용 DFD를 개발 한 후 다음 단계는 구조도를 개발하는 것입니다.

모듈화

구조화 된 디자인은 프로그램을 작고 독립적 인 모듈로 분할합니다. 이들은 아래에 표시된 세부 사항과 함께 하향식 방식으로 구성됩니다.

따라서 구조화 된 설계는 모듈화 또는 분해라는 접근 방식을 사용하여 복잡성을 최소화하고 문제를 더 작은 세그먼트로 세분화하여 관리합니다.

Advantages

• 중요한 인터페이스가 먼저 테스트됩니다.
• 추상화를 제공합니다.
• 여러 프로그래머가 동시에 작업 할 수 있습니다.
• 코드 재사용이 가능합니다.
• 통제력을 제공하고 사기를 향상시킵니다.
• 구조를 더 쉽게 식별 할 수 있습니다.

구조화 된 차트

구조화 된 차트는 시스템 개발의 다양한 모듈과 각 모듈 간의 관계를 정의하는 모듈 식 하향식 시스템을 설계하는 데 권장되는 도구입니다. 시스템 모듈과 이들 간의 관계를 보여줍니다.

모듈, 연결 화살표 또는 선을 나타내는 직사각형 상자로 구성된 다이어그램으로 구성됩니다.

• Control Module − 하위 모듈을 지시하는 상위 모듈입니다. subordinate modules.

• Library Module − 재사용 가능한 모듈이며 차트의 여러 지점에서 호출 할 수 있습니다.

구조화 된 차트를 디자인하는 방법은 두 가지입니다.

• Transform-Centered Structured Charts − 모든 트랜잭션이 동일한 경로를 따를 때 사용됩니다.

• Transaction–Centered Structured Charts − 모든 거래가 동일한 경로를 따르지 않을 때 사용됩니다.

구조 순서도 사용의 목적

• 하향식 디자인을 장려합니다.

• 모듈 개념을 지원하고 적절한 모듈을 식별합니다.

• 시스템의 크기와 복잡성을 보여줍니다.

• 각 기능 내에서 쉽게 식별 할 수있는 기능 및 모듈의 수를 식별합니다.

• 식별 가능한 각 기능이 관리 가능한 엔티티인지 또는 더 작은 구성 요소로 분할되어야하는지 여부를 나타냅니다.

시스템 복잡성에 영향을 미치는 요인

좋은 품질의 시스템 소프트웨어를 개발하려면 좋은 디자인을 개발해야합니다. 따라서 시스템 설계를 개발하는 동안 중점을 두는 것은 소프트웨어 설계의 품질입니다. 양질의 소프트웨어 설계는 소프트웨어 개발의 복잡성과 비용 지출을 최소화하는 것입니다.

시스템의 복잡성을 결정하는 데 도움이되는 시스템 개발과 관련된 두 가지 중요한 개념은 다음과 같습니다. coupling 과 cohesion.

커플 링

커플 링은 구성 요소의 독립성을 측정하는 것입니다. 시스템 개발의 각 모듈이 서로에 대한 종속성 정도를 정의합니다. 실제로 이것은 시스템에서 모듈 간의 결합이 강할수록 시스템을 구현하고 유지하는 것이 더 어려워집니다.

각 모듈은 다른 모듈과 간단하고 깔끔한 인터페이스를 가져야하며 최소한의 데이터 요소를 모듈간에 공유해야합니다.

높은 커플 링

이러한 유형의 시스템은 서로 종속 된 프로그램 단위와 상호 연결됩니다. 한 하위 시스템을 변경하면 다른 하위 시스템에 큰 영향을 미칩니다.

낮은 커플 링

이러한 유형의 시스템은 독립적이거나 거의 독립적 인 구성 요소로 구성됩니다. 한 하위 시스템의 변경은 다른 하위 시스템에 영향을주지 않습니다.

커플 링 측정

• Content Coupling − 한 구성 요소가 실제로 다른 구성 요소를 수정하면 수정 된 구성 요소는 완전히 하나의 수정에 의존합니다.

• Common Coupling − 공통 데이터 저장소에서 데이터에 액세스 할 수 있도록 시스템 설계를 구성하여 커플 링의 양을 다소 줄인 경우.

• Control Coupling − 한 구성 요소가 다른 구성 요소의 활동을 제어하기 위해 매개 변수를 전달하는 경우.

• Stamp Coupling − 데이터 구조가 한 구성 요소에서 다른 구성 요소로 정보를 전달하는 데 사용되는 경우.

• Data Coupling − 데이터 만 전달되면 구성 요소가이 커플 링으로 연결됩니다.

응집력

응집력은 구성 요소 간의 관계의 친밀 성을 측정하는 것입니다. 모듈 구성 요소가 서로에 대한 종속성의 양을 정의합니다. 실제로 이것은 시스템 설계자가 다음 사항을 확인해야 함을 의미합니다.

• 필수 프로세스를 조각난 모듈로 분할하지 않습니다.

• DFD에서 프로세스로 표현 된 관련없는 프로세스를 의미없는 모듈로 모으지 않습니다.

최고의 모듈은 기능적으로 응집 된 모듈입니다. 최악의 모듈은 우연히 응집 된 모듈입니다.

최악의 응집력

부품이 다른 부품과 관련이없는 구성 요소에서 우연한 응집력이 발견됩니다.

• Logical Cohesion − 논리적으로 관련된 여러 함수 또는 데이터 요소가 동일한 구성 요소에 배치되는 곳입니다.

• Temporal Cohesion − 시스템을 초기화하거나 변수를 설정하는 데 사용되는 컴포넌트가 여러 기능을 순차적으로 수행하지만 관련된 타이밍에 따라 기능이 관련되어있는 경우입니다.

• Procedurally Cohesion −이 순서를 보장하기 위해 함수가 구성 요소로 함께 그룹화되는 경우입니다.

• Sequential Cohesion − 컴포넌트의 한 부분에서 나온 출력이 다음 부분에 대한 입력일 때입니다.

입력 설계

정보 시스템에서 입력은 출력을 생성하기 위해 처리되는 원시 데이터입니다. 입력 설계 중에 개발자는 PC, MICR, OMR 등과 같은 입력 장치를 고려해야합니다.

따라서 시스템 입력의 품질이 시스템 출력의 품질을 결정합니다. 잘 설계된 입력 양식과 화면에는 다음과 같은 속성이 있습니다.

• 정보 저장, 기록 및 검색과 같은 특정 목적을 효과적으로 제공해야합니다.

• 정확한 완료를 보장합니다.

• 채우기 쉽고 간단해야합니다.

• 사용자의주의, 일관성 및 단순성에 중점을 두어야합니다.

• 이러한 모든 목표는 다음에 관한 기본 설계 원칙에 대한 지식을 사용하여 얻습니다.

  • 시스템에 필요한 입력은 무엇입니까?

  • 최종 사용자가 양식 및 화면의 다양한 요소에 반응하는 방법.

입력 설계의 목표

입력 설계의 목적은 다음과 같습니다.

• 데이터 입력 및 입력 절차를 설계하려면

• 입력 볼륨을 줄이려면

• 데이터 캡처를위한 소스 문서를 디자인하거나 다른 데이터 캡처 방법을 고안하려면

• 입력 데이터 기록, 데이터 입력 화면, 사용자 인터페이스 화면 등을 디자인합니다.

• 유효성 검사를 사용하고 효과적인 입력 제어를 개발합니다.

데이터 입력 방법

데이터 입력 중 오류를 방지하기 위해 적절한 데이터 입력 방법을 설계하는 것이 중요합니다. 이러한 방법은 고객이 양식에 데이터를 수동으로 입력하고 나중에 데이터 입력 운영자가 데이터를 입력하는지 또는 데이터를 사용자가 PC에 직접 입력하는지에 따라 다릅니다.

시스템은 다음과 같은 방법으로 사용자의 실수를 방지해야합니다.

• 읽기 쉬운 쓰기를위한 충분한 공간을 남겨서 명확한 양식 디자인.
• 양식을 작성하기위한 명확한 지침.
• 명확한 형태 디자인.
• 키 입력 감소.
• 즉각적인 오류 피드백.

인기있는 데이터 입력 방법 중 일부는 다음과 같습니다.

• 일괄 입력 방식 (오프라인 데이터 입력 방식)
• 온라인 데이터 입력 방법
• 컴퓨터에서 읽을 수있는 형식
• 대화 형 데이터 입력

입력 무결성 제어

입력 무결성 제어에는 최종 사용자의 일반적인 입력 오류를 제거하기위한 여러 방법이 포함됩니다. 또한 개별 필드의 값에 대한 검사도 포함됩니다. 모든 입력의 형식과 완전성을 위해.

데이터 입력 및 기타 시스템 작업에 대한 감사 추적은 오류 발생시 보안 및 복구 수단을 제공하기 위해 데이터베이스에 도입 된 모든 변경 사항에 대한 기록을 제공하는 트랜잭션 로그를 사용하여 생성됩니다.

출력 디자인

출력 설계는 모든 시스템에서 가장 중요한 작업입니다. 출력 설계 중에 개발자는 필요한 출력 유형을 식별하고 필요한 출력 제어 및 프로토 타입 보고서 레이아웃을 고려합니다.

출력 디자인의 목적

입력 설계의 목적은 다음과 같습니다.

• 의도 한 목적에 부합하고 원치 않는 출력의 생성을 제거하는 출력 설계를 개발합니다.

• 최종 사용자 요구 사항을 충족하는 출력 디자인을 개발합니다.

• 적절한 양의 출력을 제공합니다.

• 적절한 형식으로 출력을 구성하고 올바른 사람에게 전달합니다.

• 올바른 결정을 내리기 위해 제 시간에 출력을 사용할 수 있도록합니다.

이제 다양한 유형의 출력을 살펴 보겠습니다.

외부 출력

제조업체는 프린터 용 외부 출력을 만들고 설계합니다. 외부 출력을 통해 시스템은 수신자 측의 트리거 작업을 그대로 두거나 수신자에게 작업을 확인할 수 있습니다.

일부 외부 출력은 턴어라운드 출력으로 설계되어 양식으로 구현되고 시스템에 입력으로 다시 입력됩니다.

내부 출력

내부 출력은 시스템 내부에 있으며 최종 사용자와 관리자가 사용합니다. 그들은 의사 결정 및보고에서 경영진을 지원합니다.

관리 정보에 의해 생성되는 세 가지 유형의 보고서가 있습니다.

• Detailed Reports − 관리 계획 및 제어를 지원하기 위해 생성 된 필터링이나 제한이 거의없는 현재 정보를 포함합니다.

• Summary Reports − 여기에는 세부 정보를 원하지 않는 관리자를 위해 생성 된 분류 및 요약 된 추세와 잠재적 문제가 포함됩니다.

• Exception Reports − 여기에는 예외, 필터링 된 데이터가 관리자에게 정보로 제공되기 전에 특정 조건 또는 표준으로 필터링됩니다.

출력 무결성 제어

출력 무결성 제어에는 수신 시스템을 식별하는 라우팅 코드와 네트워크 프로토콜에서 처리되는 메시지의 성공적인 수신을 확인하는 확인 메시지가 포함됩니다.

인쇄 된 또는 화면 형식 보고서에는 보고서 인쇄를위한 날짜 / 시간 및 데이터가 포함되어야합니다. 여러 페이지 보고서에는 보고서 제목 또는 설명 및 페이지 매기기가 포함됩니다. 사전 인쇄 된 양식에는 일반적으로 버전 번호와 유효 날짜가 포함됩니다.

양식 디자인

양식과 보고서는 모두 입력 및 출력 디자인의 산물이며 지정된 데이터로 구성된 비즈니스 문서입니다. 주요 차이점은 양식은 데이터 입력을위한 필드를 제공하지만 보고서는 순수하게 읽기 용으로 사용된다는 것입니다. 예를 들어, 주문 양식, 고용 및 신용 신청 등

• 양식을 디자인하는 동안 디자이너는 알아야합니다.

  • 누가 그들을 사용할 것인가

  • 그들은 어디로 배달됩니까

  • 양식 또는 보고서의 목적

• 양식 디자인 중에 자동화 된 디자인 도구는 양식 및 보고서의 프로토 타입을 작성하고 평가를 위해 최종 사용자에게 제공하는 개발자의 능력을 향상시킵니다.

좋은 형태 디자인의 목적

다음을 보장하려면 좋은 양식 디자인이 필요합니다.

• 적절한 순서, 정보 및 명확한 캡션을 제공하여 화면을 단순하게 유지합니다.

• 적절한 양식을 사용하여 의도 된 목적을 충족합니다.

• 정확한 양식 완성을 보장합니다.

• 아이콘, 반전 비디오 또는 깜박이는 커서 등을 사용하여 양식을 매력적으로 유지합니다.

• 탐색을 용이하게하기 위해.

양식 유형

Flat Forms

• 수동 또는 기계로 준비하여 종이에 인쇄 한 단일 복사 양식입니다. 원본의 추가 사본의 경우 사본 사이에 카본지가 삽입됩니다.

• 디자인, 인쇄 및 재생산에 가장 간단하고 저렴한 형태로 적은 양을 사용합니다.

Unit Set/Snap out Forms

• 이들은 손으로 쓰거나 기계 사용을 위해 단위 세트에 일회성 탄소가 삽입 된 종이입니다.

• 탄소는 파란색 또는 검정색, 표준 등급 중간 강도 일 수 있습니다. 일반적으로 파란색 탄소는 손으로 쓴 양식에 가장 적합하고 검은 탄소는 기계 사용에 가장 적합합니다.

Continuous strip/Fanfold Forms

• 이들은 각 쌍의 양식 사이에 천공이있는 연속 스트립으로 결합 된 여러 단위 양식입니다.

• 대량 사용을위한 저렴한 방법입니다.

No Carbon Required (NCR) Paper

• 그들은 두 개의 화학적 코팅 (캡슐)이있는 탄소없는 종이를 사용하는데, 하나는 종이의 앞면에 다른 하나는 종이 뒷면에 있습니다.

• 압력이 가해지면 두 캡슐이 상호 작용하여 이미지를 만듭니다.

소프트웨어 시스템은 각 개발 단계에서 의도 된 동작과 진행 방향을 확인하여 노력의 중복, 시간 및 비용 초과를 방지하고 규정 된 시간 내에 시스템 완료를 보장해야합니다. 노력의 중복, 시간 및 비용 초과를 방지하고 규정 된 시간 내에 시스템 완료를 보장하기 위해 각 개발 단계에서 의도 된 동작 및 진행 방향.

시스템 테스트 및 품질 보증은 시스템 점검에 도움이됩니다. 그것은 포함합니다-

• 제품 수준 품질 (테스트)
• 프로세스 수준 품질.

간단히 살펴 보겠습니다.

테스팅

테스트는 시스템의 품질과 안정성을 향상시키기 위해 지정된 사용자 요구 사항에 따라 소프트웨어의 기능과 정확성을 확인하는 프로세스 또는 활동입니다. 전체 테스트 프로세스에 대한 적절한 계획이 필요한 시스템 개발에서 비용이 많이 들고 시간 소모적이며 중요한 접근 방식입니다.

성공적인 테스트는 오류를 찾는 테스트입니다. 오류를 찾기위한 명시적인 의도로 프로그램을 실행합니다. 즉, 프로그램을 실패시킵니다. 강력한 시스템을 만들려는 의도로 시스템을 평가하는 과정으로 주로 시스템이나 소프트웨어의 취약한 부분에 집중합니다.

시스템 테스트의 특성

시스템 테스트는 모듈 수준에서 시작하여 전체 소프트웨어 시스템 통합으로 진행됩니다. 시스템을 테스트하는 동안 다른 시간에 다른 테스트 기술이 사용됩니다. 소규모 프로젝트의 경우 개발자가, 대규모 프로젝트의 경우 독립 테스트 그룹에서 수행합니다.

시스템 테스트 단계

테스트에는 다음 단계가 포함됩니다.

Test Strategy

시스템 테스트에 사용되는 다양한 수준, 방법, 도구 및 기술에 대한 정보를 제공하는 설명입니다. 조직의 모든 요구를 충족시켜야합니다.

Test Plan

시스템 테스트 계획을 제공하고 테스트중인 시스템이 모든 설계 및 기능 사양을 충족하는지 확인합니다. 테스트 계획은 다음 정보를 제공합니다.

• 각 테스트 단계의 목표
• 테스트에 사용되는 접근 방식 및 도구
• 각 테스트 활동에 필요한 책임과 시간
• 도구, 시설 및 테스트 라이브러리의 가용성
• 테스트 계획 및 수행에 필요한 절차 및 표준
• 테스트 프로세스의 성공적인 완료를 담당하는 요소

Test Case Design

• 테스트 할 시스템의 각 모듈에 대해 여러 테스트 케이스가 식별됩니다.

• 각 테스트 사례는 특정 요구 사항 또는 설계 결정의 구현을 테스트하는 방법과 테스트 성공 기준을 지정합니다.

• 테스트 계획과 함께 테스트 사례는 시스템 사양 문서의 일부로 또는 별도의 문서로 문서화됩니다. test specification 또는 test description.

Test Procedures

각 테스트 케이스를 실행하기 위해 따라야하는 단계로 구성됩니다. 이러한 절차는 테스트 절차 사양이라는 별도의 문서에 지정되어 있습니다. 이 문서는 또한 테스트 결과를보고하기위한 특수 요구 사항 및 형식을 지정합니다.

Test Result Documentation

테스트 결과 파일에는 실행 된 총 테스트 케이스 수, 오류 수 및 오류 특성에 대한 간략한 정보가 포함되어 있습니다. 그런 다음 이러한 결과를 테스트 사양의 기준에 따라 평가하여 테스트의 전체 결과를 결정합니다.

테스트 유형

테스트는 다양한 유형이 될 수 있으며 발견하려는 버그의 종류에 따라 다양한 유형의 테스트가 수행됩니다.

단위 테스트

프로그램 테스트라고도하는 이는 분석가가 각 프로그램 또는 모듈을 독립적으로 테스트하거나 집중하는 테스트 유형입니다. 모듈의 각 문을 한 번 이상 실행하려는 의도로 수행됩니다.

• 단위 테스트에서는 프로그램의 정확성을 보장 할 수없고 다양한 입력 조합에 대한 세부적인 테스트를 수행하기 어렵습니다.

• 다른 테스트 기술과 비교하여 프로그램의 최대 오류를 식별합니다.

통합 테스트

통합 테스트에서 분석가는 함께 작동하는 여러 모듈을 테스트합니다. 시스템과 원래 목표, 현재 사양 및 시스템 문서 간의 불일치를 찾는 데 사용됩니다.

• 여기에서 분석가들은 데이터 길이, 유형 및 데이터 요소 이름에 대한 다양한 사양으로 모듈이 설계된 영역을 찾으려고합니다.

• 파일 크기가 적절하고 인덱스가 제대로 빌드되었는지 확인합니다.

기능 테스트

기능 테스트는 사양 및 관련 표준 문서에 따라 시스템이 올바르게 작동하는지 확인합니다. 기능 테스트는 일반적으로 시스템의 구현으로 시작되며 이는 시스템의 성공에 매우 중요합니다.

기능 테스트는 두 가지 범주로 나뉩니다.

• Positive Functional Testing − 생성 된 출력이 올바른지 확인하기 위해 유효한 입력으로 시스템을 테스트하는 것이 포함됩니다.

• Negative Functional Testing − 유효하지 않은 입력과 원하지 않는 작동 조건으로 소프트웨어를 테스트하는 것이 포함됩니다.

시스템 테스트 규칙

시스템 테스트를 성공적으로 수행하려면 주어진 규칙을 따라야합니다.

• 테스트는 사용자의 요구 사항을 기반으로해야합니다.

• 테스트 스크립트를 작성하기 전에 비즈니스 로직을 철저히 이해해야합니다.

• 테스트 계획은 가능한 한 빨리 이루어져야합니다.

• 테스트는 타사에서 수행해야합니다.

• 정적 소프트웨어에서 수행해야합니다.

• 유효하고 유효하지 않은 입력 조건에 대해 테스트를 수행해야합니다.

• 비용을 줄이기 위해 테스트를 검토하고 검사해야합니다.

• 정적 및 동적 테스트는 모두 소프트웨어에서 수행되어야합니다.

• 테스트 케이스와 테스트 결과를 문서화해야합니다.

품질 보증

시스템이 요구 사항 및 사양을 충족하는지 확인하기 위해 시스템 또는 소프트웨어 제품 및 해당 문서를 검토합니다.

• QA의 목적은 사양에 따라 제품을 지속적으로 배송하여 고객에게 신뢰를 제공하는 것입니다.

• 소프트웨어 품질 보증 (SQA)은 소프트웨어 전문가가 소프트웨어가 의도 된 사용 및 성능에 대해 지정된 표준을 충족하는지 확인하기 위해 적용하는 절차와 도구를 포함하는 기술입니다.

• SQA의 주요 목표는 소프트웨어 프로젝트 및 개발 된 제품에 대한 적절하고 정확한 가시성을 관리에 제공하는 것입니다.

• 시스템 개발 수명주기 동안 소프트웨어 제품 및 해당 활동을 검토하고 감사합니다.

품질 보증의 목적

품질 보증을 수행하는 목적은 다음과 같습니다.

• 소프트웨어 개발 프로세스 및 개발 된 최종 소프트웨어를 모니터링합니다.

• 소프트웨어 프로젝트가 경영진이 설정 한 표준 및 절차를 구현하고 있는지 확인합니다.

• 그룹 및 개인에게 SQA 활동 및 이러한 활동의 ​​결과에 대해 알립니다.

• 소프트웨어 내에서 해결되지 않은 문제는 상위 관리자가 해결하도록합니다.

• 제품, 프로세스 또는 표준의 결함을 식별하고 수정합니다.

품질 보증 수준

소프트웨어 제품을 인증하기 위해 수행해야하는 여러 수준의 QA 및 테스트가 있습니다.

Level 1 − Code Walk-through

이 수준에서 오프라인 소프트웨어는 공식 코딩 규칙 위반 여부를 검사하거나 확인합니다. 일반적으로 문서 및 코드 내 주석 수준을 검토하는 데 중점을 둡니다.

Level 2 − Compilation and Linking

이 수준에서 소프트웨어가 모든 공식 플랫폼 및 운영 체제를 컴파일하고 연결할 수 있는지 확인합니다.

Level 3 − Routine Running

이 수준에서는 일정 수의 이벤트, 크고 작은 이벤트 크기 등과 같은 다양한 조건에서 소프트웨어가 제대로 실행될 수 있는지 확인합니다.

Level 4 − Performance test

이 최종 단계에서 소프트웨어의 성능이 이전에 지정된 성능 수준을 충족하는지 확인합니다.

구현은 정보 시스템이 작동하는지 확인하는 프로세스입니다. 그것은 포함합니다-

• 처음부터 새로운 시스템 구축
• 기존 시스템에서 새로운 시스템을 구축합니다.

구현을 통해 사용자는 사용 및 평가를 위해 작업을 인수 할 수 있습니다. 사용자가 시스템을 처리하고 원활한 전환을 계획하도록 교육하는 것이 포함됩니다.

훈련

시스템의 직원은 자신의 역할이 무엇인지, 시스템을 어떻게 사용할 수 있는지, 시스템이 무엇을 할 것인지 안 할 것인지를 자세히 알아야합니다. 잘 설계되고 기술적으로 우아한 시스템의 성공 또는 실패는 작동 및 사용 방식에 따라 달라질 수 있습니다.

교육 시스템 운영자

시스템 운영자는 일상적이거나 비범 한 모든 가능한 작업을 처리 할 수 ​​있도록 적절한 교육을 받아야합니다. 운영자는 발생할 수있는 일반적인 오작동,이를 인식하는 방법 및 발생시 취해야 할 조치에 대해 교육을 받아야합니다.

교육에는 예상치 못한 문제 또는 비정상적인 문제가 발생할 때 연락 할 개인의 이름과 전화 번호뿐만 아니라 가능한 문제 및 해결 방법을 식별하기위한 문제 해결 목록 작성이 포함됩니다.

교육은 또한 새로운 시스템을 사용하는 데 필요한 일련의 활동을 통해 작업하는 실행 절차에 대한 숙지도 포함합니다.

사용자 교육

• 최종 사용자 교육은 컴퓨터 기반 정보 시스템 개발의 중요한 부분이며 직원이 스스로 문제를 해결할 수 있도록 제공해야합니다.

• 사용자 교육에는 장비 작동 방법, 시스템 문제 해결 방법, 발생한 문제가 장비 또는 소프트웨어로 인해 발생했는지 확인하는 방법이 포함됩니다.

• 대부분의 사용자 교육은 시스템 자체의 작동을 다룹니다. 교육 과정은 사용자가 조직을 위해 빠르게 동원 할 수 있도록 설계되어야합니다.

교육 지침

• 측정 가능한 목표 설정
• 적절한 훈련 방법 사용
• 적합한 교육 장소 선택
• 이해할 수있는 교육 자료 사용

훈련 방법

강사 주도 교육

동시에 만나야하지만 반드시 같은 장소에서 만나야하는 트레이너와 훈련생이 모두 포함됩니다. 교육 세션은 일대일 또는 공동 작업 일 수 있습니다. 그것은 두 가지 유형입니다-

Virtual Classroom

이 교육에서 강사는 교육생을 동시에 만나야하지만 같은 장소에있을 필요는 없습니다. 여기에 사용되는 기본 도구는 화상 회의, 텍스트 기반 인터넷 릴레이 채팅 도구 또는 가상 현실 패키지 등입니다.

Normal Classroom

트레이너는 훈련생을 동시에 같은 장소에서 만나야합니다. 여기에 사용되는 주요 도구는 칠판, 오버 헤드 프로젝터, LCD 프로젝터 등입니다.

자율 학습

여기에는 같은 장소에서 또는 동시에 만날 필요가없는 트레이너와 훈련생이 모두 포함됩니다. 연수생은 자신의 편의에 따라 과정에 액세스하여 기술을 스스로 배웁니다. 그것은 두 가지 유형입니다-

Multimedia Training

이 교육에서 코스는 멀티미디어 형식으로 제공되며 CD-ROM에 저장됩니다. 외부 프로그래머의 도움없이 사내 교육 과정을 개발하는 데 드는 비용을 최소화합니다.

Web-based Training

이 교육에서 코스는 종종 하이퍼 미디어 형식으로 제공되며 인터넷 및 인트라넷을 지원하도록 개발됩니다. 최종 사용자를위한 적시 교육을 제공하고 조직이 교육 요구 사항을 조정할 수 있도록합니다.

변환

이전 시스템에서 새 시스템으로 마이그레이션하는 프로세스입니다. 경영진과 프로젝트 팀 간의 의사 소통을 개선하기 위해 이해 가능하고 구조화 된 접근 방식을 제공합니다.

전환 계획

새 시스템을 구현하고 운영하는 동안 발생해야하는 모든 활동에 대한 설명이 포함되어 있습니다. 가능한 문제와 해결 방법을 예상합니다.

다음 활동이 포함됩니다.

• 변환 할 모든 파일의 이름을 지정하십시오.
• 변환 중에 새 파일을 개발하기위한 데이터 요구 사항 식별.
• 필요한 모든 새 문서와 절차를 나열합니다.
• 각 활동에서 사용할 제어를 식별합니다.
• 각 활동에 대한 사람의 책임을 식별합니다.
• 변환 일정을 확인합니다.

변환 방법

네 가지 변환 방법은 다음과 같습니다.

• 병렬 변환
• 직접 전환 변환
• 파일럿 접근
• 단계적 방법

방법	기술	장점	단점
병렬 변환	이전 시스템과 새 시스템이 동시에 사용됩니다.	새 시스템이 실패 할 때 대체 기능을 제공합니다. 최고의 보안을 제공하고 궁극적으로 새로운 시스템을 테스트합니다.	비용 초과를 유발합니다. 새로운 시스템은 공정한 흔적을 얻지 못할 수 있습니다.
직접 전환 변환	새로운 시스템이 구현되고 기존 시스템이 완전히 교체됩니다.	사용자가 새로운 시스템을 작동하도록합니다. 새로운 방법 및 제어의 즉각적인 이점.	새 시스템에 문제가 발생해도 대체되지 않습니다. 가장 신중한 계획이 필요합니다.
파일럿 접근	모든 사용자에게 시스템을 점진적으로 구현하는 단계별 접근 방식 지원	불필요한 리소스 사용없이 교육 및 설치가 가능합니다. 위험 관리로 인한 큰 우발적 상황을 피하십시오.	장기간의 페이즈 인은 전환이 잘 진행되는지 여부에 대한 문제를 야기합니다.
단계적 방법	피드백을 기반으로 조직의 한 부분에 구현 된 시스템의 작동 버전은 조직 전체에 단독으로 또는 단계별로 설치됩니다.	구현 전 경험 및 라인 테스트 제공 선호하는 새로운 시스템이 새로운 기술이나 성능의 급격한 변화를 포함하는 경우.	오래된 시스템이 잘못되어 신뢰할 수 없다는 인상을줍니다.

파일 변환

하나의 파일 형식을 다른 파일 형식으로 변환하는 과정입니다. 예를 들어 WordPerfect 형식의 파일을 Microsoft Word로 변환 할 수 있습니다.

성공적인 변환을 위해서는 다음을 포함하는 변환 계획이 필요합니다.

• 대상 시스템에 대한 지식과 현재 시스템에 대한 이해
• Teamwork
• 자동화 된 방법, 테스트 및 병렬 작업
• 문제 해결을위한 지속적인 지원
• 시스템 / 사용자 문서 등 업데이트

널리 사용되는 많은 응용 프로그램은 동일한 유형의 다른 파일 형식 열기 및 저장을 지원합니다. 예를 들어, Microsoft Word는 다른 많은 워드 프로세싱 형식으로 파일을 열고 저장할 수 있습니다.

구현 후 평가 검토 (PIER)

PIER는 프로젝트의 결과를 평가하고 프로젝트가 프로세스, 제품 또는 서비스에 기대되는 이점을 제공하는지 여부를 결정하기위한 도구 또는 표준 접근 방식입니다. 이를 통해 사용자는 프로젝트 또는 시스템이 지정된 기간 및 계획된 비용 내에 원하는 결과를 얻었는지 확인할 수 있습니다.

PIER는 프로젝트의 개발 및 관리 프로세스를 평가하여 프로젝트가 목표를 달성했는지 확인합니다.

PIER의 목표

PIER를 갖는 목적은 다음과 같습니다.

• 예상 비용, 이점 및 일정에 대한 프로젝트의 성공 여부를 결정합니다.

• 프로젝트에 추가 가치를 추가 할 기회를 식별합니다.

• 향후 참조 및 적절한 조치를 위해 프로젝트의 강점과 약점을 결정합니다.

• 비용 추정 기술을 개선하여 프로젝트의 미래에 대한 권장 사항을 작성합니다.

검토 과정에는 다음과 같은 직원이 포함되어야합니다.

• 프로젝트 팀 및 관리
• 사용자 직원
• 전략적 관리 직원
• 외부 사용자

시스템 유지 관리 / 향상

유지 관리는 무언가를 원래 상태로 복원하는 것을 의미합니다. 향상은 사용자 사양의 변경을 지원하기 위해 코드를 추가하고 수정하는 것을 의미합니다. 시스템 유지 관리는 시스템을 원래 요구 사항에 맞추고 향상된 기능은 새로운 요구 사항을 통합하여 시스템 기능을 추가합니다.

따라서 유지 보수는 기존 시스템을 변경하고 향상은 기존 시스템에 기능을 추가하며 개발은 기존 시스템을 대체합니다. 시스템 설계 및 구현의 오류를 수정하고 문서를 업데이트하며 데이터를 테스트하는 활동을 포함하는 시스템 개발의 중요한 부분입니다.

유지 관리 유형

시스템 유지 보수는 세 가지 유형으로 분류 할 수 있습니다.

• Corrective Maintenance − 사용자가 남은 문제를 수리하고 수정할 수 있습니다.

• Adaptive Maintenance − 사용자가 프로그램의 기능을 대체 할 수 있습니다.

• Perfective Maintenance − 사용자의 요구 사항과 변화하는 요구 사항에 따라 사용자가 프로그램을 수정하거나 향상시킬 수 있습니다.

시스템 감사

운영 시스템의 성능을 검토하기위한 조사입니다. 시스템 감사를 수행하는 목적은 다음과 같습니다.

• 실제 및 계획된 성능을 비교합니다.

• 명시된 시스템 목표가 현재 환경에서 여전히 유효한지 확인합니다.

• 명시된 목표의 달성을 평가합니다.

• 컴퓨터 기반 재무 및 기타 정보의 신뢰성을 보장합니다.

• 처리하는 동안 모든 기록이 포함되도록합니다.

• 사기로부터 보호하기 위해.

컴퓨터 시스템 사용 감사

데이터 처리 감사자는 컴퓨터 시스템을 제어하기 위해 사용을 감사합니다. 감사인은 컴퓨터 시스템 자체에서 얻은 제어 데이터가 필요합니다.

시스템 감사 자

감사 자의 역할은 시스템 개발의 초기 단계에서 시작되어 결과 시스템이 안전합니다. 로드 계획 및 하드웨어 및 소프트웨어 사양 결정에 도움이되는 기록 할 수있는 시스템의 활용 아이디어를 설명합니다. 컴퓨터 시스템의 현명한 사용과 시스템의 오용 가능성을 나타냅니다.

감사 재판

감사 시도 또는 감사 로그는 컴퓨터 시스템에 액세스 한 사람과 주어진 기간 동안 수행 된 작업으로 구성된 보안 레코드입니다. 감사 시도는 시스템의 데이터가 어떻게 변경되었는지에 대한 자세한 추적을 수행하는 데 사용됩니다.

거래가 처리되는 동안 적용되는 다양한 제어 기술에 대한 문서 증거를 제공합니다. 감사 재판은 독립적으로 존재하지 않습니다. 손실 된 거래를 복구하기위한 회계의 일부로 수행됩니다.

감사 방법

감사는 두 가지 방법으로 수행 할 수 있습니다.

컴퓨터 주변 감사

• 샘플 입력을 받아 처리 규칙을 수동으로 적용합니다.
• 출력을 컴퓨터 출력과 비교합니다.

컴퓨터를 통한 감사

• 선택한 중간 결과를 검토 할 수있는 감사 시험을 설정합니다.
• 통제 합계는 중간 점검을 제공합니다.

감사 고려 사항

감사 고려 사항은 설명과 모델을 모두 사용하여 잘못된 기능, 분할 된 프로세스 또는 기능, 손상된 데이터 흐름, 누락 된 데이터, 중복되거나 불완전한 처리 및 주소 지정되지 않은 자동화 기회로 인해 발생하는 문제를 식별함으로써 분석 결과를 검사합니다.

이 단계의 활동은 다음과 같습니다.

• 현재 환경 문제 식별
• 문제 원인 식별
• 대체 솔루션 식별
• 각 솔루션의 평가 및 타당성 분석
• 가장 실용적이고 적절한 솔루션 선택 및 추천
• 프로젝트 비용 추정 및 비용 편익 분석

보안

시스템 보안은 도난, 무단 액세스 및 수정, 우발적 또는 의도하지 않은 손상으로부터 시스템을 보호하는 것을 말합니다. 컴퓨터 화 된 시스템에서 보안은 데이터, 소프트웨어 및 하드웨어를 포함하는 컴퓨터 시스템의 모든 부분을 보호하는 것을 포함합니다. 시스템 보안에는 시스템 개인 정보 보호 및 시스템 무결성이 포함됩니다.

• System privacy 관련 개인의 허가 / 지식없이 개인 시스템에 액세스하고 사용하지 못하도록 보호합니다.

• System integrity 시스템에서 처리 된 원시 데이터와 처리 된 데이터의 품질과 신뢰성과 관련이 있습니다.

통제 조치

다음과 같이 광범위하게 분류 할 수있는 다양한 제어 조치가 있습니다.

지원

• 시간 중요도와 크기에 따라 매일 / 매주 정기적으로 데이터베이스를 백업합니다.

• 더 짧은 간격으로 증분 백업.

• 특히 재해 복구에 필요한 안전한 원격 위치에 백업 복사본을 보관합니다.

• 매우 중요한 시스템이고 디스크에 저장하기 전에 중단을 허용 할 수없는 경우 중복 시스템이 실행되고 모든 트랜잭션이 미러링됩니다.

시설에 대한 물리적 액세스 제어

• 물리적 잠금 및 생체 인증. 예 : 지문
• 보안 직원이 신분증 또는 출입증을 확인합니다.
• 데이터를 읽거나 수정하고 파일에 기록하는 모든 사람의 식별.

논리 또는 소프트웨어 제어 사용

• 암호 시스템.
• 민감한 데이터 / 프로그램 암호화.
• 데이터 관리 / 취급 및 보안에 대한 직원 교육.
• 인터넷에 연결된 동안 바이러스 백신 소프트웨어 및 방화벽 보호.

위험도 분석

위험은 가치있는 것을 잃을 가능성입니다. 위험 분석은 시스템의 취약성과 이로 인한 영향을 식별하여 보안 시스템을 계획하는 것으로 시작됩니다. 그런 다음 위험을 관리하고 재난에 대처하기위한 계획을 세웁니다. 재난 가능성과 그 비용에 접근하기 위해 수행됩니다.

위험 분석은 화학 물질, 인적 오류 및 공정 장비와 같은 다양한 배경을 가진 전문가의 팀워크입니다.

위험 분석을 수행하는 동안 다음 단계를 따라야합니다.

• 컴퓨터 시스템의 모든 구성 요소 식별.

• 각 구성 요소가 직면하는 모든 위협 및 위험 식별.

• 위험을 정량화합니다. 즉, 위협이 현실화되는 경우 손실 평가.

위험 분석 – 주요 단계

위험이나 위협이 변화하고 잠재적 손실도 변화함에 따라 위험 관리는 고위 관리자가 주기적으로 수행해야합니다.

위험 관리는 지속적인 프로세스이며 다음 단계를 포함합니다.

• 보안 조치 식별.

• 보안 조치 구현 비용 계산.

• 보안 조치 비용과 위협의 손실 및 확률 비교.

• 보안 조치의 선택 및 구현.

• 보안 조치의 구현 검토.

객체 지향 접근 방식에서는 정보 시스템의 구조와 동작을 데이터와 프로세스를 결합하는 작은 모듈로 캡처하는 데 중점을 둡니다. 객체 지향 설계 (OOD)의 주요 목적은 시스템 분석 및 설계를보다 유용하게 만들어 품질과 생산성을 향상시키는 것입니다.

분석 단계에서는 OO 모델을 사용하여 문제와 솔루션 사이의 간격을 메 웁니다. 시스템이 지속적으로 설계, 조정 및 유지 관리되는 상황에서 잘 작동합니다. 문제 영역에서 개체를 식별하고 데이터 및 동작 측면에서 분류합니다.

OO 모델은 다음과 같은 이점이 있습니다.

• 저비용으로 시스템 변경을 용이하게합니다.

• 구성 요소의 재사용을 촉진합니다.

• 대형 시스템을 구성하기 위해 구성 요소를 통합하는 문제를 단순화합니다.

• 분산 시스템의 설계를 단순화합니다.

객체 지향 시스템의 요소

OO 시스템의 특징을 살펴 보겠습니다.

• Objects− 객체는 문제 영역 내에 존재하며 데이터 (속성) 또는 행동으로 식별 할 수있는 것입니다. 모든 유형의 개체 (학생, 환자) 및 일부 무형 개체 (은행 계좌)는 개체로 모델링됩니다.

• Attributes − 물체에 대한 정보를 설명합니다.

• Behavior− 개체가 할 수있는 작업을 지정합니다. 개체에 대해 수행되는 작업을 정의합니다.

• Class− 클래스는 데이터와 그 동작을 캡슐화합니다. 유사한 의미와 목적을 가진 객체가 클래스로 그룹화됩니다.

• Methods− 메서드는 클래스의 동작을 결정합니다. 그것들은 객체가 수행 할 수있는 행동 일뿐입니다.

• Message− 메시지는 한 개체에서 다른 개체로의 함수 또는 프로 시저 호출입니다. 메서드를 트리거하기 위해 개체로 전송되는 정보입니다. 기본적으로 메시지는 한 개체에서 다른 개체로의 함수 또는 프로 시저 호출입니다.

객체 지향 시스템의 특징

객체 지향 시스템에는 아래에서 설명하는 몇 가지 훌륭한 기능이 있습니다.

캡슐화

캡슐화는 정보를 숨기는 과정입니다. 프로세스와 데이터를 단일 엔티티로 결합한 것입니다. 개체의 데이터는 시스템의 나머지 부분에서 숨겨지며 클래스의 서비스를 통해서만 사용할 수 있습니다. 시스템의 다른 부분에 영향을주지 않고 객체가 사용하는 방법을 개선하거나 수정할 수 있습니다.

추출

객체를 지정하기 위해 필요한 방법과 속성을 취하거나 선택하는 과정입니다. 사용자의 관점과 관련된 사물의 본질적인 특성에 초점을 맞 춥니 다.

관계

시스템의 모든 클래스는 서로 관련되어 있습니다. 개체는 분리되어 존재하지 않으며 다른 개체와의 관계로 존재합니다.

객체 관계에는 세 가지 유형이 있습니다.

• Aggregation − 전체와 부분의 관계를 나타냅니다.

• Association − 여기에서 한 클래스가 다른 클래스와 작업을 수행하거나 한 클래스가 다른 클래스에 대해 작동하는 것과 같이 두 클래스가 관련되거나 연결됩니다.

• Generalization− 하위 클래스는 상위 클래스를 기반으로합니다. 두 클래스가 비슷하지만 약간의 차이가 있음을 나타냅니다.

계승

상속은 기존 클래스의 속성 및 / 또는 작업을 상속하여 기존 클래스에서 하위 클래스를 만들 수있는 훌륭한 기능입니다.

다형성 및 동적 바인딩

다형성은 다양한 형태를 취할 수있는 능력입니다. 객체와 작업 모두에 적용됩니다. 다형성 객체는 진정한 유형이 수퍼 또는 부모 클래스 내에 숨겨지는 객체입니다.

다형성 연산에서 연산은 객체의 다른 클래스에 의해 다르게 수행 될 수 있습니다. 그것은 우리가 그들의 공통 속성만을 알고 다른 클래스의 객체를 조작 할 수있게합니다.

구조적 접근법 대. 객체 지향 접근법

다음 표는 객체 지향 접근 방식이 기존의 구조적 접근 방식과 어떻게 다른지 설명합니다.

구조화 된 접근 방식	객체 지향 접근
하향식 접근 방식으로 작동합니다.	상향식 접근 방식으로 작동합니다.
프로그램은 서브 모듈 또는 기능의 수로 나뉩니다.	프로그램은 클래스와 객체의 수로 구성됩니다.
함수 호출이 사용됩니다.	메시지 전달이 사용됩니다.
소프트웨어 재사용은 불가능합니다.	재사용이 가능합니다.
구조화 된 디자인 프로그래밍은 일반적으로 마지막 단계까지 남아 있습니다.	다른 단계와 동시에 수행되는 객체 지향 디자인 프로그래밍.
구조화 된 디자인은 오프 쇼링에 더 적합합니다.	자체 개발에 적합합니다.
디자인에서 구현으로의 명확한 전환을 보여줍니다.	설계에서 구현으로의 전환이 명확하지 않습니다.
실시간 시스템, 임베디드 시스템 및 객체가 가장 유용한 추상화 수준이 아닌 프로젝트에 적합합니다.	사용자 정의 또는 확장이 예상되는 대부분의 비즈니스 응용 프로그램, 게임 개발 프로젝트에 적합합니다.
DFD 및 ER 다이어그램은 데이터를 모델링합니다.	클래스 다이어그램, 시퀀스 다이어그램, 상태 차트 다이어그램 및 사용 사례가 모두 기여합니다.
이를 통해 명확하게 식별 가능한 단계로 인해 프로젝트를 쉽게 관리 할 수 ​​있습니다.	이 접근 방식에서는 단계 간의 불확실한 전환으로 인해 프로젝트를 관리하기 어려울 수 있습니다.

통합 모델링 언어 (UML)

UML은 프로세스, 소프트웨어 및 시스템을 모델링하여 시스템 아키텍처의 디자인을 표현할 수있는 시각적 언어입니다. 기술 설계자가 개발자와 통신 할 수 있도록 객체 지향 방식으로 시스템을 설계하고 문서화하기위한 표준 언어입니다.

Object Management Group에서 생성 및 배포하는 일련의 사양으로 정의됩니다. UML은 확장 가능하고 확장 가능합니다.

UML의 목적은 분석에서 구현에 이르기까지 모든 시스템 개발 프로젝트를 모델링 할 수있을만큼 풍부한 객체 지향 용어 및 다이어그램 기법의 공통 어휘를 제공하는 것입니다.

UML은-

• Diagrams − 프로세스, 시스템 또는 그 일부를 그림으로 표현한 것입니다.

• Notations − 커넥터, 기호, 메모 등과 같이 다이어그램에서 함께 작동하는 요소로 구성됩니다.

클래스에 대한 UML 표기법의 예

인스턴스 다이어그램 -UML 표기법

개체에 대해 수행되는 작업

다음 작업은 객체에서 수행됩니다-

• Constructor/Destructor− 클래스의 새 인스턴스 생성 및 클래스의 기존 인스턴스 삭제. 예를 들어, 새 직원 추가.

• Query− 값을 변경하지 않고 상태에 액세스하면 부작용이 없습니다. 예를 들어 특정 직원의 주소 찾기.

• Update − 하나 이상의 속성 값을 변경하고 개체 상태에 영향을줍니다. 예를 들어 직원의 주소를 변경합니다.

UML의 사용

UML은 다음과 같은 목적에 매우 유용합니다.

• 비즈니스 프로세스 모델링
• 시스템 아키텍처 설명
• 응용 프로그램 구조 표시
• 시스템 동작 캡처
• 데이터 구조 모델링
• 시스템 세부 사양 구축
• 아이디어 스케치
• 프로그램 코드 생성

정적 모델

정적 모델은 시스템의 구조적 특성을 보여주고 시스템 구조를 설명하며 시스템을 구성하는 부분을 강조합니다.

• 클래스 이름, 속성, 메서드, 서명 및 패키지를 정의하는 데 사용됩니다.

• 정적 모델을 나타내는 UML 다이어그램에는 클래스 다이어그램, 오브젝트 다이어그램 및 사용 사례 다이어그램이 포함됩니다.

동적 모델

동적 모델은 시스템의 동작 특성, 즉 시스템이 외부 이벤트에 응답하여 동작하는 방식을 보여줍니다.

• 동적 모델은 필요한 개체와 메서드 및 메시지를 통해 함께 작동하는 방식을 식별합니다.

• 시스템의 논리와 동작을 설계하는 데 사용됩니다.

• UML 다이어그램은 시퀀스 다이어그램, 통신 다이어그램, 상태 다이어그램, 활동 다이어그램을 포함하는 동적 모델을 나타냅니다.

객체 지향 시스템 개발 라이프 사이클

세 가지 매크로 프로세스로 구성됩니다.

• 객체 지향 분석 (OOA)
• 객체 지향 설계 (OOD)
• 객체 지향 구현 (OOI)

객체 지향 시스템 개발 활동

객체 지향 시스템 개발에는 다음 단계가 포함됩니다.

• 객체 지향 분석
• 객체 지향 디자인
• Prototyping
• Implementation
• 증분 테스트

객체 지향 분석

이 단계는 시스템 요구 사항을 결정하고 시스템 요구 사항을 이해하는 것과 관련이 있습니다. use-case model. 사용 사례는 사용자와 컴퓨터 시스템 간의 상호 작용을 설명하는 시나리오입니다. 이 모델은 시스템의 사용자 요구 또는 사용자보기를 나타냅니다.

또한 응용 프로그램을 구성하는 문제 도메인의 다른 클래스와의 관계 및 클래스 식별도 포함됩니다.

객체 지향 디자인

이 단계의 목표는 분석 단계, 사용자 인터페이스 및 데이터 액세스 중에 식별되는 클래스, 속성, 메서드 및 구조를 설계하고 구체화하는 것입니다. 이 단계에서는 요구 사항 구현을 지원하는 추가 클래스 또는 개체도 식별하고 정의합니다.

프로토 타이핑

프로토 타이핑을 통해 시스템의 일부 기능을 구현하는 것이 얼마나 쉬운 지 또는 어려운지 완전히 이해할 수 있습니다.

또한 사용자에게 디자인의 유용성과 유용성에 대해 언급 할 수있는 기회를 제공합니다. 유스 케이스를 추가로 정의하고 유스 케이스 모델링을 훨씬 쉽게 만들 수 있습니다.

이행

CBD (Component-Based Development) 또는 RAD (Rapid Application Development)를 사용합니다.

구성 요소 기반 개발 (CBD)

CODD는 CASE 도구와 같은 다양한 기술을 사용하여 소프트웨어 개발 프로세스에 대한 산업화 된 접근 방식입니다. 응용 프로그램 개발은 사용자 지정 개발에서 서로 작동하는 사전 구축되고 사전 테스트 된 재사용 가능한 소프트웨어 구성 요소의 어셈블리로 이동합니다. CBD 개발자는 구성 요소를 조립하여 완전한 소프트웨어 시스템을 구성 할 수 있습니다.

신속한 애플리케이션 개발 (RAD)

RAD는 기존 방법으로 일반적으로 가능한 것보다 더 빠르게 애플리케이션을 빌드하는 데 사용할 수있는 도구 및 기술 세트입니다. SDLC를 대체하지는 않지만 프로세스 설명에 더 초점을 맞추고 객체 지향 접근 방식과 완벽하게 결합 할 수 있기 때문에이를 보완합니다.

그 임무는 비주얼 베이직, 파워 빌더 등과 같은 도구를 통해 사용자 요구 사항 디자인을 빠르고 점진적으로 구현하는 것입니다.

증분 테스트

소프트웨어 개발 및 테스트를 포함한 모든 활동은 반복적 인 프로세스입니다. 따라서 제품 개발이 완료된 후에 만 ​​제품 테스트를 기다리면 비용이 많이들 수 있습니다. 여기에서는 제품 개발의 다양한 단계에서 제품을 테스트하는 증분 테스트가 나타납니다.