집 > 야금

디자인 중 고객과의 내부 상호 작용. 고객 및 계약자 - 프로젝트 성공의 기반이 되는 관계

고객과의 일반적인 상호 작용 단계는 다음과 같습니다.

  • - 고객과의 사전 커뮤니케이션: 프로젝트의 목표 및 목표 식별, 향후 시스템의 주요 요구 사항 식별, 고객 회사와의 사전 친분, 프로젝트 시기 및 비용에 대한 사전 평가, 상업 제안 준비 및 이전 고객에게.
  • - 고객 요구 사항에 대한 상세 조사 및 수집: 프로젝트 팀 구성 결정, 시스템 요구 사항 수집, 고객의 주요 사용자 및 기술 전문가 인터뷰, 위임 사항 개발 및 승인.
  • - 시스템 개발 및 테스트: 시스템 또는 기능의 특정 부분이 개발된 후 고객에게 데모가 수행됩니다. 그런 다음 오류가 없는 경우 오류를 감지하고 제거하는 단계, 승인 테스트가 이어집니다.
  • - 시스템 시범운영 : 고객측 시스템 전개, 사용자 교육, 시스템 개선을 위한 의견수렴 및 건의사항, 의견삭제
  • - 시스템의 산업적 운영: 고객에 의한 독립적인 운영, 회사의 지원 서비스에 연락(필요한 경우), 시스템 개발을 위한 희망 사항 수집.

고객과의 상호 작용의 중요한 형태는 GOST 34 및 RUP의 요구 사항에 따라 프로젝트 구현 중에 개발된 문서입니다.

작업 그룹은 특정 프로젝트 작업을 위해 구성됩니다. 작업의 동기화는 작업 그룹의 대표자 협의회를 통해 수행됩니다. 실무 그룹의 구성원은 그룹 내에서 상호 작용의 원칙을 독립적으로 개발합니다. 그룹은 문제 해결에 다른 그룹의 구성원을 참여시킬 수 있습니다. 새로운 프로젝트 참가자는 그룹 내 및 그룹 간의 성공적인 상호 작용 형식을 채택할 수 있습니다.

세계는 오랫동안 프로젝트 관리가 실질적인 결과를 제공하는 특별한 관리 영역이라는 것을 인식해 왔습니다. 이 분야의 전문가는 매우 가치가 높으며(미국에서는 변호사와 의사 다음으로 급여가 세 번째로 높은 직업임) 프로젝트 관리 방법론 자체가 수천 개의 기업에서 사실상의 관리 표준이 되었으며 다양한 분야에서 사용됩니다. 거의 모든 대기업. 작년에 ANSI 프로젝트 관리 표준이 채택되었고 ISO 10006 프로젝트 관리 표준 초안이 개발되었습니다.

오늘날 복잡한 소프트웨어 애플리케이션을 만드는 프로세스는 수명 주기 단계로 나누지 않고는 상상할 수 없습니다. 프로그램의 수명 주기에서 우리는 일련의 단계를 의미합니다.

  • 주제 영역 분석 및 기술 사양 작성(고객과의 상호 작용)
  • 프로그램 구조 설계
  • 코딩(프로젝트 문서에 따른 프로그램 코드 세트)
  • 테스트 및 디버깅
  • 프로그램 구현
  • 프로그램 지원
  • 처분
디자인 프로세스를 자세히 살펴보겠습니다. 설계 과정에서 설계자 또는 숙련된 프로그래머는 향후 프로그램의 텍스트 설명, 다이어그램 및 모델을 포함하는 프로젝트 문서를 작성합니다. 이 어려운 문제에서 UML 언어가 도움이 될 것입니다.

