소프트웨어 개발에 대한 접근 방식. 소프트웨어 개발에 대한 구조화된 접근 방식입니다. 애자일 개발의 원리와 의미

1.코딩

소프트웨어 개발 단계에서는 다음과 같은 주요 작업이 수행됩니다. 코딩; 테스트; PP 도움말 시스템 개발; 사용자 문서 작성; 소프트웨어 버전 생성 및 설치,

코딩은 높은 수준과 낮은 수준의 설계 결과를 완성된 소프트웨어 제품으로 변환하는 프로세스입니다. 즉, 코딩할 때 컴파일된 소프트웨어 모델은 선택된 프로그래밍 언어(기존 언어 중 하나일 수 있음)를 사용하여 설명됩니다. 언어 선택은 고객의 요청에 따라 또는 해결 중인 문제를 고려하여 수행됩니다. 개인적인 경험개발자.

코딩할 때 선택한 언어에 대한 표준을 따라야 합니다. 예를 들어 C 언어의 경우 ANSI C이고 C++의 경우 ISO/IEC 14882 "Standard for the C++ 프로그래밍 언어"입니다.

프로그래밍 언어에 대해 일반적으로 인정되는 표준 외에도 회사는 프로그램 작성 규칙에 대한 자체 추가 요구 사항을 개발할 수도 있습니다. 주로 프로그램 텍스트 형식 지정 규칙과 관련이 있습니다.

표준 및 회사 규칙을 따르면 개발자, 생성 날짜, 이름 및 목적에 대한 정보는 물론 구성 관리에 필요한 데이터가 포함되어 올바르게 작동하고 읽기 쉽고 다른 개발자가 이해할 수 있는 프로그램을 만들 수 있습니다.

코딩 단계에서는 프로그래머가 직접 프로그램을 작성하고 테스트합니다. 이러한 유형의 테스트를 단위 테스트라고 합니다. 소프트웨어 테스팅과 관련된 모든 문제는 이 장에서 논의됩니다. 도 10에는 소프트웨어 개발 단계에서 사용되는 테스트 기술도 여기에 설명되어 있다. 이 기술을 테스트라고 합니다. "유리 상자"(유리 상자);때로는 테스트라고도 합니다. "화이트 박스"(화이트 박스)"블랙박스"라는 고전적인 개념과 반대되는 개념입니다.

블랙박스 테스트에서 프로그램은 내부 구조를 알 수 없는 객체로 취급됩니다. 테스터는 데이터를 입력하고 결과를 분석하지만 프로그램이 어떻게 작동하는지 정확히 알지 못합니다. 전문가는 테스트를 선택할 때 자신의 관점에서 흥미로운 입력 데이터와 조건을 찾아 비표준 결과를 초래할 수 있습니다. 그는 주로 테스트 중인 프로그램에서 오류가 발생할 가능성이 가장 높은 각 입력 데이터 클래스의 대표자에 관심이 있습니다.

"유리 상자"를 테스트할 때는 상황이 완전히 다릅니다. 테스터(이 경우 프로그래머 자신)는 자신이 액세스할 수 있는 소스 코드에 대한 지식을 바탕으로 테스트를 개발합니다. 전체 권한. 그 결과, 그는 다음과 같은 혜택을 받습니다.

1. 테스트 방향. 프로그래머는 프로그램을 부분적으로 테스트하고, 테스트 중인 모듈을 호출하는 특수 테스트 서브루틴을 개발하고, 프로그래머가 관심 있는 데이터를 해당 모듈로 전송할 수 있습니다. 별도의 모듈을 "유리 상자"로 테스트하는 것이 훨씬 쉽습니다.

2. 전체 코드 적용 범위. 프로그래머는 각 테스트에서 어떤 코드 조각이 작동하는지 항상 확인할 수 있습니다. 그는 테스트되지 않은 채로 남아 있는 코드의 다른 부분을 확인하고 테스트할 조건을 선택할 수 있습니다. 아래에서는 수행된 테스트의 코드 적용 범위를 추적하는 방법을 설명합니다.

3. 명령의 흐름을 제어하는 ​​능력. 프로그래머는 프로그램에서 다음에 어떤 기능이 실행되어야 하는지, 현재 상태가 어떠해야 하는지 항상 알고 있습니다. 프로그램이 자신이 생각하는 대로 작동하는지 확인하기 위해 프로그래머는 실행 정보를 표시하는 디버깅 명령을 포함하거나 이를 수행하기 위해 특수 프로그램을 사용할 수 있습니다. 소프트웨어디버거라고 합니다. 디버거는 많은 유용한 작업을 수행할 수 있습니다. 프로그램 명령 실행 순서를 모니터링 및 변경하고, 변수의 내용과 메모리의 주소를 표시하는 등의 작업을 수행할 수 있습니다.

4. 데이터 무결성을 모니터링하는 기능. 프로그래머는 프로그램의 어느 부분이 각 데이터 요소를 변경해야 하는지 알고 있습니다. (동일한 디버거를 사용하여) 데이터 상태를 모니터링함으로써 잘못된 모듈에 의해 변경된 데이터, 잘못된 해석 또는 실패한 구성과 같은 오류를 식별할 수 있으며 프로그래머가 직접 테스트를 자동화할 수 있습니다.

