Библиографический список. Вспомогательные процессы анализа

К основным относятся те процессы анализа, которые непосредственно связаны с целями проекта и показателями, характеризующими успешность исполнения проекта:

· анализ сроков - определение соответствия фактических и прогнозных сроков исполнения операций проекта директивным или запланированным;

· анализ стоимости - определение соответствия фактической и прогнозной стоимости операций и фаз проекта директивным или запланированным;

· анализ качества - мониторинг результатов с целью их проверки на соответствие принятым стандартам качества и определения путей устранения причин нежелательных результатов исполнения качества проекта;

· подтверждение целей- процесс формальной приемки результатов проекта его участниками (инвесторами, потребителями и т.д.).

Вспомогательные процессы анализа связаны с анализом факторов, влияющих на цели и критерии успеха проекта. Эти процессы включают:

· оценку исполнения - анализ результатов работы и распределение проектной информации с целью снабжения участников проекта данными о том, как используются ресурсы для достижения целей проекта;

· анализ ресурсов - определение соответствия фактической и прогнозной загрузки и производительности ресурсов запланированным, а также анализ соответствия фактического расхода материалов плановым значениям.

В число процессов анализа не включены анализ взаимодействия с целью оптимизации процедур обработки проектной информации, анализ исполнения контрактов с целью своевременного внесения изменений и предотвращения споров и ряд других процессов, которые не носят регулярного характера (как анализ взаимодействия), либо составляют часть включенных процессов (как анализ контрактов).

В результате анализа либо принимается решение о продолжении исполнения проекта по намеченному ранее плану, либо определяется необходимость применения корректирующих воздействий.

Технология разработки программного обеспечения – это дисциплина, рассматривающая приложение теории, знаний и практики для эффективного построения программных систем, удовлетворяющих требованиям пользователей и заказчиков.

В рамках дисциплины изучается весь спектр процессов, ведущих к созданию программного обеспечения: от разработки требований к ПО, через проектирование, разработку и аттестацию до модернизации программных систем.

Процесс разработки программного обеспечения. Эта часть курса посвящена процессу разработки программного обеспечения. Рассматриваются различные модели процесса разработки, изучаются основные фазы этого процесса: формирование требований, проектирование ПО, аттестация ПО и эволюция ПО.

Управление программными проектами. Под управлением проектом подразумевается деятельность, направленная на реализацию проекта с максимально возможной эффективностью при заданных ограничениях по времени, денежным средствам, а также качеству конечных результатов проекта. Разработка программного обеспечения требует знакомства с методами и инструментами управления проектами.

	Вопрос	Варианты ответа