UML은 다양한 시스템(특히 프로그램)의 시각화, 매개변수 설명, 설계 및 문서화를 위한 그래픽 언어입니다. 다이어그램은 Rational Rose(http://www-01.ibm.com/software/rational/) 및 Enterprise Architect(http://www.sparxsystems.com.au/)와 같은 특수 CASE 도구를 사용하여 생성됩니다. 단일 정보 모델은 UML 기술을 기반으로 구축됩니다. 위의 CASE 도구는 다양한 객체 지향 언어로 코드를 생성할 수 있으며 매우 유용한 리버스 엔지니어링 기능도 있습니다. (리버스 엔지니어링을 사용하면 기존 프로그램 코드와 주석에서 그래픽 모델을 만들 수 있습니다.)

모델을 시각화하기 위한 다이어그램 유형을 고려하십시오(더 많은 유형이 있지만 필수 항목임).

사용 사례 다이어그램

설계된 시스템은 소위 선례를 사용하여 시스템과 상호 작용하는 일련의 엔티티 또는 행위자로 표현됩니다. 이 경우 행위자(actor) 또는 행위자는 외부에서 시스템과 상호 작용하는 모든 개체입니다. 즉, 각 사용 사례는 액터와 대화할 때 시스템이 수행하는 특정 작업 집합을 정의합니다. 동시에 액터와 시스템의 상호 작용이 어떻게 구현될 것인지에 대해서는 언급된 바가 없습니다.

클래스 다이어그램(클래스 다이어그램)

클래스 다이어그램은 객체 지향 프로그래밍 클래스의 용어로 시스템 모델의 정적 구조를 나타내는 역할을 합니다. 클래스 다이어그램은 특히 개체 및 하위 시스템과 같은 주제 영역의 개별 엔터티 간의 다양한 관계를 반영할 수 있으며 내부 구조(필드, 메서드 ...) 및 관계 유형(상속, 인터페이스 구현 . ..). 이 다이어그램은 시스템 작동의 시간 측면에 대한 정보를 제공하지 않습니다. 이러한 관점에서 클래스 다이어그램은 설계된 시스템의 개념적 모델을 더욱 발전시킨 것입니다. 이 단계에서는 OOP 접근 방식과 디자인 패턴에 대한 지식이 필수적입니다.

상태 다이어그램(statechart 다이어그램)

이 다이어그램의 주요 목적은 수명 주기 동안 모델 요소의 동작을 함께 특성화하는 상태 및 전환의 가능한 시퀀스를 설명하는 것입니다. 상태 다이어그램은 일부 특정 이벤트의 인식에 대한 응답 사양을 기반으로 엔터티의 동적 동작을 나타냅니다.

시퀀스 다이어그램

적절한 상호 작용 다이어그램은 UML 언어로 개체의 상호 작용을 모델링하는 데 사용됩니다. 객체의 상호 작용은 시간적으로 고려될 수 있으며 시퀀스 다이어그램은 객체 간의 메시지 전송 및 수신 타이밍을 나타내는 데 사용됩니다. 상호 작용하는 개체는 서로 일부 정보를 교환합니다. 이 경우 정보는 완전한 메시지 형식을 취합니다. 즉, 메시지는 정보 내용을 포함하고 있지만 수신자에게 직접적인 영향을 미치는 추가 속성을 획득합니다.

협업 다이어그램

협력 다이어그램에서 상호 작용에 참여하는 개체는 개체 이름, 해당 클래스 및 속성 값을 포함하는 사각형 형태로 표시됩니다. 클래스 다이어그램에서와 같이 객체 간의 연관성은 다양한 연결선의 형태로 표시됩니다. 이 경우 연결 이름과 이 연결에서 개체가 수행하는 역할을 명시적으로 지정할 수 있습니다.
시퀀스 다이어그램과 달리 협업 다이어그램은 상호 작용에서 특정 역할을 수행하는 개체 간의 관계만 묘사합니다.

구성 요소 다이어그램

컴포넌트 다이어그램은 앞에서 설명한 다이어그램과 달리 시스템의 물리적 표현 기능을 설명합니다. 구성 요소 다이어그램을 사용하면 소스, 이진 및 실행 코드일 수 있는 소프트웨어 구성 요소 간의 종속성을 설정하여 개발 중인 시스템의 아키텍처를 결정할 수 있습니다. 많은 개발 환경에서 모듈 또는 구성 요소는 파일에 해당합니다. 모듈을 연결하는 점선 화살표는 프로그램 소스 코드를 컴파일할 때 발생하는 것과 유사한 종속 관계를 나타냅니다. 구성 요소 다이어그램의 주요 그래픽 요소는 구성 요소, 인터페이스 및 이들 간의 종속성입니다.

배포 다이어그램

배포 다이어그램은 실행 단계(런타임)에만 존재하는 프로그램의 요소와 구성 요소를 시각화하도록 설계되었습니다. 이 경우 실행 파일 또는 동적 라이브러리인 프로그램 인스턴스 구성 요소만 표시됩니다. 런타임에 사용되지 않는 구성 요소는 배포 다이어그램에 표시되지 않습니다.
배포 다이어그램에는 프로세서, 장치, 프로세스 및 이들 간의 관계에 대한 그래픽 표현이 포함되어 있습니다. 논리적 표현 다이어그램과 달리 배치 다이어그램은 구현 기능을 완전히 반영해야 하므로 시스템 전체에서 동일합니다. 이 다이어그램은 본질적으로 특정 소프트웨어 시스템에 대한 OOAP 프로세스를 완료하며 해당 개발은 일반적으로 모델 사양의 마지막 단계입니다.

이것으로 특정 다이어그램과 일반적인 디자인에 대한 개요를 마칩니다. 디자인 프로세스가 오랫동안 소프트웨어 개발 표준이 되었다는 점은 주목할 가치가 있지만 적절한 문서가 부족하여 불필요한 측면 기능, 목발을 획득하고 번거롭고 손실되는 아름답게 작성된 프로그램을 처리해야 하는 경우가 많습니다. 이전 품질. =(

나는 프로그래머가 주로 코더라고 확신합니다. 그는 고객과 의사 소통해서는 안되며 시스템 아키텍처에 대해 생각해서는 안되며 프로그램에 대한 인터페이스를 발명해서는 안되며 코딩 만해야합니다-알고리즘, 기능, 외관, 유용성, 그러나 더 이상 .... 디자이너는 추상 다이어그램(주제 영역 설명)에서 시작하여 데이터 구조, 클래스 및 상호 작용 프로세스를 나타내는 다이어그램에 이르기까지 모든 것을 단계별로 자세히 설명해야 합니다. 즉, 작업의 복잡성과 디자이너의 급여는 프로그래머 == 코더보다 훨씬 높아야 합니다. 욕설 죄송합니다....

1.1. 고객과의 교류(주요기능)

1.1.1. 주문 검색

    7.2.3.1. 제품 정보

1.1.2. 고객과의 사전 계약 작업

규제 문서

    2.2.1.2.1. 고객 STP-1-01과의 사전 계약 작업

ISO9000:2000 품질경영시스템 요구사항 7항

    7.2.1.1. 가용성, 배송 및 유지보수에 대한 요구사항을 포함한 제품에 대한 고객 요구사항

    7.2.2.4. 특정 요구 사항을 준수할 수 있는 능력 결정

    // 제품 요구 사항 분석 / 소비자 관련 프로세스 / 제품 판매

1.1.3. 위임사항의 형성

규제 문서

    2.2.1.2.2. 계약 분석 및 체결 절차 STP-2-01 // Enterprise Enterprise Ellat (STP) 표준 / 품질 관리 시스템 문서 / 내부 규제 문서 / 규정

ISO9000:2000 품질경영시스템 요구사항 7항

    7.2.1.2. 고객이 지정하지 않았지만 의도하거나 지정된 용도에 필요한 요구 사항 // 고객 요구 사항 정의 / 고객 관련 프로세스 / 제품 판매

    7.2.1.3. 필수 요구 사항 및 법적 조항을 포함한 제품 관련 의무 // 고객 요구 사항 정의 / 고객 관련 프로세스 / 제품 판매

    // 제품 요구 사항 분석 / 소비자 관련 프로세스 / 제품 판매

    7.2.2.2. 소비자가 요구 사항에 대한 서면 진술을 제공하지 않는 경우 수락 전에 소비자 요구 사항 확인 // 제품 요구 사항 분석 / 소비자 관련 프로세스 / 제품 판매

    7.2.2.3. 이전에 제출한 것과 다른 계약 또는 주문의 요구 사항 변경 사항에 대한 설명(예: 입찰 또는 링크) // 제품 요구 사항 분석 / 소비자 관련 프로세스 / 제품 판매

    7.3.1.1. 설계 및/또는 개발 프로세스의 단계 결정

    7.3.2.2. 해당 법률 및 규정 요구 사항

    7.3.2.3. 유사한 이전 개발에서 파생된 적용 가능한 데이터 // 설계 및 개발을 위한 입력 데이터 / 설계 및 개발 / PRODUCT SALES

    7.3.2.4. 설계 및 개발에 중요한 기타 요구 사항 // 설계 및 개발을 위한 입력 데이터 / 설계 및 개발 / PRODUCT SALES

    7.3.4.1. 요구 사항을 충족하는 능력 평가

1.1.4. 계약 체결

규제 문서

    2.2.1.2.3. 고객과의 계약 업무에 관한 규정(STP-3-01) // Enterprise Standards Ellat (STP) / 품질 관리 시스템 문서 / 내부 규정 문서 / 규정

1.1.5. 계약 의무 이행 모니터링

규제 문서

    2.2.1.2.3.2. 변경 사항을 분석하고 계약 문서를 변경하는 절차 // 고객과의 계약 작업에 관한 규정(STP-3-01) / Enterprise Standards Ellat(STP) / 품질 관리 시스템 문서 / 내부 규정 문서 / 규정

    2.2.1.2.4.1. 고객 불만 및 클레임 처리 절차

    2.2.1.2.4.2. 고객의 의견을 제거하는 절차 // 시정 및 예방 조치에 관한 규정(STP-4-01) / Ellat Enterprise Standards(STP) / 품질 관리 시스템 문서 / 내부 규정 문서 / 규정

ISO9000:2000 품질경영시스템 요구사항 7항

    7.2.3.2. 변경을 포함한 요청, 계약, 주문 처리 // 소비자와의 커뮤니케이션 / 소비자 관련 프로세스 / 제품 판매

1.2. 프로젝트 작업 스케줄링(주요 기능)

1.2.1. 단지의 구성 및 개발 범위의 명확화

규제 문서

    // Enterprise Standards Ellat (STP) / 품질 관리 시스템 문서 / 내부 규정 문서 / 규정

ISO9000:2000 품질경영시스템 요구사항 7항

    7.2.2.1. 제품 요구 사항의 정의 // 제품 요구 사항 분석 / 소비자 관련 프로세스 / 제품 판매

1.2.2. 프로젝트 품질 보증 계획

규제 문서

    2.2.1.2.5. 프로젝트 품질 보증 프로그램 개발을 위한 구성 및 절차(STP-5-01) // Enterprise Standards Ellat (STP) / 품질 관리 시스템 문서 / 내부 규정 문서 / 규정

ISO9000:2000 품질경영시스템 요구사항 7항

  • 7.1.1. 제품, 프로젝트 또는 계약에 대한 품질 목표 설정

    • 7.1.3. 검토 및 승인 활동 및 승인 기준 정의 // 판매 프로세스 계획 / 제품 판매

    7.2.2.5. 분석 결과 수정 및 후속 조치(5.5.7항 참조) // 제품 요구 사항 분석 / 소비자 관련 프로세스 / 제품 판매

    7.3.1.2. 각 설계 및/또는 개발 단계에 대한 검토, 검증 및 승인 활동 정의 // 디자인 및 개발 기획 / 디자인 및 개발 / PRODUCTS SALES

1.2.3. 단지 구성 요소 개발을 위한 민간 기술 사양 작성

규제 문서

    2.2.1.2.7. 프로젝트 구현 기술. 작업 단계 및 순서(STP-7-01) // Enterprise Standards Ellat (STP) / 품질 관리 시스템 문서 / 내부 규정 문서 / 규정

1.2.4. 프로젝트 기획

규제 문서

    // Enterprise Standards Ellat (STP) / 품질 관리 시스템 문서 / 내부 규정 문서 / 규정

ISO9000:2000 품질경영시스템 요구사항 7항

    7.1.2. 프로세스 및 문서화 필요성 결정, 제품별 리소스 및 인프라 제공 // 판매 프로세스 계획 / 제품 판매

1.2.5. 작업 수행의 조정 및 운영 제어

규제 문서

    2.2.1.2.4.3. 시정 조치 절차 // 시정 및 예방 조치에 관한 규정(STP-4-01) / Ellat Enterprise Enterprise Standards(STP) / 품질 관리 시스템 문서 / 내부 규정 문서 / 규정

    2.2.1.2.6. 작업 계획에 관한 규정(STP-6-01) // Enterprise Standards Ellat (STP) / 품질 관리 시스템 문서 / 내부 규정 문서 / 규정

ISO9000:2000 품질경영시스템 요구사항 7항

    7.3.4.2. 문제점 파악 및 후속 조치 제안 개발 // 설계 및 개발 분석 / 설계 및 개발 / PRODUCT MAILING

    7.3.7. 설계 및 개발 변경 관리

1.3. 설계, 소프트웨어 및 운영 문서 개발(주요 기능)

1.3.1. 컴플렉스 하드웨어 문서 개발

규제 문서

    2.2.1.2.7. 프로젝트 구현 기술. 작업 단계 및 순서(STP-7-01) // Enterprise Standards Ellat (STP) / 품질 관리 시스템 문서 / 내부 규정 문서 / 규정

    2.3.3.3. 하드웨어 개발 및 생산 부서의 작업 계획

1.3.2. 단지의 소프트웨어 부분 개발

규제 문서

    2.2.1.2.7. 프로젝트 구현 기술. 작업 단계 및 순서(STP-7-01) // Enterprise Standards Ellat (STP) / 품질 관리 시스템 문서 / 내부 규정 문서 / 규정

    2.3.3.4. 소프트웨어 개발 및 생산 부서 업무 계획 // 프로그램 및 실행 계획 / 회사의 조직 및 관리 문서 / 규정

1.3.4. 설계 결과 분석 및 승인

규제 문서

    2.2.1.2.7. 프로젝트 구현 기술. 작업 단계 및 순서(STP-7-01) // Enterprise Standards Ellat (STP) / 품질 관리 시스템 문서 / 내부 규정 문서 / 규정

ISO9000:2000 품질경영시스템 요구사항 7항

    7.3.3.1. 설계 및 개발 입력 요구 사항 준수

    7.3.3.2. 제조 및 서비스 운영에 대한 적절한 정보 제공(7.5 참조) // 설계 및 개발 결과물 / 설계 및 개발 / PRODUCT MAILING

    7.3.3.4. 제품의 안전하고 적절한 사용에 필수적인 제품의 특성을 결정합니다. // 설계 및 개발 결과물 / 설계 및 개발 / PRODUCT MAILING

    7.3.5.1. 입력 요구 사항에 대한 출력 데이터의 적합성 // 설계 및 개발 검증 / 설계 및 개발 / PRODUCT SALES

    7.3.6. 설계 및 개발 결과 승인 // 설계 및 개발 / 판매 제품

  • 교육, 개발, 훈련

키워드:

1 -1

웹 사이트 개발의 예에서 고객과의 전체 상호 작용 체계를 고려하십시오. 그래픽으로 상호 작용 단계는 다음 그림과 같이 나타낼 수 있습니다.

기본은 전화또는 이메일, 계정 관리자가 처리합니다. 관리자는 Beehive 회사의 서비스에 대해 이야기하고 관심 있는 모든 질문에 대한 답변을 제공하며 고객과의 추가 상호 작용 프로세스를 설명합니다.

* 모든 질문에 답하고 모든 문제를 해결하는 데 도움을 줄 준비가 된 프로젝트 전체 기간 동안 고객에게 개인 관리자가 할당된다는 점은 주목할 가치가 있습니다.

다음으로 관리자는 완료를 돕습니다. 간략한 양식협력 주제에 대한 필요한 명확한 질문을 포함하고 내부 CRM 시스템(고객 관계 관리 시스템)에 연락처를 추가하는 웹 사이트 개발을 위해.

데이터는 필요한 모든 고객 데이터를 안전하게 저장하고 사이트 전체의 품질 개발을 보장하기 위해 시스템에 입력됩니다.

완성된 브리핑을 바탕으로 Beehive 전문가가 준비합니다. 개별 상업 제안작업 시간과 비용에 대한 설명과 함께 관리자는 고려를 위해 고객에게 보냅니다.

다음은 협력 조건에 동의하는 과정이며, 그 결과는 조약. 작업 시작 속도를 높이기 위해 양 당사자가 계약서에 서명하고 당사자는 스캔한 계약서 사본을 교환합니다. 계약서 원본은 등기우편으로 발송합니다(이하 모든 종이 사본은 우편 또는 택배로 교환함). 당사자가 종이 형태의 원본을 받은 후 1부는 우편으로 반송됩니다.

*전화에서 계약 체결까지의 과정은 보통 1~2일을 넘지 않습니다.

계약서에 서명하고 전자 스캔 사본을 교환한 후 고객은 일반적으로 총 계약 금액의 50%에 해당하는 선금을 지불합니다.

선급금을 받고 대상분야 분석 후 개발 및 승인 단계 시작 참조 조건(TOR), 개발 중인 사이트에 대한 모든 요구 사항이 규정되어 있는 경우 체계가 제공되고 전체 사이트의 상세한 프로토타입이 생성됩니다. TK는 계약에 대한 필수 부록으로, 양 당사자가 승인하고 계약과 동일한 방식으로 서명됩니다.

* 위임장은 계약자와 고객 모두에게 매우 중요한 문서임을 이해해야 합니다. 고품질의 인터넷 프로젝트를 적시에 설계하고 실행할 수 있습니다.

모든 요구 사항이 승인된 후 고객에게 발송됩니다. 필요한 텍스트 및 그래픽 자료 목록, 고객은 개발 단계 시작 전에 제공해야 합니다(즉, 계약자가 디자인 레이아웃을 개발하는 동안 고객은 필요한 모든 자료를 수집하여 제공합니다). 이 목록에는 회사에 대한 설명, 협력 대상, 보유한 상 및 인증서, 가격 및 가격표, 제품 카탈로그 및 상품 설명, 서비스 설명, 사이트에 게시된 연락처 정보 등이 포함될 수 있습니다.

때로는 고객이 자신의 서비스를 직접 설명하기 어렵거나 단순히 시간이 없습니다. 이 경우 계약자는 사이트에 누락된 콘텐츠(사진, 텍스트, 동영상 등)를 작성하는 작업을 완료할 준비가 된 것입니다.

* 고객에게 필요한 자료를 제공하는 것은 다음과 같은 이유로 매우 중요합니다.

  • 고객이 제공한 모든 콘텐츠를 한 번에 사이트 레이아웃에 올바르게 입력해야 합니다(추가 작업을 수행하는 것은 의미가 없습니다).
  • 공연자의 기술 프로세스는 문자 그대로 "분 단위"로 예정되어 있으며 이를 위반하고 추가 비용을 발생시키고 싶지 않습니다.
  • 테스트 정보로 인터넷 프로젝트를 채우는 것도 의미가 없습니다. (첫째, 불필요한 작업의 양이 다시 증가합니다. 둘째, 검색 엔진은 테스트 콘텐츠로 호스팅된 사이트를 비관할 수 있습니다. 셋째, 잠재 고객은 사이트에 대해 부정적인 태도를 가질 수 있습니다. 명백히 쓸모없는 정보를 포함함);
  • 귀하와 우리 모두에게 프로젝트를 전문적으로 제 시간에 완료하는 것이 중요합니다.

* 고객 여러분, 자신의 사이트 개발과 수익 창출을 지체하지 마십시오. 콘텐츠를 제때 제공하세요! 그렇지 않으면 귀하로부터 정보를 받을 때까지 프로젝트가 중단되므로 사이트 제출 기한이 연기됩니다. 정보 수집 및 작성, 텍스트 작성 및 사진 처리를 주문할 시간이 없다면 저렴합니다.

동시에 프로젝트를 위한 작업 그룹이 생성되고 단계가 시작됩니다. 디자인 레이아웃 개발미래 사이트.
디자인 레이아웃이 준비되면 승인을 위해 고객에게 전송됩니다. 일단 승인되면 목업은 유효한 디자인이 됩니다.

* 프로젝트의 복잡성에 따라 고객은 필요한 프로젝트 리소스를 업로드하고 개발 단계를 모니터링하며 의견을 게시할 수 있는 프로젝트 관리 시스템(예: Redmine)에 대한 액세스 권한을 부여받을 수 있습니다.

추가 작업을 계속하려면 이전에 고객에게 보낸 목록을 포함하여 필요한 모든 자료를 고객으로부터 받아야 합니다.

누락된 자료를 받는 즉시. 중요한 사이트 개발 단계승인된 TOR에 따라.
이 단계에는 많은 유형의 작업이 포함됩니다. 사이트 레이아웃의 크로스 브라우저 레이아웃, 선택한 콘텐츠 관리 시스템(CMS)에 필요한 디자인 템플릿 개발, CMS 자체의 설치 및 구성, 필요한 설치 모듈 및 구성 요소, 누락된 모듈 개발, 웹 사이트 운영 알고리즘에 대한 포괄적인 연구, 사이트를 콘텐츠로 채우고 기술 도메인에 프로젝트를 배포하고 테스트로 이동합니다.

인터넷 프로젝트 테스트는 계약자의 전문가가 수행하고 모든 오류와 의견은 제거되며 사이트는 작업을 위해 미세 조정됩니다.

작업이 완료되고 기술 도메인에서 사이트 테스트가 완료되는 즉시 인계 단계. 여기에서 고객 측에서 TOR 요구 사항 충족 및 인터넷 프로젝트 기능의 전체 프로세스를 확인합니다.
고객이 사이트가 TOR 요구 사항을 완전히 준수하는지 결정하면 사이트가 고객에게 전송되고 프로젝트가 호스팅에 게시됩니다.

작품 인도 및 수락의 결과 및 확인은 작업 가능한 사이트이며 양 당사자가 서명한 수락 행위입니다. 서명된 행위는 회계를 위한 전체 문서와 함께 우편으로 발송됩니다.

수락 증명서에 서명한 후 고객은 계약에 따라 나머지 작업 비용을 지불합니다.

최종 계산 후 문서 및 웹 사이트와 함께 고객은 사용 설명서를 받고, DVD의 사이트 사본무료 기술적 지원사이트 접수일로부터 2~4주 이내

이 다이어그램에서는 초기 호출에서 프로젝트 전달에 이르기까지 상호 작용의 모든 측면을 완전히 반영하려고 했습니다. 간단한 프로젝트의 경우 일부 단계를 결합하거나 생략할 수 있습니다. 그러나 어쨌든 모든 것이 계약에 반영됩니다.

서비스 "포괄적 웹사이트 개발" 및 "웹사이트 프로모션"에 대한 작업 계획은 위에서 설명한 고객과 계약자 간의 상호 작용 프로세스를 구조적으로 반복하므로 자세한 설명이 필요하지 않습니다.

설명된 상호 작용 체계가 투명하고 이해할 수 있기를 바랍니다. 여전히 궁금한 점이 있으면 문의하십시오.

프로젝트: 검색 색인 및 검색어별로 전자 카탈로그에 대한 검색어 분포
프로젝트 범위: 13.02.2006 - 05.06.2006
고객: Petrozavodsk State University의 과학 도서관.
책임이 있는: Gorshkova Galina Anatolyevna, 문서 컴퓨터 처리 및 카탈로그 생성 부서 책임자. 이메일 메일: . 노예. 전화: 719602. 도서관: 택시. 102. RCNIT의 수석 프로그래머 Guryev Dmitry Borisovich. 이메일 메일: . 노예. tel.: 784775. 인터넷 센터.
강사: 쿨라코프 키릴 알렉산드로비치 이메일: . 사무실 전화: 711015. 215호
강사 정보: 그룹 번호 13
관련된 문서: 프로젝트 개요 프로젝트 계획 작업 일정(간트 차트) 요구 사항 사양 설계 테스트 구현 문서 테스트 문서
Customer Engagement 개발자 관계 보고서 개발 진행 상황 용어집 사용자 가이드

의뢰인과의 첫만남.

첫 미팅에서 개발팀이 고객에게 소개되었습니다. 고객은 PetrSU의 과학 라이브러리에 대해 이야기했습니다.

라이브러리는 자동화 시스템 "Foliant"를 기반으로 작동합니다. 전자 카탈로그는 도서관 시스템의 일부입니다. 카탈로그 검색은 쿼리를 사용하여 수행됩니다. 연산자는 많은 수의 검색 색인 및 검색어를 포함할 수 있는 검색 문자열을 생성합니다. 각 요청은 로그 테이블에 기록됩니다. 이 테이블에는 요청 시간, 요청한 클라이언트의 주소, 요청 자체, 요청 결과에 대한 데이터가 포함됩니다.

고객은 로그 테이블을 지속적으로 모니터링하고 검색 인덱스 사용에 대한 일부 통계를 제공해야 합니다.

구현 중인 프로젝트에 대한 초기 요구 사항도 제시되었습니다. 요구 사항 중 하나는 효율적인 통계 편집입니다. 즉, 요청을 보낸 후 적당한 시간이 지나면 통계가 표시되어야 합니다. 이 요구 사항으로 인해 개발자는 PL/SQL에서 서버측 프로시저를 사용하도록 권장되었습니다.

클라이언트와의 두 번째 만남.

고객은 개발자에게 전자 카탈로그 시스템에 들어가기 위한 로그인과 암호를 제공하여 로그 테이블과 검색 색인 테이블이라는 두 개의 작업용 테이블 사본을 제공했습니다.

Guryev Dmitry Borisovich는 Oracle SQL*Plus DBMS 클라이언트 작업에 대해 자세히 알려 주었습니다. 팀은 전자 카탈로그 작업에 대해 알게되었습니다.

"Foliant" 시스템은 약 99개의 필드를 포함하는 RusMark 표준을 기반으로 작동합니다. AIBS "Foliant"와 함께 작동하는 각 라이브러리는 사용할 필드와 하위 필드를 선택합니다. 라이브러리 데이터 저장 규칙을 설명하는 특수 GOST가 있습니다. 필드 수가 많기 때문에 검색 색인 시스템을 만들었습니다. 서비스 및 공용 인덱스가 있습니다.

디렉터리 사용자는 내부와 외부로 나뉩니다. 각 부서 또는 직원에게는 자체 권한이 할당됩니다. 개체에 대한 각 레코드는 별도의 요소로 구문 분석되며 전체적으로 저장되지 않습니다.

고객과의 세 번째 만남.

고객이 서면으로 명확한 요구 사항을 제공했습니다.

고객은 다음 통계에 관심이 있습니다.

  1. 전자 카탈로그에 대한 요청 수입니다.
  • 지난 한 달 동안.
  • 현재 연도의 월별 회계.
  • 연도별 회계.
  • 정보의 역사를 만듭니다.
  • 요청 목록 각자에게검색 결과가 null인 검색 인덱스입니다.
  • 자주 발생하는 요청 목록입니다.
  • 특정 기간 동안 요청 실행 분석. 보고서에는 다음 통계가 포함되어야 합니다.
    • 요청 수입니다.
    • 조회 요청 수입니다.
    • 복잡한 쿼리의 수입니다.
    • 성공한 응답의 수입니다.
    • null 응답 수입니다.
      • 다음 검색 색인을 사용하십시오.
    • 작가
    • 저자 개정 찌르다.
    • 문서 유형.
    • 지리적 섹션.
    • 날짜를 입력하세요.
    • 발행일.
    • 제목.

    클라이언트와의 네 번째 만남.

    고객 Guryev D.B. SQL*Plus 유틸리티 설치 및 구성의 복잡성을 설명했습니다. 프로그램 시작 문제에 대한 해결책은 SQL * Net 패키지와 Guryev D.B.를 설치하는 것이 었습니다. 개발자를 위해 테이블의 정확한 이름을 제공하고 팀의 처분에 따라 다른 테이블도 추가했습니다. 전문가는 아키텍처 문서를 연구하고 모든 유형의 아키텍처를 실제로 구현하고 가장 최적의 아키텍처를 선택할 것을 제안했습니다. 동시에 로그 테이블을 재구성하지 않고 가능한 한 특정 문제를 해결하고 로그 테이블의 데이터를 일반화하여 다양한 로컬 통계에서 추가로 사용하는 것이 바람직합니다.

    고객 Gorshkova G.A. 요구 사항 문서를 알고 승인했습니다.

    고객과의 다섯 번째 만남.

    고객 측의 전문가인 Guryev Dmitry Borisovich는 PetrSU의 교육 서버에서 "Oracle" DBMS 작업에 필요한 소프트웨어를 설치하도록 초대되었습니다. PetrSU 서버에 대한 관리 액세스 권한이 있는 Vadim Anatolyevich Ponomarev도 대학 측에서 이 프로세스에 참여했습니다.

    우리는 또한 추천합니다

    로드 중...로드 중...