5. 내부 경계점의 비전. 안에 소스 코드외부에서는 보이지 않는 프로그램의 경계점이 보입니다. 예를 들어, 완전히 다른 여러 알고리즘을 사용하여 특정 작업을 수행할 수 있으며 코드를 보지 않고는 프로그래머가 어떤 알고리즘을 선택했는지 판단하는 것이 불가능합니다. 또 다른 일반적인 예는 입력 데이터를 임시로 저장하는 데 사용되는 버퍼의 오버플로 문제입니다. 프로그래머는 버퍼가 오버플로되는 데이터의 양을 즉시 알 수 있으며 수천 번의 테스트를 수행할 필요가 없습니다.

6. 선택한 알고리즘에 따라 테스트 가능성이 결정됩니다. 매우 복잡한 계산 알고리즘을 사용하는 데이터 처리를 테스트하려면 특별한 기술이 필요할 수 있습니다. 고전적인 예로는 행렬 변환과 데이터 정렬이 있습니다. 프로그래머와 달리 테스터는 어떤 알고리즘이 사용되는지 정확히 알아야 하므로 전문 문헌을 참조해야 합니다.

유리 상자 테스트는 프로그래밍 프로세스의 일부입니다. 프로그래머는 항상 이 작업을 수행합니다. 즉, 각 모듈을 작성한 후 테스트하고 시스템에 통합한 후 다시 테스트합니다.

단위 테스트를 수행할 때 구조적 또는 기능적 테스트 기술 중 하나 또는 둘 다를 사용할 수 있습니다.

구조적테스트는 유리 상자 테스트의 한 유형입니다. 주요 아이디어는 테스트할 소프트웨어 경로를 올바르게 선택하는 것입니다. 그에 비해 기능의테스트는 블랙박스 테스트의 범주에 속합니다. 각 프로그램 기능은 입력 데이터를 입력하고 출력을 분석하여 테스트됩니다. 동시에 프로그램의 내부 구조는 거의 고려되지 않습니다.

구조 테스트가 훨씬 더 강력하지만 이론적 기초, 대부분의 테스터는 기능 테스트를 선호합니다. 구조 테스트는 수학적 모델링에 더 적합하지만 이것이 더 효과적이라는 의미는 아닙니다. 각 기술을 사용하면 다른 기술을 사용할 때 놓친 오류를 식별할 수 있습니다. 이러한 관점에서 볼 때 그들은 동등하게 효과적이라고 할 수 있습니다.

테스트 대상은 다음과 같습니다. 전체 경로프로그램(시작부터 완료까지 실행하는 명령의 순서)뿐만 아니라 개별 섹션도 포함됩니다. 프로그램을 실행하는 가능한 모든 방법을 테스트하는 것은 절대적으로 비현실적입니다. 따라서 테스트 전문가는 가능한 모든 경로에서 절대적으로 테스트해야 하는 그룹을 식별합니다. 선택을 위해 그들은 다음과 같은 특별한 기준을 사용합니다. 적용 범위 기준 (coveragecriteria),이는 매우 실제적인(상당히 큰 경우에도) 테스트 수를 결정합니다. 이러한 기준은 때때로 논리적 적용 범위 기준,또는 완전성 기준.

3. 도움말 시스템 개발 소프트웨어 제품. 사용자 문서 작성

프로젝트 직원 중 한 명을 문서의 기술 편집자로 임명하는 것이 좋습니다. 이 직원은 다른 작업도 수행할 수 있지만, 다른 직원이 문서를 개발 중이더라도 그의 주요 업무는 문서 분석입니다.

여러 사람이 소프트웨어 제작에 참여하지만 그 중 누구도 소프트웨어 품질에 대해 전적인 책임을 지지 않는 경우가 종종 있습니다. 결과적으로, 소프트웨어는 더 많은 사람들이 개발한다는 사실로부터 이익을 얻지 못할 뿐만 아니라, 각자가 무의식적으로 책임을 다른 사람에게 전가하고 동료가 작업의 이 부분 또는 저 부분을 수행할 것이라고 기대하기 때문에 손실을 입습니다. 이 문제는 기술 문서의 품질과 정확성에 대해 전적인 책임을 지는 편집자를 임명함으로써 해결됩니다.

PP 도움말 시스템은 사용자 매뉴얼용으로 개발된 자료를 기반으로 구성됩니다. 이 작업을 수행하는 담당자가 구성하고 작성합니다. 기술 편집자일 수도 있고 기술 편집자와 함께 일하는 개발자 중 한 명이 될 수도 있습니다.

잘 문서화된 보호프로파일은 다음과 같은 장점을 가지고 있습니다.

1. 사용의 용이성. 소프트웨어가 잘 문서화되어 있으면 적용하기가 훨씬 쉽습니다. 사용자는 더 빨리 배우고 실수를 줄이며 결과적으로 작업을 더 빠르고 효율적으로 수행할 수 있습니다.