1.	Что такое информация?	1. Это данные, хранящиеся в информационной системе 2. Это данные, помещенные в значимый и полезный контекст и сообщенные получателю 3. Это данные, содержащиеся в документе 4. Это распечатанный документ
2.	Для чего необходима информационная система?	1. Для накопления данных 2. Для подготовки отчетов 3. Для обработки данных и операций с целью предоставить своим пользователям информацию 4. Для сбора данных и принятия решений
3.	Что такое ценность информации?	1. Это стоимость информации 2. Это прибыль, получаемая от использования информации 3. Это выгода, даваемая информацией за вычетом стоимости ее получения
4.	Что происходит в организации при внедрении автоматизированных информационных систем?	1. Сокращается количество работников и уменьшаются затраты 2. Сокращаются затраты 3. Увеличиваются затраты на администрирование 4. Перераспределяется рабочее время сотрудников и улучшается качество информации
5.	Для чего необходима информация? Укажите вариант, который наиболее точно отражает необходимость информации	1. Информация используется для получения данных 2. Информация необходима для снятия неопределенности и поддержания модели объекта управления в актуальном состоянии 3. Информация нужна для формирования документов
6.	Чем определяется качество информации?	1. Достоверностью и управлением 2. Оперативностью и достоверностью 3. Источником и приемником
7.	Какие основные функции информационных систем?	1. Сканирование информации, хранение и печать 2. Поиск данных, организация пользовательского интерфейса, и хранение. 3. Ввод данных, хранение, обработка, представление. 4. Расшифровка информации, ввод информации, и представление
8.	Какие подсистемы являются основными подсистемами автоматизированной информационной системы?	1. Подсистемы сбора и хранения данных 2. Подсистемы сбора, хранения, обработки данных 3. Подсистемы обработки и представления данных 4. 1,2 5. 1,3 6. Все выше перечисленные
9.	Назовите отличительные свойства «знаний»	1. Определенность, возможность использования 2. Структурированность, удобство доступа и усвоения. 3. Структурированность, удобство доступа и усвоения, концентрированность, наличие процедур обработки. 4. Все вышеперечисленные
10.	Какой этап процесса разработки программного обеспечения (ПО) обеспечивает качество продукта?	1. Проектирование и анализ требований 2. Программирование и проектирование 3. Тестирование и программирование 4. Все
11.	Какие стадии включает в себя процесс разработки программного обеспечения (ПО)?	1. Концептуальное проектирование, детальное проектирование, программирование, тестирование, интеграция, испытания, ввод в действие и эксплуатация 2. Анализ требований к ПО, концептуальное проектирование, детальное проектирование, программирование, тестирование, интеграция, испытания, ввод в действие и эксплуатация 3. Анализ требований к ПО, концептуальное проектирование, детальное проектирование, интеграция, программирование, тестирование, испытания, ввод в действие и эксплуатация 4. Анализ требований к ПО, концептуальное проектирование, детальное проектирование, интеграция, испытания, программирование, тестирование, ввод в действие и эксплуатация
12.	Что в себя включает техническое задание?	1. Проект системы 2. Требования к системе 3. Требования к команде разработчиков 4. Все перечисленные выше пункты
13.	Что такое жизненный цикл ПО (Выберите наиболее точное определение)?	1. Это промежуток времени от момента возникновения необходимости ПО до момента вывода его из эксплуатации 2. Это промежуток времени от момента возникновения необходимости ПО до момента вывода его из эксплуатации, отражаемый соответствующими процессами 3. Это промежуток времени от момента возникновения необходимости ПО до момента внедрения 4. Это набор процессов разработки ПО
14.	За счет чего достигается эффективность жизненного цикла ПО?	1. За счет сокращения времени разработки 2. За счет регламентирования порядка и содержания результатов проведения работ 3. За счет автоматизации выполнения отдельных этапов и операций 4. За счет рационального разделения труда между специалистами разной квалификации и проблемной ориентации применяемой технологии проектирования, разработки и сопровождения 5. 1,3,4 6. 2,3,4
15.	Укажите основные особенности современных технологий разработки ПО (выделите наиболее точное определение)	1. Технология создания и развития ПО и БД опирается на модели жизненного цикла 2. Переход к массовому индустриальному созданию сложных информационных систем большими коллективами специалистов 3. Разработка небольших модулей небольшими коллективами. 4. Автоматизация отельных работ и этапов 5. Использование языков программирования третьего поколения 6. 1,3,4 7. 1,2,4 8. 3,5
16.	Для чего используются стандарты жизненного цикла ПО?	1. Для автоматизации работ 2. Для распределения заданий между программистами 3. Для регламентации отдельных процессов и работ
17.	Какие основные объекты стандартизации Вы знаете?	1. Структура программного обеспечения 2. Документация 3. Процессы разработки 4. Квалификация программистов 5. 1,2,4 6. 1,2,3,4 7. 1,2,3
18.	Для чего необходим процесс анализа требований к ПО (информационной системе)?	1. Для согласования требований заказчика и возможностей исполнителя 2. Для выявления технических деталей, необходимых для программирования ИС 3. Для обследования объекта и формирования моделей
19.	Какие Вы знаете модели жизненного цикла?	1. Каскадная 2. Каскадная с выборочным контролем 3. Каскадная с поэтапным контролем 4. Спиральная 5. Структурная 6. Гибкая с промежуточным контролем 7. 2,3,5 8. 1,2,3,4 9. 2,4,6, 10.1,3,4
20.	Каковы основные особенности процесса анализа требований?	1. Анализ требований дополнительный и необязательный этап ЖЦ 2. Анализ требований - важнейший среди всех этапов ЖЦ 3. Оказывает существенное влияние на все последующие этапы 4. Сказывается лишь на этапе проектирования, не оказывая влияния на последующие этапы 5. Представляет собой строго формализованный процесс на базе однозначных критериев 6. Является наименее изученным и понятым процессом
21.	Какие основные задачи необходимо решить на этапе анализа требований? (выделите верные варианты)	1. Выбрать правильную технологию решения задачи 2. Понять, что предполагается сделать при разработке 3. Выяснить отношение руководства организации к реализуемому проекту 4. Обсудить требования к разрабатываемому продукту и закрепить их в виде устной договорённости 5. Задокументировать то, что предполагается сделать при разработке 6. Использовать при формулировке требований достаточно простой и понятный заказчику язык 7. Использовать строгий формальный язык, основанный на терминологии афтоматизированных информационных систем
22.	Системный анализ представляет собой	1. Раздел общей теории систем 2. Способ исследования, основанный на графических методологиях 3. Метод исследования систем путём иерархической декомпозиции «от простого к сложному» 4. Методика улучшающего вмешательства в проблемную ситуацию 5. Метод математического анализа и оптимизации систем
23.	Основная проблема системного анализа заключается	1. Избыточных требованиях заказчика к разработчику 2. Недостаточной внимательности разработчика к требованиям заказчика 3. В трудности достижения взаимопонимания между разработчиком и заказчиком из-за отсутствия общего языка и терминологии
24.	Что такое структурный анализ?	1. Раздел общей теории систем 2. Способ исследования, основанный на графических методологиях 3. Методика улучшающего вмешательства в проблемную ситуацию 4. Метод математического анализа и оптимизации систем 5. Метод исследования систем путём иерархической декомпозиции «от простого к сложному»
25.	В чём заключаются характерные особенности структурного анализа (выделите верные варианты)?	1. изучение системы как единой взаимосвязанной структуры 2. разбиение на уровни абстракции 3. ограничение числа элементов на каждом из уровней абстракции 4. описание каждого из уровней абстракции как минимум 9 компонентами 5. максимальный уровень детальности описания на каждом уровне абстракции 6. ограниченный контекст, включающий лишь существенные на каждом уровне детали 7. двойственность данных и операций над ними 8. обязательное разделение исследования данных и процессов 9. использование свободного естественного языка записи 10.использование строгих формальных правил записи 11.полный охват системы с первой итерации 12.последовательное приближение к конечному результату
26.	Какие средства струк-турного анализа исполь-зуются для моделиро-вания функциональ-ности системы?	1. DFD (Data Flow Diagrams) 2. SADT (Structured Analysis and Design Technique) 3. ERD (Entity-Relationship diagrams) 4. STD (State Transition Diagrams)
27.	Какие средства структурного анализа используются для моделирования данных системы?	1. DFD (Data Flow Diagrams) 2. SADT (Structured Analysis and Design Technique) 3. ERD (Entity-Relationship diagrams) 4. STD (State Transition Diagrams)
28.	Какие средства структурного анализа используются для моделирования динамики системы?	1. DFD (Data Flow Diagrams) 2. SADT (Structured Analysis and Design Technique) 3. ERD (Entity-Relationship diagrams) 4. STD (State Transition Diagrams)
29.	Для чего необходим стандарт ISO 12207?	1. Для регламентации структуры ПО 2. Для регламентации процессов жизненного цикла ПО 3. Для регламентации документации 4. 1,3 5. 2,3 6. 1,2
30.	Для чего необходим процесс проектирование ПО (информационной системе)? Выберите наиболее точный ответ.	1. Для создания технической документации на ПО 2. Для выработки технических решений, достаточных для создания или модификации ПО. 3. Для разработки структуры ПО и схем базы данных
31.	Что такое "модель жизненного цикла ПО"?	1. Это порядок выполнения основных процессов в рамках жизненного цикла ПО 2. Это представление проекта разработки программного обеспечения (ПО) 3. Это документ, в котором для каждого разработчика указаны его работы
32.	Описание каких основных групп процессов включает в себя стандарт ISO 12207	1. Основные процессы ЖЦ, поддержка ЖЦ, организация ЖЦ 2. Основные процессы ЖЦ, поддержка ЖЦ, организация ЖЦ, тестирование ПО 3. Основные процессы ЖЦ, разработка, проектирование и тестирование 4. Проектирование, разработка, тестирование
33.	В каком стандарте РФ устанавливаются требования к техническому заданию на автоматизированную информационную систему?	1. ГОСТ 34.602-89 2. ГОСТ 34.601-90 3. ИСО 34.602-89 4. ИСО 34.601-89
34.	На какой стадии ЖЦ ПО осуществляются наибольшие затраты?	1. Тестирование 2. Программирование и тестирование 3. Анализ требований и концептуальное проектирование 4. Детальное проектирование и программирование
35.	Какие основные требования предъявляются к проекту современной автоматизированной информационной системы?	1. Проект должен обеспечивать масштабируемость АИС 2. Проект должен обеспечивать мобильность АИС 3. Проект АИС должен обеспечивать максимальное повторное использование существующих компонент 4. Проект должен обеспечивать мобильность АИС 5. Проект должен обеспечивать распределенность АИС в пространстве 6. Проект должен обеспечивать распределенность АИС во времени 7. Все вышеперечисленное
36.	Что такое проектирование?	1. Разработка технической документации на ПО 2. Разработка графических моделей на ПО 3. Формирование технического проекта ПО 4. Процесс разработки технических решений, достаточных для создания или модификации ПО
37.	Что такое "методология проектирования ПО"?	1. Совокупность принципов, методов, моделей, используемых для проектирования ПО 2. Методы, используемые для проектирования ПО 3. Набор инструментов проектирования ПО
38.	Какие основные методы используются при проектировании программного обеспечения?	1. Агрегация и инкапсуляция 2. Абстракция и спецификация 3. Агрегация и спецификация
39.	Какие методологии проектирования получили наибольшее распространение?	4. Объектно-ориентированные 5. Методологии, ориентированные на потоки данных 6. Комбинированные 7. Структурно-компонентные 8. 1,2,3 9. 1,2 10.1,2,3,4
40.	В чем заключается принцип абстрагирования?	1. Выделение существенных аспектов системы с целью представления проблемы в простом общем виде 2. Выделение несущественных аспектов системы с целью представления проблемы в простом общем виде 3. Декомпозиция системы на отдельные составляющие с целью представления проблемы в простом общем виде

