Разработка технического задания

Июль 22, 2022

Главная
Образование
Разработка технического задания

Содержание

2. Определения Автоматизированная система (АС) – система, состоящая из персонала и комплекса средств автоматизации его деятельности, реализующая
3. Взаимодействие автоматизированных систем – обмен данными, командами и сигналами между функционирующими АС. Документация на автоматизированную систему
4. Жизненный цикл автоматизированной системы – совокупность взаимосвязанных процессов создания и последовательного изменения состояния АС от формирования
5. Информационная система – система, которая организует хранение и манипулирование информацией о предметной области. Информационная совместимость авто-матизированных
6. Информационное обеспечение автоматизированной системы – совокупность форм документов, классификаторов, нормативной базы и реализованных решений по объемам,
7. Методическое обеспечение автома-тизированной системы – совокупность документов, описывающих технологию функционирования АС, методы выбора и применения пользователями
8. Приемочная документация на автома-тизированную систему – документация, фиксирующая сведения, подтверждающие готовность АС к приемке ее в
9. Процесс создания автоматизированной системы – совокупность работ от формирования исходных требований к системе до ввода в
10. Совместимость автоматизированных систем – комплексное свойство двух или более АС, характеризуемое их способностью взаимодействовать при функционировании.
11. Спецификация программы – форма-лизованное представление требований, предъявляемых к программе, которые должны быть удовлетворены при ее разработке,
12. Технический проект автоматизированной системы – комплект проектных документов на АС, разрабатываемый на стадии «Технический проект», утвержденный
13. Техническое задание на авто-матизированную систему – документ, оформленный в установленном порядке и определяющий цели создания АС,
14. Эксплуатационная документация на автоматизированную систему – часть рабочей документации на АС, предназначенная для использования при эксплуатации
15. Основные стандарты, методологии и своды знаний, где упоминается ТЗ или SRS (Software (or System) Requirements Specification):
16. Как инструмент коммуникации в связке общения заказчик-исполнитель, техническое задание позволяет: 1. обеим сторонам: – представить готовый
17. Когда нет продуманного и четкого технического задания
18. Вопрос: Как разработать техническое задание? Коммерческая организация решила внедрить у себя автоматизированную систему. Она не имеет
19. Вопрос: Как разработать техническое задание? IT-компания занимается услугами по разработке и/или внедрению автоматизированных систем. Это наиболее
20. Что такое техническое задание? ГОСТ: «ТЗ на АС является основным документом, определяющим требования и порядок создания
21. Что такое техническое задание? «Техническое задание – это исходный документ на проектирование технического объекта. Техническое задание
22. ГОСТ 2.114-95 Единая система конструкторской документации. Технические условия ГОСТ 19.201-78 Единая система программной документации. Техническое задание.
23. Основное назначение Технического задания — сформулировать требования к разрабатываемому объекту, т.е. к автоматизированной системе Требования по
24. Виды требований могут быть различными – это зависит от целей проекта Свойства требований: Требование должно быть
25. ВАЖНО!!! На каком языке (в смысле сложности понимания) должно быть написано техническое задание? Должны ли быть
26. Техническое задание – это документ, в основе которого лежат требования, сформулированные на понятном (обычном, привычном) для
27. Технический проект – это документ, который предназначен для технической реализации требований, сформулированных в Техническом задании. В
28. ЗАДАЧА: Сделать качественное Техническое задание, понятное Заказчику, а Технический проект использовать как внутренний документ для взаимоотношений
29. Структура технического задания по ГОСТ: общие сведения; назначение и цели создания (развития) системы; характеристика объектов автоматизации;
30. Техзадание. Раздел 1. Общие сведения: начало
31. Техзадание. Раздел 1. Общие сведения: продолжение
32. Техзадание. Раздел 2. Назначение и цели создания (развития) системы: начало
33. Техзадание. Раздел 2. Назначение и цели создания (развития) системы: продолжение
34. Техзадание. Раздел 3. Характеристика объектов автоматизации :
35. Техзадание. Раздел 4. Требования к системе : ГОСТ расшифровывает перечень таких требований: требования к структуре и
36. Техзадание. Раздел 4. Требования к системе : ВАЖНО: Требования к квалификации. Если квалификация имеющегося персонала явно
37. Техзадание. Раздел 4. Требования к системе : ВАЖНО: Требования к структуре и функционированию системы. Могут быть
38. Техзадание. Раздел 5. Состав и содержание работ по созданию системы :
39. Техзадание. Раздел 6. Порядок контроля и приемки системы:
40. Техзадание. Раздел 7. Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы
41. Техзадание. Раздел 8. Требования к документированию:
42. Техзадание. Раздел 9. Источники разработки:
43. ВАЖНО!!! Разделы 1-9 «Могут» быть включены в Техническое задание, но не «Обязаны». Техзадание должно разрабатываться для
44. Раздел 4 «Требования к системе» Помним: требования должны быть понятными, конкретными и тестируемыми! Рекомендации из книги
45. Рекомендации из книги К.Вигерс «Разработка требований к программному обеспечению» продолжение Используйте больше схем, графиков, таблиц, рисунков
46. Техническое задание. Виды работ при сборе требований к ИС и информации для описания бизнес-процессов
47. Техническое задание. Виды работ при сборе требований к ИС и информации для описания бизнес-процессов никто, кроме
48. Техническое задание. Виды работ при сборе требований к ИС и информации для описания бизнес-процессов
49. Подход к изучению требований к информационной системе с дальнейшим их отражением в Техническом задании
50. ВАЖНО!!! Технического задания процесс трудоемкий, а значит и затратный. Но если он сделан грамотно, то избавляет
51. Понятие «стандарт» Стандарт - в широком смысле слова образец, эталон, модель, принимаемые за исходную для сопоставления
52. Стандарт ISO/IEC 12207 – процессы ЖЦ
53. Основные определения Жизненный цикл ИС – период времени, который начинается с момента принятия решения о необходимости
54. Общая модель ЖЦ системы концепция идеи системы разработка создание утилизация эксплуатация и сопровождение разработка разработка разработка
55. Характеристика стандарта Область применения стандарта: процессы, выполняющиеся в ходе жизненного цикла программной системы Модель жизненного цикла:
56. Цель стандарта Определить полную совокупность процессов, которые могут выполняться в ходе проекта по созданию программной системы
57. Адаптация Поскольку проекты могут сильно различаться, например по масштабам, сложности, рискам и т. п., допускается для
58. Группы процессов Основные - это процессы, непосредственно относящиеся к жизненному циклу информационной системы Вспомогательные - это
60. Модель жизненного цикла программного продукта
61. Под моделью жизненного цикла понимается структура, определяющая последовательность выполнения и взаимосвязи процессов, действий и задач, которые
62. Состав модели ЖЦ ПО стадии - часть процесса создания ПО, ограниченная определенными временными рамками и заканчивающаяся
63. Основные модели ЖЦ Каскадная модель V-образная модель Модель прототипирования Модель быстрой разработки приложений Многопроходная модель Спиральная
64. Каскадная модель Прямолинейная и простая в использовании. Необходим постоянный жесткий контроль за ходом работы. Разрабатываемое программное
65. V-образная модель Простая в использовании. Особое значение придается тестированию и сравнению результатов фаз тестирования и проектирования
66. Модель прототипирования
67. Модель быстрой разработки приложений Проектные группы небольшие (3...7 человек) и составлены из высококвалифицированных специалистов. Уменьшенное время
68. Многопроходная модель Быстро создается работающая система. Уменьшается возможность внесения изменений в процессе разработки. Невозможен переход от
69. Спиральная модель
70. Технологии и инструментальные средства моделирования бизнес-процессов Структурный анализ – метод исследования системы, которое начинается с общего
71. Стандарты моделирования IDEF Назначение семейства стандартов IDEF Стандарты IDEF предназначены для разработки бизнес-моделей и представляют собой
72. Стандарты моделирования IDEF К семейству IDEF относятся следующие стандарты: IDEF0 – методология функционального моделирования IDEF1 –
73. Стандарты моделирования IDEF Стандарт IDEF0 – функциональный блок
74. Стандарты моделирования IDEF Стандарт IDEF0 – декомпозиция
75. Декомпозиция функциональных диаграмм Подфункция функция Подфункция 1 Подфункция 1 Подфункция 2 Подфункция 3 А0 А1 А2
76. Стандарты моделирования IDEF. Два типа диаграмм в стандарте IDEF3 Диаграммы описания последовательности этапов процесса (Process Flow
77. Стандарты моделирования IDEF. Два типа диаграмм в стандарте IDEF3 Второй - диаграммами Состояния Объекта в и
78. Динамические аспекты поведения системы IDEF3
79. Модель потоков данных – диаграммы DFD (Data Flow Diagram)‏
80. Диаграммы ERD - «сущность-связь» Описывают структуры данных, связанных с различными объектами модели; документируют сущности процесса (их
81. Диаграммы ERD - «сущность-связь»
82. UML (Unified Modeling Language) Унифицированный язык моделирования — язык графического описания для объектного моделирования при разработке
83. Виды диаграмм UML
84. Диаграмма случаев использования (прецендентов) (use case diagram) 1 - варианты использования; 2 - действующие лица; 7
85. Пример диаграммы случаев использования (прецендентов) (use case diagram) Основной задачей диаграмм случаев использования (прецендентов) является получение
86. Назначение диаграмм вариантов использования (use case diagram) Определить общие границы функциональности проектируемой системы в контексте моделируемой
87. Примеры диаграммы классов в Rational Rose
88. Диаграммы последовательностей (sequence diagrams) На диаграммах последовательностей, так же как и на диаграммах коммуникаций, показываются роли
90. Скачать презентацию

Слайд 2

Определения
Автоматизированная система (АС) – система, состоящая из персонала и комплекса средств

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

Слайд 3

Взаимодействие автоматизированных систем – обмен данными, командами и сигналами между функционирующими

АС.
Документация на автоматизированную систему – комплект взаимоувязанных документов, полностью определяющих технические требования к АС, проектные и организационные решения по созданию и функционированию АС.

Слайд 4

Жизненный цикл автоматизированной системы – совокупность взаимосвязанных процессов создания и последовательного

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

Слайд 5

Информационная система – система, которая организует хранение и манипулирование информацией о

предметной области.
Информационная совместимость авто-матизированных систем – частная совместимость АС, характеризуемая возможностью использования в них одних и тех же данных и обмена данными между ними.

Слайд 6

Информационное обеспечение автоматизированной системы – совокупность форм документов, классификаторов, нормативной базы

и реализованных решений по объемам, размещению и формам существования информации, применяемой в АС при ее функционировании.

Слайд 7

Методическое обеспечение автома-тизированной системы – совокупность документов, описывающих технологию функционирования АС, методы выбора и

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

Слайд 8

Приемочная документация на автома-тизированную систему – документация, фиксирующая сведения, подтверждающие готовность

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

Слайд 9

Процесс создания автоматизированной системы – совокупность работ от формирования исходных требований

к системе до ввода в действие.
Рабочая документация на авто-матизированную систему – комплект проектных документов на АС, содержащий взаимоувязанные решения по системе в целом, ее функциям, всем видам обеспечения АС, достаточные для комплектации, монтажа, наладки и функционирования АС, ее проверки и обеспечения работоспособности.

Слайд 10

Совместимость автоматизированных систем – комплексное свойство двух или более АС, характеризуемое

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

Слайд 11

Спецификация программы – форма-лизованное представление требований, предъявляемых к программе, которые должны

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

Слайд 12

Технический проект автоматизированной системы – комплект проектных документов на АС, разрабатываемый

на стадии «Технический проект», утвержденный в установленном порядке, содержащий основные проектные решения по системе в целом, ее функциям и всем видам обеспечения АС и достаточный для разработки рабочей документации на АС.

Слайд 13

Техническое задание на авто-матизированную систему – документ, оформленный в установленном порядке

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

Слайд 14

Эксплуатационная документация на автоматизированную систему – часть рабочей документации на АС,

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

Слайд 15

Основные стандарты, методологии и своды знаний, где упоминается ТЗ или SRS

(Software (or System) Requirements Specification):
• ГОСТ 34 • ГОСТ 19 • IEEE STD 830-1998 • ISO/IEC/ IEEE 29148-2011 • RUP • SWEBOK, BABOK и пр.
Спецификация требований программного обеспечения (англ. Software Requirements Specification, SRS) — структурированный набор требований (функционал, производительность, конструктивные ограничения и атрибуты) к программному обеспечению и его внешним интерфейсам. (Определение на основе IEEE Std 1012:2004) Предназначен для того, чтобы установить базу для соглашения между заказчиком и разработчиком (или подрядчиками) о том, как должен функционировать программный продукт.

Слайд 16

Как инструмент коммуникации в связке общения заказчик-исполнитель, техническое задание позволяет:
1.

обеим сторонам:
– представить готовый продукт;
– выполнить попунктную проверку готового продукта (приемочное тестирование — проведение испытаний);
– уменьшить число ошибок, связанных с изменением требований в результате их неполноты или ошибочности (на всех стадиях и этапах создания, за исключением испытаний);
2. заказчику:
– осознать, что именно ему нужно
– требовать от исполнителя соответствия продукта всем условиям, оговоренным в ТЗ
3. исполнителю:
– понять суть задачи, показать заказчику «технический облик» программного изделия или автоматизированной системы;
– спланировать выполнение проекта и работать по намеченному плану – отказаться от выполнения работ, не указанных в ТЗ.

Слайд 17

Когда нет продуманного и четкого технического задания

Слайд 18

Вопрос: Как разработать техническое задание?
Коммерческая организация решила внедрить у себя автоматизированную

систему. Она не имеет собственной IT-службы и решили поступить так: Заинтересованное лицо должно разработать Техническое задание и отдать его на разработку сторонней организации.
Коммерческая организация решила внедрить у себя автоматизированную систему. Она имеет собственную IT-службу. Решили поступить так: разработать Техническое задание, затем согласовать его между IT-службой и Заинтересованными лицами, и реализовать собственными силами.
Госструктура решила затеять IT-проект. Тут все настолько мутно, куча формальностей, откатов, распилов и пр.

Слайд 19

Вопрос: Как разработать техническое задание?
IT-компания занимается услугами по разработке и/или внедрению

автоматизированных систем. Это наиболее сложный случай, ведь приходится работать в самых различных условиях:
Техническое задание разрабатывается для собственных разработчиков (клиенту все равно);
Техническое задание разрабатывается для передачи подрядчику (т.е. группе программистов, находящихся за штатом компании, или отдельному специалисту).

Слайд 20

Что такое техническое задание?
ГОСТ: «ТЗ на АС является основным документом, определяющим

требования и порядок создания (развития или модернизации — далее создания) автоматизированной системы, в соответствии с которым проводится разработка АС и ее приемка при вводе в действие»

Слайд 21

Что такое техническое задание?
«Техническое задание – это исходный документ на проектирование технического

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

Слайд 22

ГОСТ 2.114-95 Единая система конструкторской документации. Технические условия
ГОСТ 19.201-78 Единая система

программной документации. Техническое задание. Требования к содержанию и оформлению
ГОСТ 34.602-89 Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы

Слайд 23

Основное назначение Технического задания — сформулировать требования к разрабатываемому объекту, т.е.

к автоматизированной системе
Требования по ГОСТ к АС:
требования в функциональности - 90% сложности
требования к безопасности и правам доступа;
требования к квалификации персонала и т.п.

Слайд 24

Виды требований могут быть различными – это зависит от целей проекта
Свойства

требований:
Требование должно быть понятным;
Требование должно быть конкретным;
Требование должно быть тестируемым.

Слайд 25

ВАЖНО!!!
На каком языке (в смысле сложности понимания) должно быть написано техническое

задание?
Должны ли быть описаны в нем спецификации различных функций, алгоритмы, типы данных и прочие технические штуки?
А что такое техническое проектирование (указано в ГОСТах), и как оно связано с Техническим заданием?
Где граница между Техническим заданием и Техническим проектом?

Слайд 26

Техническое задание – это документ, в основе которого лежат требования, сформулированные на

понятном (обычном, привычном) для Заказчика языке.
Используется отраслевая терминология, понятная Заказчику.
Никаких привязок к особенностям технической реализации быть не должно. Т.е. на этапе ТЗ в принципе не важно, на какой платформе будут реализовываться эти требования.
Исключения: Если речь идет о внедрении системы на основе уже существующего программного продукта (привязка на уровне экранных форм, форм отчетов и пр.)
Выяснением и формулированием требований, а также разработкой Технического задания должен заниматься бизнес-аналитик.

Слайд 27

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

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

Слайд 28

ЗАДАЧА:
Сделать качественное Техническое задание, понятное Заказчику, а Технический проект использовать как

внутренний документ для взаимоотношений между архитектором системы и программистами.

Слайд 29

Структура технического задания по ГОСТ:
общие сведения;
назначение и цели создания (развития) системы;
характеристика

объектов автоматизации;
требования к системе;
состав и содержание работ по созданию системы;
порядок контроля и приемки системы;
требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие;
требования к документированию;
источники разработки.

Слайд 30

Техзадание. Раздел 1. Общие сведения: начало

Слайд 31

Техзадание. Раздел 1. Общие сведения: продолжение

Слайд 32

Техзадание. Раздел 2. Назначение и цели создания (развития) системы: начало

Слайд 33

Техзадание. Раздел 2. Назначение и цели создания (развития) системы: продолжение

Слайд 34

Техзадание. Раздел 3. Характеристика объектов автоматизации :

Слайд 35

Техзадание. Раздел 4. Требования к системе :
ГОСТ расшифровывает перечень таких требований:
требования

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

Слайд 36

Техзадание. Раздел 4. Требования к системе :
ВАЖНО:
Требования к квалификации. Если квалификация

имеющегося персонала явно недостаточна, лучше прописать требования к организации обучения, программе обучения, срокам и т.п.
Требования к защите информации от несанкционированного доступа. Это требования к разграничению доступа к данным. Если такие требования планируются, то их нужно расписать отдельно, как можно более детально по тем же правилам, что и функциональные требования (понятность, конкретность, тестируемость).
Требования к стандартизации. Такие требования обычно инициирует IT-служба Заказчика. Например, у компании 1С есть требования к оформлению программного кода, проектированию интерфейса и пр.

Слайд 37

Техзадание. Раздел 4. Требования к системе :
ВАЖНО:
Требования к структуре и функционированию

системы. Могут быть описаны требования к интеграции систем между собой, представлено описание общей архитектуры. Чаще требования к интеграции выделяют вообще в отдельный раздел или даже отдельное Техническое задание, т.к. эти требования могут оказаться достаточно сложными.
Требования к видам обеспечения. ГОСТ выделяет такие виды:
Математическое
Информационное
Лингвистическое
Программное
Техническое
Метрологическое
Организационное
Методическое

Слайд 38

Техзадание. Раздел 5. Состав и содержание работ по созданию системы :

Слайд 39

Техзадание. Раздел 6. Порядок контроля и приемки системы:

Слайд 40

Техзадание. Раздел 7. Требования к составу и содержанию работ по подготовке

объекта автоматизации к вводу системы в действие:

Слайд 41

Техзадание. Раздел 8. Требования к документированию:

Слайд 42

Техзадание. Раздел 9. Источники разработки:

Слайд 43

ВАЖНО!!!
Разделы 1-9 «Могут» быть включены в Техническое задание, но не «Обязаны».
Техзадание

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

Слайд 44

Раздел 4 «Требования к системе»
Помним: требования должны быть понятными, конкретными и

тестируемыми!
Рекомендации из книги К.Вигерс «Разработка требований к программному обеспечению»
Не следует использовать слов, имеющих множество синонимов. Если это необходимо, то лучше дать четкое определение термину в разделе «Термины и определения» к Техническому заданию
Следует стараться не использовать длинных предложений
Если какое-то требование Вам кажется слишком общим, его необходимо детализировать до более мелких, но конкретных требований

Слайд 45

Рекомендации из книги К.Вигерс «Разработка требований к программному обеспечению» продолжение
Используйте больше

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

Слайд 46

Техническое задание. Виды работ при сборе требований к ИС и информации

для описания бизнес-процессов

Слайд 47

Техническое задание. Виды работ при сборе требований к ИС и информации

для описания бизнес-процессов

никто, кроме рабочей
группы Заказчика
не может принимать
участие в
приемке-сдаче работ

Слайд 48

Техническое задание. Виды работ при сборе требований к ИС и информации

для описания бизнес-процессов

Слайд 49

Подход к изучению требований к информационной системе с дальнейшим их отражением

в Техническом задании

Слайд 50

ВАЖНО!!!
Технического задания процесс трудоемкий, а значит и затратный.
Но если он

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

Слайд 51

Понятие «стандарт»
Стандарт - в широком смысле слова образец, эталон, модель, принимаемые

за исходную для сопоставления с ними других подобных объектов
Стандарт как нормативно-технический документ устанавливает комплекс норм, правил, требований к объекту стандартизации

Слайд 52

Стандарт ISO/IEC 12207 – процессы ЖЦ

Слайд 53

Основные определения
Жизненный цикл ИС – период времени, который начинается с момента

принятия решения о необходимости создания ИС и заканчивается в момент ее полного изъятия из эксплуатации

Слайд 54

Общая модель ЖЦ системы
концепция идеи системы
разработка
создание
утилизация
эксплуатация и сопровождение
разработка
разработка
разработка

Слайд 55

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

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

Слайд 56

Цель стандарта
Определить полную совокупность процессов, которые могут выполняться в ходе проекта

по созданию программной системы

Слайд 57

Адаптация
Поскольку проекты могут сильно различаться, например по масштабам, сложности, рискам и

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

Слайд 58

Группы процессов
Основные - это процессы, непосредственно относящиеся к жизненному циклу информационной

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

Слайд 59

Слайд 60

Модель жизненного цикла программного продукта

Слайд 61

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

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

Слайд 62

Состав модели ЖЦ ПО
стадии - часть процесса создания ПО, ограниченная определенными

временными рамками и заканчивающаяся выпуском конкретного продукта
результаты выполнения работ на каждой стадии
ключевые события - точки завершения работ и принятия решений

Слайд 63

Основные модели ЖЦ
Каскадная модель
V-образная модель
Модель прототипирования
Модель быстрой разработки приложений
Многопроходная модель
Спиральная

модель

Слайд 64

Каскадная модель
Прямолинейная и простая в использовании. Необходим постоянный жесткий контроль

за ходом работы. Разрабатываемое программное обеспечение недоступно для изменений

Слайд 65

V-образная модель
Простая в использовании. Особое значение придается тестированию и сравнению результатов

фаз тестирования и проектирования

Слайд 66

Модель прототипирования

Слайд 67

Модель быстрой разработки приложений
Проектные группы небольшие (3...7 человек) и составлены из

высококвалифицированных специалистов. Уменьшенное время цикла разработки (до 3 мес) и улучшенная производительность. Повторное использование кода и автоматизация процесса разработки

Слайд 68

Многопроходная модель
Быстро создается работающая система. Уменьшается возможность внесения изменений в процессе

разработки. Невозможен переход от текущей реализации к новой версии в течение построения текущей частичной реализации

Слайд 69

Спиральная модель

Слайд 70

Технологии и инструментальные средства моделирования бизнес-процессов
Структурный анализ – метод исследования системы,

которое начинается с общего обзора и затем детализируется, приобретая иерархическую структуру со все большим числом уровней.
Объектно-ориентированное моделирование - подразумевает описание статической структуры системы в терминах объектов и связей между ними, а поведение системы описывается в терминах обмена сообщениями между объектами. Каждый объект обладает своим собственным поведением, моделирующим поведение объекта реального мира.
Программные средства: IDEF Designer, ERwin\BPwin, Oracl Designer, BPM Workbench, Aris, Rational Rose, Ramus, StarUML

Слайд 71

Стандарты моделирования IDEF
Назначение семейства стандартов IDEF
Стандарты IDEF предназначены для разработки бизнес-моделей

и представляют собой набор спецификаций языка описания бизнес-процессов.
IDEF-методика создавалась в США в рамках программы компьютеризации промышленности ICAM – Integrated Computer Aided Manufacturing. Название стандарта расшифровывается как Icam DEFinition.

Слайд 72

Стандарты моделирования IDEF
К семейству IDEF относятся следующие стандарты:
IDEF0 – методология функционального

моделирования
IDEF1 – методология моделирования информационных потоков
IDEF1X – методология построения реляционных структур
IDEF2 – методология динамического моделирования развития систем
IDEF3 – методология документирования процессов в системе
IDEF4 – методология построения объектно-ориентированных систем
IDEF5 – методология онтологического описания сложных систем

Слайд 73

Стандарты моделирования IDEF
Стандарт IDEF0 – функциональный блок

Слайд 74

Стандарты моделирования IDEF
Стандарт IDEF0 – декомпозиция

Слайд 75

Декомпозиция функциональных диаграмм
Подфункция
функция
Подфункция 1
Подфункция 1
Подфункция 2
Подфункция 3
А0
А1
А2
А3
Контекстная диаграмма определяет все функции,

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

Каждая подфункция может содержать только те элементы, которые входят в исходную функцию.

IDEF0

Слайд 76

Стандарты моделирования IDEF.
Два типа диаграмм в стандарте IDEF3
Диаграммы описания последовательности

этапов процесса (Process Flow Description Diagrams, PFDD)

Рисунок 1. Пример PFDD диаграммы

Существуют два типа диаграмм в стандарте IDEF3, представляющие описание одного и того же сценария технологического процесса в разных ракурсах.
Диаграммы относящиеся к первому типу называются диаграммами Описания Последовательности Этапов Процесса (Process Flow Description Diagrams, PFDD).

Слайд 77

Стандарты моделирования IDEF.
Два типа диаграмм в стандарте IDEF3
Второй - диаграммами Состояния

Объекта в и его Трансформаций Процессе (Object State Transition Network, OSTN).

Рисунок 2. Пример OSTN диаграммы

Слайд 78

Динамические аспекты поведения системы
IDEF3

Слайд 79

Модель потоков данных – диаграммы DFD (Data Flow Diagram)‏

Слайд 80

Диаграммы ERD - «сущность-связь»
Описывают структуры данных, связанных с различными объектами

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

Автомашина
# Регистр. номер
* Год
* Марка
*Модель
*Цвет

Полис
# Идент. номер
* Дата
* Сумма

Один

Много

IDEF1X

Слайд 81

Диаграммы ERD - «сущность-связь»

Слайд 82

UML (Unified Modeling Language)
Унифицированный язык моделирования — язык графического описания для

объектного моделирования при разработке ПО
Язык широкого профиля, открытый стандарт графических обозначений для создания абстрактной модели системы
UML не язык программирования, но из UML-моделей возможна генерация кода
Основные авторы - Гради Буч, Джеймс Рамбо, Ивар Якобсон
Первая версия UML 1.0 - январь 1997 г.

Слайд 83

Виды диаграмм UML

Слайд 84

Диаграмма случаев использования (прецендентов) (use case diagram)
1 - варианты использования;
2 -

действующие лица;
7 – комментарии;
Основные типы отношений:
3 - ассоциация между действующим лицом и вариантом использования;
4 - обобщение между действующими лицами;
5 - обобщение между вариантами использования;
6 - зависимости (различных типов) между вариантами использования.

Слайд 85

Пример диаграммы случаев использования (прецендентов) (use case diagram)
Основной задачей диаграмм случаев использования (прецендентов)

является получение требований к системе от заказчика и пользователей

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

Слайд 86

Назначение диаграмм вариантов использования (use case diagram)
Определить общие границы функциональности проектируемой

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

Слайд 87

Примеры диаграммы классов в Rational Rose

Слайд 88

Диаграммы последовательностей (sequence diagrams)
На диаграммах последовательностей, так же как и на

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

Разработка технического задания

Содержание

ОпределенияАвтоматизированная система (АС) – система, состоящая из персонала и комплекса средств

Взаимодействие автоматизированных систем – обмен данными, командами и сигналами между функционирующими

Жизненный цикл автоматизированной системы – совокупность взаимосвязанных процессов создания и последовательного

Информационная система – система, которая организует хранение и манипулирование информацией о

Информационное обеспечение автоматизированной системы – совокупность форм документов, классификаторов, нормативной базы

Методическое обеспечение автома-тизированной системы – совокупность документов, описывающих технологию функционирования АС, методы выбора и

Приемочная документация на автома-тизированную систему – документация, фиксирующая сведения, подтверждающие готовность

Процесс создания автоматизированной системы – совокупность работ от формирования исходных требований

Совместимость автоматизированных систем – комплексное свойство двух или более АС, характеризуемое

Спецификация программы – форма-лизованное представление требований, предъявляемых к программе, которые должны

Технический проект автоматизированной системы – комплект проектных документов на АС, разрабатываемый

Техническое задание на авто-матизированную систему – документ, оформленный в установленном порядке

Эксплуатационная документация на автоматизированную систему – часть рабочей документации на АС,

Основные стандарты, методологии и своды знаний, где упоминается ТЗ или SRS

Как инструмент коммуникации в связке общения заказчик-исполнитель, техническое задание позволяет: 1.

Когда нет продуманного и четкого технического задания

Вопрос: Как разработать техническое задание?Коммерческая организация решила внедрить у себя автоматизированную

Вопрос: Как разработать техническое задание?IT-компания занимается услугами по разработке и/или внедрению

Что такое техническое задание?ГОСТ: «ТЗ на АС является основным документом, определяющим

Что такое техническое задание?«Техническое задание – это исходный документ на проектирование технического

ГОСТ 2.114-95 Единая система конструкторской документации. Технические условияГОСТ 19.201-78 Единая система

Основное назначение Технического задания — сформулировать требования к разрабатываемому объекту, т.е.

Виды требований могут быть различными – это зависит от целей проектаСвойства

ВАЖНО!!!На каком языке (в смысле сложности понимания) должно быть написано техническое

Техническое задание – это документ, в основе которого лежат требования, сформулированные на

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

ЗАДАЧА:Сделать качественное Техническое задание, понятное Заказчику, а Технический проект использовать как

Структура технического задания по ГОСТ:общие сведения;назначение и цели создания (развития) системы;характеристика

Техзадание. Раздел 1. Общие сведения: начало

Техзадание. Раздел 1. Общие сведения: продолжение

Техзадание. Раздел 2. Назначение и цели создания (развития) системы: начало

Техзадание. Раздел 2. Назначение и цели создания (развития) системы: продолжение

Техзадание. Раздел 3. Характеристика объектов автоматизации :

Техзадание. Раздел 4. Требования к системе :ГОСТ расшифровывает перечень таких требований:требования

Техзадание. Раздел 4. Требования к системе :ВАЖНО:Требования к квалификации. Если квалификация

Техзадание. Раздел 4. Требования к системе :ВАЖНО:Требования к структуре и функционированию

Техзадание. Раздел 5. Состав и содержание работ по созданию системы :

Техзадание. Раздел 6. Порядок контроля и приемки системы:

Техзадание. Раздел 7. Требования к составу и содержанию работ по подготовке

Техзадание. Раздел 8. Требования к документированию:

Техзадание. Раздел 9. Источники разработки:

ВАЖНО!!!Разделы 1-9 «Могут» быть включены в Техническое задание, но не «Обязаны».Техзадание

Раздел 4 «Требования к системе»Помним: требования должны быть понятными, конкретными и

Рекомендации из книги К.Вигерс «Разработка требований к программному обеспечению» продолжениеИспользуйте больше

Техническое задание. Виды работ при сборе требований к ИС и информации

Техническое задание. Виды работ при сборе требований к ИС и информации

Техническое задание. Виды работ при сборе требований к ИС и информации

Подход к изучению требований к информационной системе с дальнейшим их отражением

ВАЖНО!!!Технического задания процесс трудоемкий, а значит и затратный. Но если он

Понятие «стандарт»Стандарт - в широком смысле слова образец, эталон, модель, принимаемые

Стандарт ISO/IEC 12207 – процессы ЖЦ

Основные определенияЖизненный цикл ИС – период времени, который начинается с момента

Общая модель ЖЦ системыконцепция идеи системыразработкасозданиеутилизацияэксплуатация и сопровождениеразработкаразработкаразработка

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

Цель стандарта Определить полную совокупность процессов, которые могут выполняться в ходе проекта

АдаптацияПоскольку проекты могут сильно различаться, например по масштабам, сложности, рискам и

Группы процессовОсновные - это процессы, непосредственно относящиеся к жизненному циклу информационной

Модель жизненного цикла программного продукта

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

Состав модели ЖЦ ПОстадии - часть процесса создания ПО, ограниченная определенными

Основные модели ЖЦКаскадная модельV-образная модельМодель прототипированияМодель быстрой разработки приложенийМногопроходная модель Спиральная

Каскадная модель Прямолинейная и простая в использовании. Необходим постоянный жесткий контроль

V-образная модельПростая в использовании. Особое значение придается тестированию и сравнению результатов

Модель прототипирования

Модель быстрой разработки приложенийПроектные группы небольшие (3...7 человек) и составлены из

Многопроходная модельБыстро создается работающая система. Уменьшается возможность внесения изменений в процессе

Спиральная модель

Технологии и инструментальные средства моделирования бизнес-процессовСтруктурный анализ – метод исследования системы,

Стандарты моделирования IDEFНазначение семейства стандартов IDEFСтандарты IDEF предназначены для разработки бизнес-моделей

Стандарты моделирования IDEFК семейству IDEF относятся следующие стандарты:IDEF0 – методология функционального

Стандарты моделирования IDEFСтандарт IDEF0 – функциональный блок

Стандарты моделирования IDEFСтандарт IDEF0 – декомпозиция

Декомпозиция функциональных диаграммПодфункцияфункцияПодфункция 1Подфункция 1Подфункция 2Подфункция 3А0А1А2А3Контекстная диаграмма определяет все функции,

Определения
Автоматизированная система (АС) – система, состоящая из персонала и комплекса средств

Как инструмент коммуникации в связке общения заказчик-исполнитель, техническое задание позволяет:
1.

Вопрос: Как разработать техническое задание?
Коммерческая организация решила внедрить у себя автоматизированную

Вопрос: Как разработать техническое задание?
IT-компания занимается услугами по разработке и/или внедрению

Что такое техническое задание?
ГОСТ: «ТЗ на АС является основным документом, определяющим

Что такое техническое задание?
«Техническое задание – это исходный документ на проектирование технического

ГОСТ 2.114-95 Единая система конструкторской документации. Технические условия
ГОСТ 19.201-78 Единая система

Виды требований могут быть различными – это зависит от целей проекта
Свойства

ВАЖНО!!!
На каком языке (в смысле сложности понимания) должно быть написано техническое

ЗАДАЧА:
Сделать качественное Техническое задание, понятное Заказчику, а Технический проект использовать как

Структура технического задания по ГОСТ:
общие сведения;
назначение и цели создания (развития) системы;
характеристика

Техзадание. Раздел 4. Требования к системе :
ГОСТ расшифровывает перечень таких требований:
требования

Техзадание. Раздел 4. Требования к системе :
ВАЖНО:
Требования к квалификации. Если квалификация

Техзадание. Раздел 4. Требования к системе :
ВАЖНО:
Требования к структуре и функционированию

ВАЖНО!!!
Разделы 1-9 «Могут» быть включены в Техническое задание, но не «Обязаны».
Техзадание

Раздел 4 «Требования к системе»
Помним: требования должны быть понятными, конкретными и

Рекомендации из книги К.Вигерс «Разработка требований к программному обеспечению» продолжение
Используйте больше

ВАЖНО!!!
Технического задания процесс трудоемкий, а значит и затратный.
Но если он

Понятие «стандарт»
Стандарт - в широком смысле слова образец, эталон, модель, принимаемые

Основные определения
Жизненный цикл ИС – период времени, который начинается с момента

Общая модель ЖЦ системы
концепция идеи системы
разработка
создание
утилизация
эксплуатация и сопровождение
разработка
разработка
разработка

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

Цель стандарта
Определить полную совокупность процессов, которые могут выполняться в ходе проекта

Адаптация
Поскольку проекты могут сильно различаться, например по масштабам, сложности, рискам и

Группы процессов
Основные - это процессы, непосредственно относящиеся к жизненному циклу информационной

Состав модели ЖЦ ПО
стадии - часть процесса создания ПО, ограниченная определенными

Основные модели ЖЦ
Каскадная модель
V-образная модель
Модель прототипирования
Модель быстрой разработки приложений
Многопроходная модель
Спиральная

Каскадная модель
Прямолинейная и простая в использовании. Необходим постоянный жесткий контроль

V-образная модель
Простая в использовании. Особое значение придается тестированию и сравнению результатов

Модель быстрой разработки приложений
Проектные группы небольшие (3...7 человек) и составлены из

Многопроходная модель
Быстро создается работающая система. Уменьшается возможность внесения изменений в процессе

Технологии и инструментальные средства моделирования бизнес-процессов
Структурный анализ – метод исследования системы,

Стандарты моделирования IDEF
Назначение семейства стандартов IDEF
Стандарты IDEF предназначены для разработки бизнес-моделей

Стандарты моделирования IDEF
К семейству IDEF относятся следующие стандарты:
IDEF0 – методология функционального

Стандарты моделирования IDEF
Стандарт IDEF0 – функциональный блок

Стандарты моделирования IDEF
Стандарт IDEF0 – декомпозиция