2. 비용 절감 기술적 지원. 사용자가 필요한 작업을 수행하는 방법을 알 수 없을 때 PCB 제조업체의 기술 지원 서비스에 전화합니다. 이러한 서비스를 실행하는 데는 비용이 매우 많이 듭니다. 좋은 매뉴얼은 사용자가 스스로 문제를 해결하고 기술 지원팀에 문의할 필요성을 줄이는 데 도움이 됩니다.

3. 높은 신뢰성. 이해하기 어렵거나 엉성한 문서는 소프트웨어의 신뢰성을 떨어뜨립니다. 사용자가 실수를 할 가능성이 더 높고 실수의 원인과 그 결과를 처리하는 방법을 이해하기 어렵기 때문입니다.

유지 관리가 용이합니다. 사용자의 실수로 인해 발생하는 문제를 분석하는데 막대한 비용과 시간이 소요됩니다. 새로운 소프트웨어 릴리스의 변경 사항은 단순히 이전 기능의 인터페이스에 대한 변경 사항인 경우가 많습니다. 사용자가 마침내 소프트웨어 사용 방법을 파악하고 기술 지원 요청을 중단할 수 있도록 도입되었습니다. 관리가 상당히 잘됨

컴퓨터 과학, 사이버네틱스 및 프로그래밍

Iteration N 통합 개발 프로세스 소프트웨어 USDP 사용 사례 모델은 애플리케이션이 사용되는 사례를 설명합니다. 분석 모델은 애플리케이션의 기본 클래스를 설명합니다. 디자인 모델은 클래스와 전용 개체 간의 연결과 관계를 설명하고, 배포 모델은 컴퓨터 전체의 소프트웨어 배포를 설명합니다.

20과
소프트웨어 개발에 대한 일반 원칙 및 접근 방식

소프트웨어 개발 모델

1. 보도파드나야
2. 캐스케이드 모델
3. 나선
4. 익스트림 프로그래밍
5. 증분
6. MSF 방법론

폭포 모델

나선형 모델

점진적 개발

요구사항 분석

설계

구현

요소

테스트

완성

테스트

하나의 전체

반복 1 반복 2…. 반복 N

통합 소프트웨어 개발 프로세스(USDP)

1. 사용 사례 모델은 애플리케이션이 사용되는 사례를 설명합니다.
2. 분석 모델은 애플리케이션의 기본 클래스를 설명합니다.
3. 디자인 모델은 클래스와 선택된 객체 간의 연결과 관계를 설명합니다.
4. 배포 모델은 컴퓨터 전체의 소프트웨어 배포를 설명합니다.
5. 구현 모델은 프로그램 코드의 내부 구성을 설명합니다.
6. 테스트 모델은 테스트 구성 요소, 테스트 절차 및 다양한 테스트 사례로 구성됩니다.

MSF 방법론

일반적인 소프트웨어 제품 아키텍처 구성 요소 및 일반적인 소프트웨어 요구 사항

결함 허용오류를 감지하고, 시스템에 대한 나쁜 결과를 복원하고 지역화하여 신뢰성을 높이는 일련의 시스템 속성입니다. 내결함성을 보장하기 위해 실제 시스템을 설계할 때는 시스템 오류로 이어질 수 있는 모든 가능한 상황을 제공하고 오류 처리 메커니즘을 개발해야 합니다.

신뢰할 수 있음 다양한 실패와 실패를 견딜 수 있는 시스템의 능력.

거절 이건 시스템 전환이다오류로 인해 완전히 작동할 수 없는 상태가 되었습니다.

충돌 시스템 오류로 이어지지 않는 시스템 작동 오류.

일정 기간 동안 실패 및 실패 횟수가 적을수록 시스템의 신뢰성이 높아진다고 간주됩니다.

관심을 가질 만한 다른 작품뿐만 아니라
57355.		다양한 유기 화합물, 분류. 살아있는 자연의 유기물질	48.5KB
	유기 화합물의 다양성은 탄소 원자가 단순 결합과 다중 결합으로 서로 연결되어 자전거, 자전거, 세발자전거, 다륜, 뼈대 등 사슬로 연결된 거의 무제한의 원자를 갖는 화합물을 형성하는 탄소 원자의 독특한 능력에 의해 결정됩니다.
57359.		언어 정보 모델 처리	291KB
	기본 개념: 모델; 정보 모델; 언어 정보 모델; 주석; 추상적인. 시놉시스 위도의 시놉시스. 2에 대한 메모를 만듭니다. 문서를 Note라는 이름으로 자체 폴더에 저장합니다.
57361.		숫자와 그림 3. 경계선에 숫자 맞추기 3. 숫자 쓰기 3. 물체 개수 맞추기	35.5KB
	생물은 몇 마리나 있습니까? 1위가 누구인지 꼴찌가 누구인지 1위가 누구인지 2위가 누구인지 고슴도치의 이웃 이름을 말해보세요. 오른 손잡이 다람쥐는 누구입니까 왼손잡이 기린은 누구입니까 가장 큰 사람은 누구입니까 가장 작은 사람은 생물 가운데 서 있습니다 Gra 보여주세요 자비를 베풀지 마십시오.