1. Barker, R. CASE*Method. Entity-Relationship Modelling [Текст]/ R.Barker - Copyright Oracle Corporation UK Limited, Addison-Wesley Publishing Co., 1990.

2. Boehm, B.W. A Spiral Model of Software Development and Enhancement. ACM [Текст]/ Boehm B.W. - SIGSOFT Software Engineering Notes, Aug. 1986

3. DATARUN Concepts [Текст] / Computer Systems Advisers Research Ltd., 1994.

4. DeMarco, Tom. Structured Analysis and System Specification. [Текст] / Tom DeMarco. - Yourdon Press, New York, 1978.

5. Gane, Chris. Structured System Analysis [Текст]/ Chris Gane, Trish Sarson. - Prentice-Hall, 1979.

6. IEEE Std 1209-1992. IEEE Recommended Practice for the Evaluation and Selection of CASE Tools. [Текст]

7. IEEE Std 1348-1995. IEEE Recommended Practice for the Adoption of CASE Tools. [Текст]

11. SE Companion Installation and Administration Manual. [Текст] /SECA Inc., 1995.

12. Uniface V6.1 Designers' Guide. [Текст] / Uniface B.V., Netherlands, 1994.

13. Westmount I-CASE User Manual. [Текст] / Westmount Technology B.V., Netherlands, 1994.

14. Yourdon, Edward. Modern Structured Analysis. [Текст] / Edward Yourdon. - Prentice-Hall, 1989.

15. Автоматизация управления предприятием [Текст] / В.В. Баронов [и др.] - М.: ИНФРА-М, 2000. - 239 с.

16. Брауде, Э. Дж. Технология разработки программного обеспечения [Текст] / Э. Дж. Брауде – СПб.: Питер, 2004. – 655 с.: ил.

17. Буч, Гради. Язык UML. Руководство пользователя: Пер. с англ. /Г. Буч, Д. Рамбо, А. Джекобсон - М.: ДМК, 2000.

18. Вендров, А.М. CASE-технологии. Современные методы и средства проектирования информационных систем. [Текст] / А.М. Вендров. - М.: Финансы и статистика, 1998.

19. Вендров, А.М. Проектирование программного обеспечения экономических информационных систем [Текст] / А.М. Вендров. - М.: Финансы и статистика, 2002.

20. Зиндер, Е.З. Бизнес-реинжиниринг и технологии системного проектирования: Учебное пособие [Текст] / Е.З. Зиндер. - М., Центр информационных технологий, 1996.

21. Калянов, Г.Н. CASE: Структурный системный анализ (автоматизация и применение) [Текст] / Г.Н. Калянов. - М.: ЛОРИ, 1996.

22. Калянов, Г.Н. Case-технологии: консалтинг в автоматизации бизнес-процессов [Текст] / Г.Н. Калянов. - М.: «Горячая линия - Телеком», 2002.

23. Калянов, Г.Н. Консалтинг при автоматизации предприятий (подходы, методы, средства) [Текст] / Г.Н. Калянов - М.: СИНТЕГ, 1997.

24. Калянов, Г.Н. Теория и практика реорганизации бизнес-процессов [Текст] / Г.Н. Калянов. - М.: СИНТЕГ, 2000.

25. Константайн, Л. Разработка программного обеспечения [Текст] / Л. Константайн, Л. Локвуд. – СПб.: Питер, 2004. – 592 с.: ил.

26. Куперштейн, В.И. Microsoft Project в делопроизводстве и управлении [Текст] / В.И. Куперштейн – СПб.: БХВ-Петербург, 2003. – 480с.:ил.

27. Маклаков, С.В. BPWin и ERWin.CASE-средства разработки информационных систем [Текст] / С.В. Маклаков. - М.: ДИАЛОГ-МИФИ, 2000.

28. Маклаков, С.В. Создание информационных систем с AllFusion Modeling Suite [Текст] / С.В. Маклаков – М.:ДИАЛОГ-МИФИ, 2003 – 432 с.: ил.

29. Марка, Д.А. Методология структурного анализа и проектирования [Текст] / Д.А. Марка, К. Мак Гоуэн. – М.: Метатехнология, 1993.

30. Международные стандарты, поддерживающие жизненный цикл программных средств [Текст] / М.: МП "Экономика", 1996.

31. Новоженов, Ю.В. Объектно-ориентированные технологии разработки сложных программных систем [Текст] / Ю.В. Новоженов. - М., 1996.

32. Ойхман, Е.Г. Реинжиниринг бизнеса: реинжиниринг организации и информационных технологий [Текст] / Е.Г. Ойхман, Э.В. Попов. - М.: Финансы и статистика, 1997.

33. Орлов, С. Технологии разработки программного обеспечения: Уч. [Текст] / С. Орлов -СПб.:Питер,2003.-480с.-(Учеб. пособие)

34. Садовский, В.Н. Основания общей теории систем. Логико-методологический анализ [Текст] / В.Н. Садовский. - М.: Наука, 1974. - 278 с.

35. Шеер, А.В. Бизнес-процессы. Основные понятия. Теория. Методы: Пер. с англ. - 2-е изд., испр. и доп./ А.В. Шеер - М.: АОЗТ «Просветитель», 1999.

36. Шеер, А.В.. Моделирование бизнес-процессов: Пер. с англ. - 2-е изд., испр. и доп./ А.В. Шеер. - М.: ООО «Издательство «Серебряные нити», 2000.

37. Шлеер, С. Объектно-ориентированный анализ: моделирование мира в состояниях [Текст] /С. Шлеер, С. Меллор. – Киев.: Диалектика, 1993.