오늘날 소프트웨어 엔지니어링에는 EIS 소프트웨어 개발에 대한 두 가지 주요 접근 방식이 있으며, 그 근본적인 차이점은 다음과 같습니다. 다른 방법들시스템 분해. 첫 번째 접근 방식은 기능적 모듈식 또는 구조적 접근 방식이라고 합니다. 이는 시스템의 구조가 기능의 계층 구조와 개인 간의 정보 전송 측면에서 설명되는 기능적 분해의 원리를 기반으로 합니다. 기능적 요소. 두 번째, 객체 지향 접근 방식은 객체 분해를 사용합니다. 이 경우 시스템의 구조는 개체와 개체 간의 연결로 설명되고, 시스템의 동작은 개체 간의 메시지 교환으로 설명됩니다.

따라서 EIS 소프트웨어 개발에 대한 구조적 접근 방식의 본질은 자동화된 기능으로의 분해(분류)에 있습니다. 시스템은 기능적 하위 시스템으로 나뉘며, 이는 다시 하위 기능, 작업 등으로 나뉩니다. 특정 절차. 동시에 자동화 시스템은 모든 구성요소가 상호 연결되는 전체적인 관점을 유지합니다. 개별 작업부터 전체 시스템까지 "상향식"으로 시스템을 개발할 때 무결성이 손실되고 설명할 때 문제가 발생합니다. 정보 상호작용개별 구성 요소.

구조적 접근 방식의 가장 일반적인 방법은 모두 여러 가지 일반 원칙을 기반으로 합니다. 기본 원칙은 다음과 같습니다.

"분할 및 정복"의 원칙(하위 섹션 2.1.1 참조)

계층적 정렬의 원리는 시스템의 구성 요소를 각 수준에 새로운 세부 사항을 추가하여 계층적 트리 구조로 구성하는 원리입니다.

두 가지 기본 원칙을 강조한다고 해서 나머지 원칙이 부차적이라는 의미는 아닙니다. 그 중 하나라도 무시하면 예측할 수 없는 결과(전체 프로젝트의 실패 포함)를 초래할 수 있기 때문입니다. 이러한 원칙의 주요 내용은 다음과 같습니다.

추상화의 원칙 - 시스템의 본질적인 측면을 강조하고 중요하지 않은 측면은 추상화합니다.

일관성의 원칙 - 시스템 요소의 타당성과 일관성

데이터 구조화의 원칙 - 데이터는 구조화되고 계층적으로 구성되어야 합니다.

구조적 접근 방식은 주로 시스템의 기능적 구조와 데이터 간의 관계를 설명하는 두 가지 도구 그룹을 사용합니다. 각 도구 그룹은 특정 유형의 모델(다이어그램)에 해당하며 가장 일반적인 유형은 다음과 같습니다.

DFD(데이터 흐름 다이어그램) - 데이터 흐름 다이어그램.

SADT(구조 분석 및 설계 기술 - 구조 분석 및 설계 방법) - 모델 및 해당 기능 다이어그램

ERD(엔티티 관계 다이어그램) - 엔터티 관계 다이어그램입니다.

데이터 흐름 다이어그램과 엔터티 관계 다이어그램은 CASE 도구에서 가장 일반적으로 사용되는 모델 유형입니다.

특정보기나열된 다이어그램의 구성과 디자인의 해석은 소프트웨어 라이프사이클 단계에 따라 달라집니다.