38. Якобсон, А. Унифицированный процесс разработки программного обеспечения. [Текст] / А. Якобсон, Г. Буч, Дж. Рэмбо – СПб.: Питер, 2002. – 496 с.: ил.

	Вопрос	Варианты ответа
	Что такое информация?	Это данные, хранящиеся в информационной системе Это данные, помещенные в значимый и полезный контекст и сообщенные получателю Это данные, содержащиеся в документе Это распечатанный документ
	Для чего необходима информационная система?	Для накопления данных Для подготовки отчетов Для обработки данных и операций с целью предоставить своим пользователям информацию Для сбора данных и принятия решений
	Что такое ценность информации?	Это стоимость информации Это прибыль, получаемая от использования информации Это выгода, даваемая информацией за вычетом стоимости ее получения
	Что происходит в организации при внедрении автоматизированных информационных систем?	Сокращается количество работников и уменьшаются затраты Сокращаются затраты Увеличиваются затраты на администрирование Перераспределяется рабочее время сотрудников и улучшается качество информации
	Для чего необходима информация? Укажите вариант, который наиболее точно отражает необходимость информации	Информация используется для получения данных Информация необходима для снятия неопределенности и поддержания модели объекта управления в актуальном состоянии Информация нужна для формирования документов
	Чем определяется качество информации?	Достоверностью и управлением Оперативностью и достоверностью Источником и приемником
	Какие основные функции информационных систем?	Сканирование информации, хранение и печать Поиск данных, организация пользовательского интерфейса, и хранение. Ввод данных, хранение, обработка, представление. Расшифровка информации, ввод информации, и представление
	Какие подсистемы являются основными подсистемами автоматизированной информационной системы?	Подсистемы сбора и хранения данных Подсистемы сбора, хранения, обработки данных Подсистемы обработки и представления данных 1,2 1,3 Все выше перечисленные
	Назовите отличительные свойства «знаний»	Определенность, возможность использования Структурированность, удобство доступа и усвоения. Структурированность, удобство доступа и усвоения, концентрированность, наличие процедур обработки. Все вышеперечисленные
	Какой этап процесса разработки программного обеспечения (ПО) обеспечивает качество продукта?	Проектирование и анализ требований Программирование и проектирование Тестирование и программирование Все
	Какие стадии включает в себя процесс разработки программного обеспечения (ПО)?	Концептуальное проектирование, детальное проектирование, программирование, тестирование, интеграция, испытания, ввод в действие и эксплуатация Анализ требований к ПО, концептуальное проектирование, детальное проектирование, программирование, тестирование, интеграция, испытания, ввод в действие и эксплуатация Анализ требований к ПО, концептуальное проектирование, детальное проектирование, интеграция, программирование, тестирование, испытания, ввод в действие и эксплуатация Анализ требований к ПО, концептуальное проектирование, детальное проектирование, интеграция, испытания, программирование, тестирование, ввод в действие и эксплуатация
	Что в себя включает техническое задание?	Проект системы Требования к системе Требования к команде разработчиков Все перечисленные выше пункты
	Что такое жизненный цикл ПО (Выберите наиболее точное определение)?	Это промежуток времени от момента возникновения необходимости ПО до момента вывода его из эксплуатации Это промежуток времени от момента возникновения необходимости ПО до момента вывода его из эксплуатации, отражаемый соответствующими процессами Это промежуток времени от момента возникновения необходимости ПО до момента внедрения Это набор процессов разработки ПО
	За счет чего достигается эффективность жизненного цикла ПО?	За счет сокращения времени разработки За счет регламентирования порядка и содержания результатов проведения работ За счет автоматизации выполнения отдельных этапов и операций За счет рационального разделения труда между специалистами разной квалификации и проблемной ориентации применяемой технологии проектирования, разработки и сопровождения 1,3,4 2,3,4
	Укажите основные особенности современных технологий разработки ПО (выделите наиболее точное определение)	Технология создания и развития ПО и БД опирается на модели жизненного цикла Переход к массовому индустриальному созданию сложных информационных систем большими коллективами специалистов Разработка небольших модулей небольшими коллективами. Автоматизация отельных работ и этапов Использование языков программирования третьего поколения 1,3,4 1,2,4 3,5
	Для чего используются стандарты жизненного цикла ПО?	Для автоматизации работ Для распределения заданий между программистами Для регламентации отдельных процессов и работ
	Какие основные объекты стандартизации Вы знаете?	Структура программного обеспечения Документация Процессы разработки Квалификация программистов 1,2,4 1,2,3,4 1,2,3
	Для чего необходим процесс анализа требований к ПО (информационной системе)?	Для согласования требований заказчика и возможностей исполнителя Для выявления технических деталей, необходимых для программирования ИС Для обследования объекта и формирования моделей
	Какие Вы знаете модели жизненного цикла?	Каскадная Каскадная с выборочным контролем Каскадная с поэтапным контролем Спиральная Структурная Гибкая с промежуточным контролем 2,3,5 1,2,3,4 2,4,6, 1,3,4
	Каковы основные особенности процесса анализа требований?	Анализ требований дополнительный и необязательный этап ЖЦ Анализ требований - важнейший среди всех этапов ЖЦ Оказывает существенное влияние на все последующие этапы Сказывается лишь на этапе проектирования, не оказывая влияния на последующие этапы Представляет собой строго формализованный процесс на базе однозначных критериев Является наименее изученным и понятым процессом
	Какие основные задачи необходимо решить на этапе анализа требований? (выделите верные варианты)	Выбрать правильную технологию решения задачи Понять, что предполагается сделать при разработке Выяснить отношение руководства организации к реализуемому проекту Обсудить требования к разрабатываемому продукту и закрепить их в виде устной договорённости Задокументировать то, что предполагается сделать при разработке Использовать при формулировке требований достаточно простой и понятный заказчику язык Использовать строгий формальный язык, основанный на терминологии афтоматизированных информационных систем
	Системный анализ представляет собой	Раздел общей теории систем Способ исследования, основанный на графических методологиях Метод исследования систем путём иерархической декомпозиции «от простого к сложному» Методика улучшающего вмешательства в проблемную ситуацию Метод математического анализа и оптимизации систем
	Основная проблема системного анализа заключается	Избыточных требованиях заказчика к разработчику Недостаточной внимательности разработчика к требованиям заказчика В трудности достижения взаимопонимания между разработчиком и заказчиком из-за отсутствия общего языка и терминологии
	Что такое структурный анализ?	Раздел общей теории систем Способ исследования, основанный на графических методологиях Методика улучшающего вмешательства в проблемную ситуацию Метод математического анализа и оптимизации систем Метод исследования систем путём иерархической декомпозиции «от простого к сложному»
	В чём заключаются характерные особенности структурного анализа (выделите верные варианты)?	изучение системы как единой взаимосвязанной структуры разбиение на уровни абстракции ограничение числа элементов на каждом из уровней абстракции описание каждого из уровней абстракции как минимум 9 компонентами максимальный уровень детальности описания на каждом уровне абстракции ограниченный контекст, включающий лишь существенные на каждом уровне детали двойственность данных и операций над ними обязательное разделение исследования данных и процессов использование свободного естественного языка записи использование строгих формальных правил записи полный охват системы с первой итерации последовательное приближение к конечному результату
	Какие средства струк-турного анализа исполь-зуются для моделиро-вания функциональ-ности системы?	DFD (Data Flow Diagrams) SADT (Structured Analysis and Design Technique) ERD (Entity-Relationship diagrams) STD (State Transition Diagrams)
	Какие средства структурного анализа используются для моделирования данных системы?	DFD (Data Flow Diagrams) SADT (Structured Analysis and Design Technique) ERD (Entity-Relationship diagrams) STD (State Transition Diagrams)
	Какие средства структурного анализа используются для моделирования динамики системы?	DFD (Data Flow Diagrams) SADT (Structured Analysis and Design Technique) ERD (Entity-Relationship diagrams) STD (State Transition Diagrams)
	Для чего необходим стандарт ISO 12207?	Для регламентации структуры ПО Для регламентации процессов жизненного цикла ПО Для регламентации документации 1,3 2,3 1,2
	Для чего необходим процесс проектирование ПО (информационной системе)? Выберите наиболее точный ответ.	Для создания технической документации на ПО Для выработки технических решений, достаточных для создания или модификации ПО. Для разработки структуры ПО и схем базы данных
	Что такое "модель жизненного цикла ПО"?	Это порядок выполнения основных процессов в рамках жизненного цикла ПО Это представление проекта разработки программного обеспечения (ПО) Это документ, в котором для каждого разработчика указаны его работы
	Описание каких основных групп процессов включает в себя стандарт ISO 12207	Основные процессы ЖЦ, поддержка ЖЦ, организация ЖЦ Основные процессы ЖЦ, поддержка ЖЦ, организация ЖЦ, тестирование ПО Основные процессы ЖЦ, разработка, проектирование и тестирование Проектирование, разработка, тестирование
	В каком стандарте РФ устанавливаются требования к техническому заданию на автоматизированную информационную систему?	ГОСТ 34.602-89 ГОСТ 34.601-90 ИСО 34.602-89 ИСО 34.601-89
	На какой стадии ЖЦ ПО осуществляются наибольшие затраты?	Тестирование Программирование и тестирование Анализ требований и концептуальное проектирование Детальное проектирование и программирование
	Какие основные требования предъявляются к проекту современной автоматизированной информационной системы?	Проект должен обеспечивать масштабируемость АИС Проект должен обеспечивать мобильность АИС Проект АИС должен обеспечивать максимальное повторное использование существующих компонент Проект должен обеспечивать мобильность АИС Проект должен обеспечивать распределенность АИС в пространстве Проект должен обеспечивать распределенность АИС во времени Все вышеперечисленное
	Что такое проектирование?	Разработка технической документации на ПО Разработка графических моделей на ПО Формирование технического проекта ПО Процесс разработки технических решений, достаточных для создания или модификации ПО
	Что такое "методология проектирования ПО"?	Совокупность принципов, методов, моделей, используемых для проектирования ПО Методы, используемые для проектирования ПО Набор инструментов проектирования ПО
	Какие основные методы используются при проектировании программного обеспечения?	Агрегация и инкапсуляция Абстракция и спецификация Агрегация и спецификация
	Какие методологии проектирования получили наибольшее распространение?	Объектно-ориентированные Методологии, ориентированные на потоки данных Комбинированные Структурно-компонентные 1,2,3 1,2 1,2,3,4
	В чем заключается принцип абстрагирования?	Выделение существенных аспектов системы с целью представления проблемы в простом общем виде Выделение несущественных аспектов системы с целью представления проблемы в простом общем виде Декомпозиция системы на отдельные составляющие с целью представления проблемы в простом общем виде

Barker, R. CASE*Method. Entity-Relationship Modelling [Текст]/ R.Barker - Copyright Oracle Corporation UK Limited, Addison-Wesley Publishing Co., 1990.

Boehm, B.W. A Spiral Model of Software Development and Enhancement. ACM [Текст]/ Boehm B.W. - SIGSOFT Software Engineering Notes, Aug. 1986

DeMarco, Tom. Structured Analysis and System Specification. [Текст] / Tom DeMarco. - Yourdon Press, New York, 1978.

Gane, Chris. Structured System Analysis [Текст]/ Chris Gane, Trish Sarson. - Prentice-Hall, 1979.

IEEE Std 1209-1992. IEEE Recommended Practice for the Evaluation and Selection of CASE Tools. [Текст]

IEEE Std 1348-1995. IEEE Recommended Practice for the Adoption of CASE Tools. [Текст]

SE Companion Installation and Administration Manual. [Текст] /SECA Inc., 1995.

Westmount I-CASE User Manual. [Текст] / Westmount Technology B.V., Netherlands, 1994.

Yourdon, Edward. Modern Structured Analysis. [Текст] / Edward Yourdon. - Prentice-Hall, 1989.

Автоматизация управления предприятием [Текст] / В.В. Баронов [и др.] - М.: ИНФРА-М, 2000. - 239 с.

Брауде, Э. Дж. Технология разработки программного обеспечения [Текст] / Э. Дж. Брауде – СПб.: Питер, 2004. – 655 с.: ил.

Буч, Гради. Язык UML. Руководство пользователя: Пер. с англ. /Г. Буч, Д. Рамбо, А. Джекобсон - М.: ДМК, 2000.

Вендров, А.М. CASE-технологии. Современные методы и средства проектирования информационных систем. [Текст] / А.М. Вендров. - М.: Финансы и статистика, 1998.

Вендров, А.М. Проектирование программного обеспечения экономических информационных систем [Текст] / А.М. Вендров. - М.: Финансы и статистика, 2002.

Зиндер, Е.З. Бизнес-реинжиниринг и технологии системного проектирования: Учебное пособие [Текст] / Е.З. Зиндер. - М., Центр информационных технологий, 1996.

Калянов, Г.Н. CASE: Структурный системный анализ (автоматизация и применение) [Текст] / Г.Н. Калянов. - М.: ЛОРИ, 1996.

Калянов, Г.Н. Case-технологии: консалтинг в автоматизации бизнес-процессов [Текст] / Г.Н. Калянов. - М.: «Горячая линия - Телеком», 2002.

Калянов, Г.Н. Консалтинг при автоматизации предприятий (подходы, методы, средства) [Текст] / Г.Н. Калянов - М.: СИНТЕГ, 1997.

Калянов, Г.Н. Теория и практика реорганизации бизнес-процессов [Текст] / Г.Н. Калянов. - М.: СИНТЕГ, 2000.

Константайн, Л. Разработка программного обеспечения [Текст] / Л. Константайн, Л. Локвуд. – СПб.: Питер, 2004. – 592 с.: ил.

Куперштейн, В.И. Microsoft Project в делопроизводстве и управлении [Текст] / В.И. Куперштейн – СПб.: БХВ-Петербург, 2003. – 480с.:ил.

Маклаков, С.В. BPWin и ERWin.CASE-средства разработки информационных систем [Текст] / С.В. Маклаков. - М.: ДИАЛОГ-МИФИ, 2000.

Маклаков, С.В. Создание информационных систем с AllFusion Modeling Suite [Текст] / С.В. Маклаков – М.:ДИАЛОГ-МИФИ, 2003 – 432 с.: ил.

Марка, Д.А. Методология структурного анализа и проектирования [Текст] / Д.А. Марка, К. Мак Гоуэн. – М.: Метатехнология, 1993.

Международные стандарты, поддерживающие жизненный цикл программных средств [Текст] / М.: МП "Экономика", 1996.

Новоженов, Ю.В. Объектно-ориентированные технологии разработки сложных программных систем [Текст] / Ю.В. Новоженов. - М., 1996.

Ойхман, Е.Г. Реинжиниринг бизнеса: реинжиниринг организации и информационных технологий [Текст] / Е.Г. Ойхман, Э.В. Попов. - М.: Финансы и статистика, 1997.

Орлов, С. Технологии разработки программного обеспечения: Уч. [Текст] / С. Орлов -СПб.:Питер,2003.-480с.-(Учеб. пособие)

Садовский, В.Н. Основания общей теории систем. Логико-методологический анализ [Текст] / В.Н. Садовский. - М.: Наука, 1974. - 278 с.

Шеер, А.В. Бизнес-процессы. Основные понятия. Теория. Методы: Пер. с англ. - 2-е изд., испр. и доп./ А.В. Шеер - М.: АОЗТ «Просветитель», 1999.

Шеер, А.В.. Моделирование бизнес-процессов: Пер. с англ. - 2-е изд., испр. и доп./ А.В. Шеер. - М.: ООО «Издательство «Серебряные нити», 2000.

Шлеер, С. Объектно-ориентированный анализ: моделирование мира в состояниях [Текст] /С. Шлеер, С. Меллор. – Киев.: Диалектика, 1993.

Якобсон, А. Унифицированный процесс разработки программного обеспечения. [Текст] / А. Якобсон, Г. Буч, Дж. Рэмбо – СПб.: Питер, 2002. – 496 с.: ил.

1 Цели при разработке программного обеспечения 5

2 Жизненный цикл ПО. Модели жизненного цикла 8

3.4.2 Контекстная диаграмма и детализация процессов 21

4 Построение модели в DFD на примере банковской задачи 23

7 Методология функционального моделирования SADT (IDEF0) 34

7.2.3 Диаграмма «Только для просмотра» (For Exposition Only – FEO) 42

9.1 Соответствие объектов моделей процессов и моделей данных 52

9.2 Экспорт между моделью данных и моделью процессов 53

10.2 Правила валидации и значения по умолчанию 56

10.4.1 Значения RI, используемые ERWin для различных типов связей 59

11 Тестирование и сертификация программного обеспечения 60

11.1 Дестабилизирующие факторы и методы обеспечения высокого качества функционирования ПО 61

11.2 Использование среды автоматизированного тестирования Platinum TESTBytes 62

11.3 Методы обеспечения качества и надежности программных средств 63

11.4 Использование CASE для повышения качества ПО 63

11.5 Влияние стандартов открытых систем на качество ПО 64

11.6 Повышение качества ПО путем тестирования 65

11.7 Основные особенности процесса тестирования ПО 65

11.8 Организационные особенности тестирования 65

12 Организация и планирование тестирования для обеспечения качества ПО 67

13 Стандарты, регламентирующие разработку ПО 70

13.1 Стандарт ISO 12207:1995 - Процессы жизненного цикла программных средств 70