소프트웨어 요구사항 형성 단계에서 SADT 모델과 DFD를 사용하여 "AS-IS" 모델과 "TO-BE" 모델을 구축함으로써 조직의 비즈니스 프로세스의 기존 및 제안된 구조와 이들 간의 상호 작용을 반영합니다( SADT 모델의 사용은 원래 소프트웨어 설계용이 아니기 때문에 일반적으로 이 단계로만 제한됩니다. ERD의 도움으로 조직에서 사용되는 데이터에 대한 설명은 데이터베이스 구현 도구(DBMS)와 관계없이 개념적 수준에서 수행됩니다.

설계 단계에서 DFD는 설계된 소프트웨어 시스템의 구조를 설명하는 데 사용되며 새로운 설계로 개선, 확장 및 보완될 수 있습니다. 마찬가지로, ERD는 데이터베이스 스키마의 후속 생성에 적합한 논리적 수준에서 데이터 표현을 설명하는 새로운 구성으로 개선되고 보완됩니다. 이러한 모델은 소프트웨어 시스템 아키텍처, 프로그램 블록 다이어그램, 계층 구조를 반영하는 다이어그램으로 보완될 수 있습니다. 스크린 형태그리고 메뉴 등등

나열된 모델은 시스템이 기존 시스템인지 새로 개발되었는지 여부에 관계없이 EIS 소프트웨어에 대한 완전한 설명을 함께 제공합니다. 각 특정 사례의 다이어그램 구성은 시스템의 복잡성과 필요한 설명의 완전성에 따라 달라집니다.

이 장에 제시된 대부분의 도표 예시의 주제 영역은 러시아 연방의 조세 제도이며, 이에 대한 가장 완전한 설명은 러시아 연방 조세법에 포함되어 있습니다. 정보 기술, 러시아 연방 세금 시스템에 사용되는 특정 기능이 있습니다.

따라서 EIS 소프트웨어 개발에 대한 구조적 접근 방식의 본질은 자동화된 기능으로의 분해(분류)에 있습니다. 시스템은 기능적 하위 시스템으로 나뉘며, 이는 다시 하위 기능, 작업 등으로 나뉩니다. 특정 절차. 동시에 시스템은 모든 구성 요소가 상호 연결되는 전체적인 관점을 유지합니다. 개별 작업에서 전체 시스템에 이르기까지 시스템을 "상향식"으로 개발할 때 무결성이 손실되고 개별 구성 요소의 정보 상호 작용을 설명할 때 문제가 발생합니다.

구조적 접근 방식의 가장 일반적인 방법은 모두 다음과 같은 여러 가지 일반 원칙을 기반으로 합니다.

1. “분할 정복”의 원칙;

2. 계층적 정렬의 원리는 시스템의 구성 요소를 각 수준에 새로운 세부 사항을 추가하여 계층적 트리 구조로 구성하는 원리입니다.

두 가지 기본 원칙을 분리한다고 해서 나머지 원칙이 부차적이라는 의미는 아닙니다. 그 중 하나라도 무시하면 예측할 수 없는 결과가 발생할 수 있습니다(전체 프로젝트의 실패 포함). 이러한 원칙의 주요 내용은 다음과 같습니다.

1. 추상화의 원리 - 시스템의 본질적인 측면을 강조하고 중요하지 않은 측면은 추상화합니다.

2. 시스템 요소의 일관성, 타당성 및 일관성의 원칙.

3. 구조원리 데이터 - 데이터구조화되고 계층적으로 구성되어야 합니다.

구조적 접근 방식에는 주로 시스템의 기능적 구조와 데이터 간의 관계를 설명하는 두 가지 도구 그룹이 있습니다. 각 도구 그룹은 특정 유형의 모델(다이어그램)에 해당하며, 그중 가장 일반적인 것은 다음과 같습니다.

· DFD(데이터 흐름 다이어그램) - 데이터 흐름 다이어그램;

· SADT(구조 분석 및 설계 기술 - 구조 분석 및 설계 방법론) - 모델 및 해당 기능 다이어그램: 표기 IDEF0(시스템의 기능 모델링), IDEF1х(데이터베이스의 개념 모델링), IDEF3х(품질 평가를 위한 시스템 구축) 사물의 작업; 그래픽 설명프로세스의 흐름, 프로세스와 이러한 프로세스에 의해 변경되는 개체의 상호 작용)

· ERD(엔티티 - 관계 다이어그램) - 엔터티-관계 다이어그램.

소프트웨어 요구 사항 형성 단계에서 거의 모든 구조적 접근 방법(구조 분석)은 두 가지 모델링 도구 그룹을 사용합니다.

1. 시스템이 수행해야 하는 기능과 DFD 또는 SADT(IDEF0) 기능 간의 관계를 보여주는 다이어그램입니다.

2. 데이터와 그 관계를 모델링하는 다이어그램(ERD).

나열된 다이어그램의 구체적인 형태와 디자인의 해석은 소프트웨어 라이프사이클의 단계에 따라 다릅니다.