13.3 Серия стандартов ГОСТ 34-ХХХ «Информационная технология» 77

13.3.1 ГОСТ 34.601-90. Информационная технология. Автоматизированные системы. Стадии создания. 77

13.3.2 ГОСТ 34.602-89. Информационная технология. Техническое задание на создание автоматизированной системы 77

13.3.3 ГОСТ 34.603-92. Информационная технология. Виды испытаний автоматизированных систем 77

14 Управление проектами разработки информационных систем 77

14.6.2 Вспомогательные процессы планирования 80

15 Определение концепции проекта (область применения, цели и подход) 84

15.5.1 Выработать основные положения проекта 85

15.5.2 Определить область применения, цели и подход 85

15.5.4 Получить подтверждение Заказчика и Исполнителя 86

16.4 График движения денежных средств по проекту 89

Нотация диаграмм потоков данных (Data Flow Diagrams) принадлежит к классу средств моделирования функциональных требований к проектируемой системе. С помощью средств данного класса требования разбиваются на функциональные компоненты (процессы) и представляются в виде сети, связанной потоками данных. Главная цель таких средств – продемонстрировать, как каждый процесс преобразует входные данные в выходные, выявить отношения между процессами.

Рассмотрим DFD в нотации Гейна – Сарсона (Gane - Sarson), используемой в CASE-средстве BPWin.

На диаграммах потоков данных функциональные требования представляются с помощью процессов и хранилищ, связанных потоками данных (рис.6).

Поток данных – механизм, использующийся для моделирования передачи информации (физических компонентов) из одной части системы в другую. Поток изображается именованной стрелкой, ориентация которой указывает направление движения информации. Если информация движется между двумя элементами модели в противоположных направлениях, это изображается либо двумя встречными стрелками, либо одной двунаправленной.

Процесс – производит выходные потоки из входных в соответствии с действием, задаваемым именем процесса. Имя должно содержать глагол в неопределенной форме с последующим дополнением (например, ВЫЧИСЛИТЬ МАКСИМАЛЬНУЮ ВЫСОТУ). Кроме того, каждый процесс должен иметь уникальный номер для ссылок на него внутри диаграммы. Номер может использоваться совместно с номером диаграммы для получения уникального индекса процесса во всей модели.

Хранилище (накопитель) данных – позволяет на определенных участках определять данные, которые будут сохраняться в памяти между процессами. Фактически, хранилище представляет собой временной «срез» потока данных. Информация, содержащаяся в хранилище данных, может быть использована в любой момент и выбрана в произвольном порядке. Имя хранилища должно идентифицировать его содержимое и быть существительным. В случае, если поток данных проходит через хранилище и его структура соответствует структуре хранилища, он должен иметь то же самое имя, которое нет необходимости отражать на диаграмме.

Внешняя сущность (терминатор) представляет сущность вне контекста системы, являющуюся источником или приемником данных системы. Имя внешней сущности должно содержать существительное (например, СКЛАД ТОВАРОВ). Узлы, изображаемые внешними сущностями, не должны участвовать ни в какой обработке данных.

Контекстная диаграмма и детализация процессов

Декомпозиция DFD осуществляется путем раскрытия процессов при помощи DFD нижнего уровня.

Контекстная диаграмма – специальный вид DFD, моделирующий систему наиболее общим образом. Контекстная диаграмма отражает интерфейс системы с внешним миром, информационные потоки между системой и внешними сущностями, с которыми она должна быть связана. Контекстная диаграмма идентифицирует внешние сущности и, как правило, единственный процесс, отражающий наиболее общий процесс деятельности, соответствующий главной цели или природе системы.

DFD первого уровня строится как декомпозиция единственного процесса, отраженного на контекстной диаграмме.

Построенная диаграмма первого уровня имеет также множество процессов, каждый из которых в свою очередь может быть описан при помощи DFD нижнего уровня. Таким образом, строится иерархия DFD с контекстной диаграммой в корне дерева. Процесс декомпозиции останавливается тогда, когда процесс может быть эффективно описан при помощи короткой (не более 1 страницы текста или модели) спецификации процесса.

Для контроля и поддержания иерархии моделей и процессов в DFD используются структурированные номера процессов. Нумерация строится следующим образом:

Контекстный процесс – не нумеруется, или имеет номер 1.

Процессы диаграммы первого уровня – имеют номера 1.1, 1.2, 1.3 и т.д.

Процессы диаграммы второго уровня, раскрывающей процесс 1.1 нумеруются 1.1.1, 1.1.2, 1.1.3 и т.д.

Процессы диаграммы второго уровня, раскрывающей процесс 1.2 нумеруются 1.2.1, 1.2.2, 1.2.3 и т.д.

Одни и те же данные или объекты, порожденные одной функцией, могут использоваться сразу в нескольких функциях. Потоки же, порожденные несколькими функциями, могут представлять собой одинаковые или однородные данные, которые затем могут использоваться или перерабатываться в одной точке назначения. Для моделирования таких ситуаций используется механизм разветвления или слияния потоков.

Смысл разветвления или слияния передается наименованием каждой ветви потока. Существуют правила присвоения имен потокам в такой ситуации.

Если поток именован до разветвления, а после разветвления ни одна ветвь не именована, следовательно, каждая ветвь моделирует те же данные что и до разветвления.

Если поток именован до разветвления, а после разветвления часть ветвей именована, а часть – нет, подразумевается, что именованные ветви соответствуют наименованию, а неименованные ветви моделируют те же данные, что и до разветвления.

Недопустима ситуация, когда поток до разветвления не именован, а после разветвления не именована какая-либо ветвь.

Правила именования потоков при слиянии – аналогичны.

При слиянии потоков недопустима ситуация, когда не именована какая-либо из ветвей до слияния и поток после слияния.

Главная цель построения модели в DFD заключается в том, чтобы сделать требования к системе ясными и понятными на каждом уровне детализации, а также разбить требования на части с четко определенными отношениями между ними.

Для достижения этой цели следует пользоваться следующими рекомендациями:

Не загромождать диаграмму несущественными на данном уровне деталями.

Декомпозицию потоков данных осуществлять параллельно с декомпозицией процессов, обе эти работы ведутся параллельно, а не одна после другой.

Для улучшения понимаемости модели выбирать ясные, отражающие суть дела имена объектов модели, стараться не использовать аббревиатуры.