소프트웨어 요구사항 형성 단계에서 SADT 모델과 DFD를 사용하여 "AS-IS" 모델과 "TO-BE" 모델을 구축함으로써 조직의 비즈니스 프로세스의 기존 및 제안된 구조와 이들 간의 상호 작용을 반영합니다( SADT 모델의 사용은 원래 소프트웨어 설계용이 아니기 때문에 일반적으로 이 단계로만 제한됩니다. ERD의 도움으로 조직에서 사용되는 데이터에 대한 설명은 데이터베이스 구현 도구(DBMS)에 관계없이 개념적 수준에서 수행됩니다.

1. 프로그래밍 기술의 목적. 프로그래밍 기술 개발의 역사. 소프트웨어 프로젝트의 유형. 프로그래밍 기술의 구성요소. 프로젝트, 제품, 프로세스 및 사람

2. 프로그램 수명주기. 개발의 순환적 성격. 프로그래밍 기술의 기본 개념. 프로세스 및 모델. 단계와 회전. 이정표와 유물. 이해관계자 및 직원.

3. 요구사항 식별 및 분석. 소프트웨어 요구 사항. 요구사항 개발 흐름도. 요구사항 관리.

4. 건축 및 상세 설계. 구현 및 코딩. 테스트 및 검증. 품질 관리 프로세스. 화이트박스 방식과 블랙박스 방식. 검사 및 검토. 테스트 목표. 확인, 검증 및 시스템 테스트. 유지 관리 및 지속적인 개발.

5. 개발 프로세스 모델. 폭포 및 컨베이어 모델. 나선형 및 증분 모델. 유연한 개발 프로세스 모델.

6. 프로세스 모델 구축. 프로세스 요구 사항을 식별합니다. 사용된 단계, 이정표 및 아티팩트. 프로세스 아키텍처 선택. 표준 프로젝트 수행 절차. 문서화된 절차.

7. 개발팀 모델. 개발의 집단적 성격. 최적의 팀 규모. 프로젝트 참가자의 종속. 팀 개발 및 직원 개발. 전문화, 협력 및 상호 작용.

8. 개발팀 모델. 계층적 팀 모델. 수술 팀 방법. 동료 팀 모델.

9. 프로그래밍의 본질. 프로그래밍의 과학. 프로그래밍의 예술. 프로그래밍 기술. 프로그래밍 패러다임. 구조화된 프로그래밍. 논리 프로그래밍. 객체 지향 프로그래밍.

10. 소프트웨어 아키텍처. 이벤트 관리. 클라이언트/서버 아키텍처. 서비스. 3계층 아키텍처. 프로그램 디자인. 컨셉 디자인. 논리적인 디자인. 상세한 디자인.

1. Novikov의 소프트웨어 개발 접근 방식" http://window. /window_catalog/files/r60368/itmo307.pdf.

2. 익스트림 프로그래밍. – 상트페테르부르크: 피터, 2002.

3. 소프트웨어 개발 기술. - 세인트 피터스 버그. : 피터, 2004.

4. 브룩스 주니어 디자인되고 제작됩니다 소프트웨어 시스템. M.: 나우카, 1975; 번역의 새 판: The Mythical Man-Month. SPb.: 기호+, 1999.

5. 알고리즘 + 데이터 구조 = 프로그램. 엠., 미르, 1978.

6. 체계적인 프로그래밍. 소개. M.: 미르, 1977.

7. 구조화된 프로그래밍. M.: 미르, 1975.

8. 프로그래밍 규율. M.: 미르, 1978.

9. 소프트웨어 개발 기술. – 상트페테르부르크: 피터, 2002.

10. Terekhov 프로그래밍. M.: 이놈, 2006.

11. Rambo J. 통합 소프트웨어 개발 프로세스. 상트페테르부르크: 피터, 2002.

관리자를 위한 경제이론

기초 미시경제 이론. 경제 과정 분석에 적용한 예. 기본 거시경제 이론. 경제 과정 분석에 적용한 예. 경제 프로세스 관리의 원칙과 방법. 경제적 과정의 발전 수준을 평가하는 도구 확장 재생산 문제. 러시아 경제의 경제 성장 요인. 지속 가능한 개발의 기준 및 지표. 주기적 변동을 완화합니다. 경제 발전 속도를 평가하는 데 있어 승수 및 가속기의 역할. 경제학에서의 생산함수. 경제 과정 분석에 적용한 예. 이익. 이익에 영향을 미치는 지표 계산, 그래픽 이미지심지어 브레이크 포인트. 투자 정책 실행 방법론.

경제 이론 과정 : 대학 교과서 / Ed. . –Kirov: “ASA”, 2004. Kolemaev - 수학적 모델링. 거시경제 프로세스 및 시스템 모델링: 교과서. M.: UNITY-DANA, 2005. Bazhin 사이버네틱스. Kharkov: Consul, 2004. 수학적 모델링 방법에 관한 Leushin 워크숍: 교과서. 니즈니노브고로드 주 기술. 대학 - N. Novorod, 2007. 경제학에 관한 정치인: 경제학 분야 노벨상 수상자 강의. M.: 현대경제학과법, 2005. Cheremnykh. 고급 수준: Textbook.-M.:INFRA-M, 2008. 미니 경제 기관의 진화. 러시아 과학 아카데미 우랄 지점 경제 연구소 - M.: Nauka, 2007.

개발 및 경영 의사결정 기술 [N]

의사결정은 관리자 활동의 기초가 됩니다. 결정 이론 소개. 결정 이론의 기본 개념. 비즈니스 관리 모델과 그것이 의사 결정에 미치는 영향. 다양한 방법솔루션 분류. 분류: 격식의 정도, 일상의 정도, 빈도, 긴급성, 목표 달성 정도, 대안을 선택하는 방법에 따라 분류됩니다. 의사결정의 기본 방법. 의사 결정의 의지적 방법. 의사결정의 목표. 해결책을 찾는 시간입니다. 기본적인 실수 의사결정의 수학적 방법. 결정 이론의 수학적 측면. 운영 연구. 의사결정에 대한 수학적 접근. 의사결정 트리. 개발 및 의사결정 모델. 게임 이론. 의사결정의 수학적 방법. 결정 이론의 수학적 측면. 큐잉 이론의 모델. 재고 관리 모델. 선형 프로그래밍 모델. 운송 작업. 시뮬레이션 모델링. 네트워크 분석. 경제 분석. 합리적 모델의 한계. 그룹의 개발 및 의사 결정의 특징. 집합의 연결 정도에 따라 집단 응집력을 결정하는 방법. 집단적 결정을 내리는 방법. 합의 방법. 투표 방법. 창의적인 의사결정 방법. 영감. 아이디어 회의. 선박 협의회. 드 보노(De Bono)의 "생각하는 모자(Thinking Hats)" 방법. 창의적 문제 해결 이론(TRIZ). 완벽한 최종 솔루션. TRIZ를 활용한 문제 및 해결 방법의 예입니다. 독특하고 창의적인 결정을 내릴 때 TRIZ 방법을 적용합니다. 솔루션 아이디어를 개발하고 이를 상황에 적용하는 방법. 목표 트리 모델. 이해관계를 조율하는 전략. 이익을 조정하기 위한 결정의 형성. 상대방의 이익을 결정하는 방법. 의사결정 지원 시스템(전문가 시스템). 의사 결정 시스템 생성의 역사. 의사결정 시스템의 분류. 전형적인 구조전문가 시스템. 지식을 제시하는 방법. 논리적 추론 방법. 전문가 시스템의 실제 적용.

I. 의사결정 이론: 교과서. - M .: 시험, 2006. - 573 p. I. 의사결정. 경영 결정을 개발하기 위한 이론 및 방법. 지도 시간. - M.: MarT, 2005. - 496 pp. 경영 결정 개발 - M.: 출판사 "Delo", 2004 - 392 pp. G. 전문가 평가 및 의사결정 - M.: 특허, 1996. - 271 p. 타하 // 운영 연구 소개 = 운영 연구: 소개. - 7판. - M .: "Williams", 2007. - P. 549-594. G. 테일. 경제 예측 및 의사 결정. M.: “진보” 1970. K. D. 루이스. 경제 지표 예측 방법. M.: "재정 및 통계" 1986. G. S. Kildishev, A. A. Frenkel. 시계열 분석 및 예측. M.: “통계” 1973. O. Kim, C. W. Muller, U. R. Klekka 외 요인, 판별 및 군집 분석. M .: "재정 및 통계" 1989. 효과적인 관리자. 제 3권. 의사결정. – MIM LINK, 1999 Turevsky 및 자동차 운송 기업 관리. - M.: 고등학교, 2005. , ; 편집자 . 경영 시스템 분석: 지도 시간. – M.: 금융 및 통계, 2006. , Tinkov: 교과서. – M.: KNORUS, 2006.

통합 관리 시스템의 비즈니스 프로세스 모델링

비즈니스 프로세스는 어떤 원칙으로 구별됩니까? 비즈니스 프로세스에 대한 전체적인 설명의 문제점은 무엇입니까? 시스템이란 무엇이며 어떤 속성을 가지고 있습니까? 비즈니스 프로세스 모델링에서 시스템 분석의 역할은 무엇입니까? 통제 대상으로 처리합니다. 프로세스 환경. 비즈니스 프로세스의 기본 요소입니다. 기능 및 프로세스 관리의 장점과 단점. PDCA 관리주기. 프로세스 관리 주기의 단계. PDCA 주기 및 ISO 9001:2008 요구 사항 구현. SADT 방법론(구조 분석 및 설계 기법 - 구조 분석 및 설계 방법). 본질. 기본 조항. IDEF0 방법론에서 활동의 기능적 모델은 어떻게 표현됩니까? 기능 모델 다이어그램의 활동은 무엇을 의미하며 IDEF0 방법론에 따라 어떻게 표시됩니까? 기능 모델 다이어그램의 화살표는 무엇이며, 유형과 유형은 무엇입니까? DFD 방법론. 본질. DFD 다이어그램의 기본 구성 요소입니다. DFD 다이어그램의 기능은 무엇이며 여기에 설명된 내용은 무엇입니까? DFD 다이어그램 개체의 기능은 무엇입니까? DFD 다이어그램의 화살표는 무엇을 의미합니까? IDEF3 방법론. 본질. 문서화 및 모델링 도구. IDEF3 다이어그램의 기능은 무엇이며 여기에 설명된 내용은 무엇입니까? IDEF3 다이어그램 개체의 기능은 무엇입니까? 그리고 범인은요? 프로세스 분류. 일반적인 비즈니스 프로세스. 리엔지니어링과 그 기술. 회사를 경영할 때 리엔지니어링을 활용하는 것이 바람직한 경우는 언제입니까? 모니터링 및 측정 프로세스. 조직 프로세스의 지표. 프로세스의 수치 및 등급 평가.

"AllFusion Process Modeler(BPwin 4.1) Dialog-MEPhI를 사용한 비즈니스 프로세스 모델링" 2003 "AllFusion Modeling Suite를 사용한 정보 시스템 생성" ed. "Dialog-MEPhI" 2003 "AllFusion Process Modeler 4.1을 이용한 기능 모델링 실습. (BPwin) 어디서? 왜? 어떻게?" 에드. "Dialogue-MEPhI" 2004 AllFusion Process Modeler(BPwin)를 사용한 Dubeykovsky 모델링. 에드. "Dialogue-MEPhI" 2007 D. Mark, K. McGowan "구조 분석 및 설계 SADT 방법론" 1993 SADT 방법론에 대한 고전 작업. Cheremnykh 시스템 분석: IDEF 기술, 시스템 모델링 및 분석. IDEF 기술. 작업장. M.: 금융 및 통계, 2001. "구조적 비즈니스 모델: DFD 기술" http://www. /레벨4.asp? ItemId=5810 "비즈니스 프로세스 재구성의 이론과 실제" 2003/ P50.1.. 기능 모델링 방법론. M.: 러시아의 Gosstandart, 2000. http://www. IDEF0, IDEF3, DFD http://www. BPwin을 사용한 비즈니스 프로세스 모델링 http://www. /department/se/devis/7/ 비즈니스 관리 프로세스 모델링의 IDEF0 http:///content/view/21/27/ http://www. /dir/cat32/subj45/file1411/view1411.html http://www. http://www.

소프트웨어 제품의 효율성 평가

1. IT 아키텍처

2. 관리 프로세스의 영역.

3. 기획 및 조직 영역의 프로세스 목록

4. 도메인 프로세스 목록 획득 및 구현

5. 운영 및 유지 관리 영역의 프로세스 목록

6. 모니터링 및 평가 영역의 프로세스 목록

7. 프로세스 성숙도 모델 수준의 특성

9. KPI와 KGI의 관계 및 목적

1. 10.일반 IT 통제 및 애플리케이션 통제. 비즈니스 및 IT의 책임 영역.

Cobit 4.1 러시아어 버전.

지적 재산의 생성 및 사용에 대한 법적 규제

1. 지적활동의 결과에 대한 지적재산권을 기재하고 그 내용을 공개한다.

2. 독점권 처분에 대한 계약 유형을 나열하십시오. 독점권 처분에 관한 각 계약을 설명하십시오.

4. 저작권의 대상인 컴퓨터 프로그램의 법적 보호에 대한 주요 조항을 설명하십시오.

5. 저작권의 대상과 관련 권리의 대상인 데이터베이스의 법적 보호에 대한 주요 조항을 비교하십시오.

6. 특허권 대상의 특허 가능성 조건을 설명합니다: 발명; 실용신안; 산업 디자인.

7. 발명에 대한 특허성 기준의 내용을 확장합니다: 신규성; 창의적 단계; 산업상 이용가능성.

8. 발명, 실용신안 또는 산업 디자인에 대한 특허를 획득하기 위한 조건 및 절차와 특허의 유효성 및 유효 기간을 보장하는 조건을 설명합니다.

9. "노하우"를 정의하고 생산 비밀의 법적 보호가 발생하고 수행되는 생성 과정의 조건을 나열합니다.

10. 보호되는 개별화 수단을 나열하고 비교 특성을 제공합니다.

1. 지적재산권 러시아 연방, 교과서 // M, Prospekt, 2007

2., 지적재산권법, 교과서 // M, RIOR, 2009.

프로젝트 및 소프트웨어 개발 관리 [I]

방법론이란 무엇이며 왜 필요한가? 방법론의 일반적인 구조, 방법론의 주요 요소. 자신만의 방법론을 설계하기 위한 원칙. 다양한 아티팩트, 역할, 역량, 경계 조건의 예. 방법론 지표인 Cowburn에 따른 방법론의 구조. Cowburn의 디자인 기준. 방법론 선택 기준, Cowburn 매트릭스. 프로젝트 수명주기. 폭포수 및 반복적인 수명주기 모델. 폭포수 모델과 반복 모델의 적용 한계. 반복적 방법론의 예로 RUP를 들 수 있습니다. RUP의 기본 개념, 적용 범위. 소프트웨어 개발에서 인간의 역할. 애자일 방법론, 애자일 방법론의 기본 원칙. 유연한 방법론이 등장한 이유. 유연한 방법론의 예인 스크럼. 스크럼의 역할, 아티팩트, 활동. 스크럼 적용 가능성 제한. 익스트림 프로그래밍(XP) 아이디어, 가치, 기본 관행, 적용 가능성의 한계. 스크럼과 XP의 유사점과 차이점 요구사항 수집 및 관리. 기본 관행, 용어, 원칙. 프로젝트 및 제품, 주요 문서 유형을 문서화하는 방법. 이 과정에서 논의된 방법론의 요구사항 관리 사례의 예입니다. 소프트웨어 개발 계획. 계획 유형, 위험 관리, 대중적인 위험. 이 과정에서 논의된 방법론의 개발 계획 사례의 예입니다. 소프트웨어 개발 테스트. 소프트웨어 제품의 조립(빌드) 개념입니다. 기본 테스트 방법, 용어. 이 과정에서 논의된 방법론의 테스트 사례의 예입니다. 어셈블리(빌드)의 개념, 코드 저장 방법, 도구. 버전 관리 시스템으로 작업을 구성하는 두 가지 원칙. 다양한 제품 카테고리에 대한 제품 출시/전시 프로세스의 특징, 사례. 소프트웨어 아키텍처, 다단계 아키텍처, 아키텍처 기준의 현대 개념. 소프트웨어를 설계할 때 필요한 결정 목록, 데이터 저장 시스템 선택 방법.

Kent Beck – 익스트림 프로그래밍 Frederick Brooks – 신화적인 Man-Month 또는 소프트웨어 시스템이 생성되는 방법. 톰 드마르코 - 마감일. 프로젝트 관리에 관한 소설. 톰 드 마르코, 티모시 리스터 - 곰과의 왈츠. Tom de Marco, Timothy Lister - 인적 요소_ 성공적인 프로젝트 및 팀. Alistair Cowburn - 각 프로젝트에는 고유한 방법론이 있습니다. Alistair Cowburn - 사람은 비선형적이며 소프트웨어를 만드는 데 가장 중요한 구성 요소입니다. Andriy Orlov - 자동화 엔지니어의 메모. 전문적인 고백. Philipp Kratchen - Rational Unified Process 소개. Henrik Kniberg - 스크럼 및 XP: 최전선에서 전하는 메모. 해당 과정에 대한 강의 프레젠테이션