Однократно определять функционально идентичные процессы на самом верхнем уровне, где такой процесс необходим, и ссылаться на него на нижних уровнях.

Использовать простейшие диаграммные техники: если что-то можно описать при помощи DFD, то это и следует сделать, а не использовать более сложные методы.

В соответствии с данными рекомендациями процесс построения модели разбивается на следующие этапы:

Расчленение множества требований и организация их в основные функциональные группы.

Идентификация внешних объектов, с которыми должна быть связана система.

Идентификация основных видов информации, циркулирующих между системой и внешней средой.

Разработка предварительной контекстной диаграммы. Функциональные группы представляются процессами, внешние объекты – внешними сущностями, основные виды информации – потоками данных между процессами и внешними сущностями.

Верификация предварительной контекстной диаграммы, внесение в нее изменений по результатам ответов на возникающие вопросы.

Построение контекстной диаграммы путем слияния всех процессов предварительной диаграммы в один процесс, а также группировки потоков.

Формирование DFD первого уровня на базе процессов предварительной контекстной диаграммы.

Проверка основных требований по DFD первого уровня.

Декомпозиция каждого процесса текущей DFD с помощью детализирующей диаграммы или спецификации процесса.

Проверка основных требований по DFD соответствующего уровня.

Добавление определений новых потоков в словарь данных при каждом их появлении на диаграммах.

Параллельное с процессом декомпозиции изучение требований (в том числе и вновь поступающих), разбиение их на элементарные и идентификация процессов или спецификаций процессов, соответствующих этим требованиям.

После построения каждых 2-3 уровней – ревизия модели с целью проверки ее корректности и улучшения понимаемости.

Построение спецификаций процессов в тех случаях, когда нет необходимости или возможности раскрывать их при помощи DFD.

Построение модели в DFD на примере банковской задачи

В качестве примера создания модели рассмотрим фрагмент проекта системы, организующей работу по обслуживанию клиента банка через банкомат. На этом примере рассмотрим основные базовые техники структурного анализа и проектирования по мере того, как будет возникать необходимость в них. На рисунке 7 приведена контекстная диаграмма системы с единственным процессом («Обслужить»), идентифицирующая внешние сущности «Клиент» и «Компьютер банка» (в компьютере банка хранится информация о состоянии счетов всех клиентов).

Опишем потоки данных, связывающие систему с внешними объектами.

Для банковского обслуживания клиент должен предоставить системе свою «Кредитную карту». С «Кредитной карты» автоматически считывается информация – «Пароль», «Лимит денег», «Детали клиента». Кроме того, клиент должен сообщить свои «Ключевые данные», состоящие из составных частей «Пароль» и «Запрос на обслуживание». «Запрос на обслуживание» представляет собой вариант требуемой клиенту услуги (например, снятие со счета наличных денег).

Банковское обслуживание с точки зрения клиента должно обеспечивать выполнение следующих операций:

Выдать «Сообщение», приглашающее клиента ввести «Ключевые данные».

Выдать клиенту «Выписку» по проведенному обслуживанию. «Выписка» включает в себя следующие элементы: «Выписка о деньгах», «Выписка по балансу», «Выписка по операции».

С компьютером банка контекстный процесс обменивается следующей информацией:

«Протокол обслуживания» включающий в себя элементы: «Обработанная документация», «Денежная сумма», «Данные по истории запроса». Детализация контекстного процесса при помощи DFD нижнего уровня представлена на рис. 8.

Процесс 1 («Получить пароль») осуществляет прием и проверку пароля клиента. Процесс использует следующие потоки данных:

«Сообщение» – используется для информирования клиента о готовности принять пароль.

«Введенный пароль» – элемент внешнего потока «Ключевые данные»;

«Пароль» из хранилища «Данные кредитной карты» для проверки вводимого клиентом пароля.

Процесс 2 («Получить запрос на обслуживание») осуществляет прием и проверку запроса клиента на проведение необходимой ему банковской операции. Процесс использует следующие потоки данных:

«Сообщение» используется для информирования клиента о готовности системы принять запрос на обслуживание.

«Запрос на обслуживание» является элементом внешнего потока «Ключевые данные».

«Лимит денег» из хранилища «Данные кредитной карты» – используется для контроля наличия денег на счете клиента.

Процесс 3 («Обработать запрос на обслуживание») использует следующие потоки данных:

«Данные по счету» от внешней сущности «Компьютер банка».

«Детали клиента» из хранилища «Данные кредитной карты».

Процесс 4 («Обработать кредитную карту») осуществляет считывание информации с кредитной карты. Процесс использует следующие потоки данных:

«Данные кредитной карты». Данный поток на модели не именован, поскольку он полностью соответствует по структуре хранилищу «Данные кредитной карты».

Процессы 1, 2 и 4 являются элементарными, их спецификация будет приведена в лекции по спецификации процессов. Декомпозиция процесса 3 приведена на рис. 9.

Декомпозиция процесса «Обработать запрос на обслуживание»

Процесс 3.1 («Обработать документацию») осуществляет обработку внутренней банковской документации по клиенту. Процесс использует следующие потоки данных:

«Обработанная документация», которая является частью потока «Протокол обслуживания».

Процесс 3.2 («Распечатать баланс клиента») выдает клиенту справку по истории его счета и баланса. Процесс использует потоки:

«Данные по балансу» (часть потока «Данные по счету»).

«Выписка по балансу» (часть потока «Выписка»).

«Данные по истории запроса» (часть потока «Протокол обслуживания»).

Процесс 3.3 («Приготовить деньги клиенту») обеспечивает выдачу наличных денег и информирует компьютер банка об изъятых из банка деньгах. Процесс использует следующие потоки данных:

«Денежная сумма» (часть потока «Протокол обслуживания»).

Процесс 3.4 («Распечатать операцию клиента») выдает справку по истории счета и уведомление по проведенной операции. Процесс использует следующие потоки:

«Выписка по операции» (часть потока «Выписка»).

«Данные по истории запроса» (часть потока «Протокол обслуживания»).

[1] В процессе проекта заказчик может быть изменен. Например, на начальных этапах большого проекта, менеджер комплексного проекта может принять решение о начале работ до согласования с действительным заказчиком сформулированных требований. В этом случае до утверждения требований действительным заказчиком, роль заказчика принимает на себя менеджер комплексного проекта.