Системный анализ в процессе разработки ПО
-
Upload
maxim-galimov -
Category
Documents
-
view
647 -
download
5
Transcript of Системный анализ в процессе разработки ПО
![Page 1: Системный анализ в процессе разработки ПО](https://reader034.fdocuments.net/reader034/viewer/2022050817/557fd57ed8b42aab088b50d0/html5/thumbnails/1.jpg)
Системный анализ в процессе разработки ПО
Максим Галимов
директор по перспективным исследованиям,
DIRECTUM
![Page 2: Системный анализ в процессе разработки ПО](https://reader034.fdocuments.net/reader034/viewer/2022050817/557fd57ed8b42aab088b50d0/html5/thumbnails/2.jpg)
Процесс
1. В идеальном мире любая мысль материализуется точно и без лишних сложностей.
ИдеяМатериальное
воплощение
2. Если переложить это на разработку программного решения, то получается та же картинка в новых терминах.
ИдеяПрограммное
решение
![Page 3: Системный анализ в процессе разработки ПО](https://reader034.fdocuments.net/reader034/viewer/2022050817/557fd57ed8b42aab088b50d0/html5/thumbnails/3.jpg)
3. С точки зрения сложности состава продукта, это выглядит несколько сложнее. Идей много, некоторые из них образуют программные решения, входящие в состав продукта. Идеи возникают очень разным образом и все они разной стадии «сырости», разного размера, разной близости к программному решению. Идеи приходят от пользователей, от заказчика, от разработчиков, от конкурентов, от безумных аналитиков; они фильтруются и некоторые из них воплощаются.
Продукт
Программное решение
Программное решение
Идея
Идея
Идея
Идея
Идея
Идея
Идея Программное решение
![Page 4: Системный анализ в процессе разработки ПО](https://reader034.fdocuments.net/reader034/viewer/2022050817/557fd57ed8b42aab088b50d0/html5/thumbnails/4.jpg)
4. Для простоты мы пока будем говорить о сферической идее в вакууме и о сферическом программном решении в составе продукта.
ИдеяПрограммное
решение
5. Мы не Гарри Поттеры, и для того, чтобы идея воплотилась, нужно поработать.
ИдеяПрограммное
решение Процесс разработки
![Page 5: Системный анализ в процессе разработки ПО](https://reader034.fdocuments.net/reader034/viewer/2022050817/557fd57ed8b42aab088b50d0/html5/thumbnails/5.jpg)
6. Процесс разработки – это последовательная детализация идеи и перевод ее в программный код. (Обратите внимание, английское слово development означает и разработку, и развитие – в нашем случае, развитие идеи). Степень проработанности идеи растет и достигает своего апогея к моменту реализации. Иногда идеи воплощаются не полностью, иногда не так, как изначально задумывалось, но это, в конечном счете, не так важно.
ИдеяПрограммное
решение Процесс разработки
![Page 6: Системный анализ в процессе разработки ПО](https://reader034.fdocuments.net/reader034/viewer/2022050817/557fd57ed8b42aab088b50d0/html5/thumbnails/6.jpg)
7. Перевод идеи в программный код – это не единственный перевод в процессе разработки. Очень часто нужно переводить с «птичьего языка» заказчика на человеческий, затем на язык проектировщика, разработчика, пользователя и т.д. Усилия на уточнение того, чего хочет автор идеи, в начале очень высокие, затем снижаются. (Между прочим, это очень хорошо согласуется с процессами разработки, описанными в RUP и MSF.)
ИдеяПрограммное
решение
Э-э-э... Э + <Э> + <э> Э: а! <Э>: А! <э>: а! а++ А++ а++Э, Ээ, ЭЭЭ, эээ, Ээ, ...
![Page 7: Системный анализ в процессе разработки ПО](https://reader034.fdocuments.net/reader034/viewer/2022050817/557fd57ed8b42aab088b50d0/html5/thumbnails/7.jpg)
8. С точки зрения аналитика процесс разработки содержит фазы анализа, моделирования, проектирования и разработки. Тестирование, документирование и другие последующие этапы разработки входят в фазу «Разработка».
ИдеяПрограммное
решение
Моделирование Проектирование РазработкаАнализ
![Page 8: Системный анализ в процессе разработки ПО](https://reader034.fdocuments.net/reader034/viewer/2022050817/557fd57ed8b42aab088b50d0/html5/thumbnails/8.jpg)
9. Главные действующие лица – заказчик, аналитик, проектировщик и разработчик. Остальные лица есть, но они не действующие или не главные (пользователь, тестировщик и проч.). Понятно, что процесс выглядит несколько однобоко (например, однозначно роль тестировщика очень важна для заказчика), но это взгляд со стороны аналитика, а поэтому первые этапы интереснее, чем последующие. Заказчик – хочет, аналитик – понимает, проектировщик – придумывает, разработчик – реализует.
ИдеяПрограммное
решение
Моделирование Проектирование РазработкаАнализ
Аналитик Проектировщик РазработчикАналитикЗаказчик
![Page 9: Системный анализ в процессе разработки ПО](https://reader034.fdocuments.net/reader034/viewer/2022050817/557fd57ed8b42aab088b50d0/html5/thumbnails/9.jpg)
10. Между этапами для сложных продуктов существуют явные границы. На каждой границе нужно передать информацию от одного участника процесса другому, важно обеспечить единое информационное пространство (пространство понятий, требований, области применения продукта и т.д.). Важно не упустить детали и сформировать полный пакет информации. Аналитик является в данном случае важным звеном, но не является ответственным за передачу от заказчика проектировщику и разработчику (хотя его можно назначить представителем заказчика).
ИдеяПрограммное
решение
Общая цель / бизнес-задачаОграничения и предположения
Сроки и ресурсы
Аналитик Проектировщик РазработчикЗаказчик
(Аналитик)
Заказчик
Исходные ситуации и шаблоны ситуацийАнализ конкурентов и ориентиров
МодельТребования
АрхитектураСтруктура БД
Технические решения
![Page 10: Системный анализ в процессе разработки ПО](https://reader034.fdocuments.net/reader034/viewer/2022050817/557fd57ed8b42aab088b50d0/html5/thumbnails/10.jpg)
11. Возникает проблема: как правильно передать информацию и обеспечить ее полное восприятие, как проконтролировать исполнение. Возникает понятие «контракта» между сторонами на каждой границе. Каждый «контракт» – это в конечном итоге документ, с которым согласны (с известными допущениями) обе стороны. В том числе по контракту инициатор будет контролировать работу, сделанную исполнителем.
ИдеяПрограммное
решение
Концепция исследования
Аналитик Проектировщик РазработчикЗаказчик
(Аналитик)
Модель и требования
Технический проект
Заказчик
Системный анализ
![Page 11: Системный анализ в процессе разработки ПО](https://reader034.fdocuments.net/reader034/viewer/2022050817/557fd57ed8b42aab088b50d0/html5/thumbnails/11.jpg)
12. Исполнитель в процессе своей части работы может увидеть «пробелы» в контракте, противоречия или нереализуемые вещи. Очень важно обеспечивать постоянную обратную связь не только для устранения ошибок в «контракте», но и для оценки уже реализованных вещей. Приемщиком на первых этапах является Заказчик, но при приближении к программному решению его роль уменьшается, также появляется возможность назначать представителя заказчика («заказчик функционального блока», например). Цена ошибки, сделанной на первых этапах, очень высока в конечном продукте, поэтому очень важно проверять работу на ошибки и исправлять их как можно раньше.
ИдеяПрограммное
решение
Выяснение ситуаций,
ознакомление с их списком и шаблонами
Представление модели,
проверка на соответствие
ситуациям
Проверка технических решений на
соответствие модели и
контрольным ситуациям
Оценка прототипов и проверка на соответствие техпроекту, модели и
контрольным ситуациям
Моделирование Проектирование РазработкаАнализ
Тестирование и оценка на
соответствие техпроекту, детальным проектам,
контрольным ситуациям и
модели
![Page 12: Системный анализ в процессе разработки ПО](https://reader034.fdocuments.net/reader034/viewer/2022050817/557fd57ed8b42aab088b50d0/html5/thumbnails/12.jpg)
13. Прямая и обратная связь – это, конечно, упрощенная формулировка процесса. Анализ и моделирование, а также моделирование и проектирование – это интерактивные, итерационные процессы, где очень часто возникают проблемы «на стыке» (можно ли реализовать придуманную модель, можно ли закрыть все противоречивые ситуации одним решением и т.д.). В частности, модель постоянно уточняется на основе новых вопросов и деталей.
Идея
Моделирование Проектирование РазработкаАнализ
Программное решение
![Page 13: Системный анализ в процессе разработки ПО](https://reader034.fdocuments.net/reader034/viewer/2022050817/557fd57ed8b42aab088b50d0/html5/thumbnails/13.jpg)
14. Взаимопонимание между участниками процесса очень важно. Иногда, если позволяет сложность задачи, этапы могут совмещаться. Признаки, когда это можно сделать: этапы во времени находятся близко друг к другу, объем задачи небольшой, очень сильные начальные ограничения, допущения уже выглядят как модель и т.д. Совмещаются в одном лице и роли. Упрощается документооборот процесса. Например, при прикладной разработке проектировщик экономит на моделировании и на проектировании архитектуры (очень сильные ограничения: число объектов, которыми можно манипулировать, невелико), иногда в ущерб гибкости, конечно. Agile-технологии также призывают сокращать дистанцию от заказчика до разработчика и анализировать, моделировать и проектировать «на лету». Но Ситуации, Модель и требования, Технический проект так или иначе имеются (в документальном виде или в головах).
ИдеяПрограммное
решение
Проектирование Разработка
Проектировщик Разработчик
![Page 14: Системный анализ в процессе разработки ПО](https://reader034.fdocuments.net/reader034/viewer/2022050817/557fd57ed8b42aab088b50d0/html5/thumbnails/14.jpg)
Ситуации, Модели и Требования
15. Самое время определиться с тем, что же такое «Ситуации», «Модель» и «Требования». Выше мы говорили, что каждый этап в процессе помогает сделать перевод с одного языка на другой. Ситуации, модель и требования – это промежуточный перевод задачи между заказчиком и проектировщиком. Модель формирует единую систему понятий предметной области, выделяет основные субъекты и объекты (кто управляет, кем управляют), описывает отношения между этими понятиями (кто и что в какие связи с кем и чем может вступать), описывает поведение и разные характеристики этих субъектов и объектов, – и все это в контексте какой-то среды, «места действия».
Понятия Отношения Поведение Среда
Объекты Субъекты
![Page 15: Системный анализ в процессе разработки ПО](https://reader034.fdocuments.net/reader034/viewer/2022050817/557fd57ed8b42aab088b50d0/html5/thumbnails/15.jpg)
16. Чтобы построить модель, нужны исходные ситуации. Они извлекаются из заказчика, пользователей, и фиксируются в совершенно разнообразных формах. Это может быть словесное описание, схемы процессов в разных нотациях и т.д. Ситуации – это описание реальных событий в мире (у заказчика реального или обобщенного). При переходе от ситуации к модели выделяют некоторые шаблоны ситуаций, обобщения. А иногда сразу мыслят ими.
Ситуация
Ситуация
Ситуация
Ситуация
Ситуация
Ситуация
Ситуация Модель
Шаблон (группа)
ситуаций
Шаблон (группа)
ситуацийШаблон (группа)
ситуаций
![Page 16: Системный анализ в процессе разработки ПО](https://reader034.fdocuments.net/reader034/viewer/2022050817/557fd57ed8b42aab088b50d0/html5/thumbnails/16.jpg)
17. Небольшой «лайфхак»: обязательно нужно обсуждать процессы и ситуации и обязательно нужно дать время им уложиться в голове (отложить работу, подождать). Тогда мозг сам упорядочит входную информацию, отбросит лишнее и позволит быстрее построить модель. Зафиксировать же модель можно разными способами (схемы и/или словесные описания).
![Page 17: Системный анализ в процессе разработки ПО](https://reader034.fdocuments.net/reader034/viewer/2022050817/557fd57ed8b42aab088b50d0/html5/thumbnails/17.jpg)
18. Кроме ситуаций еще очень важно проанализировать аналогичные продукты (ориентиры), в том числе конкурирующие продукты – там уже заложена какая-то модель, а значит, можно сэкономить время на моделировании, предварительно, конечно, проверив на соответствие нашим ситуациям.
Модель
Модель
Модель Модель
![Page 18: Системный анализ в процессе разработки ПО](https://reader034.fdocuments.net/reader034/viewer/2022050817/557fd57ed8b42aab088b50d0/html5/thumbnails/18.jpg)
19. Проверка на соответствие ситуациям – очень важная составляющая моделирования. Итерации в процессе моделирования дают возможность уточнять, видоизменять модель. Другая сторона – проверка на техническую реализуемость. Очень часто в результате этих проверок модель значительно упрощается, правда, часто за счет усложнения работы пользователя или невозможности закрыть все его потребности. Сравните, например, концепты автомобилей и серийные модели. В конечном итоге очень полезно бывает выделить небольшое количество контрольных ситуаций, которые будут переданы проектировщикам и разработчикам и на которых проверяется вся полнота решения задачи (они обеспечивают полное покрытие задачи).
МодельАрхитектура и технические
решенияСитуация
Ситуация
Ситуация
Ситуация
Ситуация
Ситуация
![Page 19: Системный анализ в процессе разработки ПО](https://reader034.fdocuments.net/reader034/viewer/2022050817/557fd57ed8b42aab088b50d0/html5/thumbnails/19.jpg)
20. Требования (функциональные и нефункциональные) возникают как результат моделирования. Требования формируются в привязке к модели, «скелету» понятий и отношений. Выделить требования «вообще» нельзя, можно выделить требования к чему-то. В процессе выделения ситуаций иногда можно сразу выделить базовые требования (исходные потребности пользователей или заказчика), тогда же возникают и базовые элементы модели. Иногда в простых случаях описания ситуаций уже достаточно для проектирования и разработки, модель формируется в голове сразу. В процессе выделения требования возникает необходимость выделять дополнительные ситуации, уточняющие модель и требования. Тут очень важно остановиться, т.к. можно уйти слишком глубоко и это окажется непродуктивным (особенно, если процесс разработки отложен во времени).
Понятие
Отношение
Требования
Требования
Требования
Требования
Требования
![Page 20: Системный анализ в процессе разработки ПО](https://reader034.fdocuments.net/reader034/viewer/2022050817/557fd57ed8b42aab088b50d0/html5/thumbnails/20.jpg)
21. Требования – это характеристики и поведение объектов и субъектов модели. Что от них ждет пользователь и заказчик. Моделей может быть много – базовая модель данных, модель архитектуры, модель безопасности, модель интерфейса, модель жизненного цикла понятий и т.д. Все они дополняют друг друга, но обычно достаточно одной-трех, остальное же описывается в виде текстовых требований. Иногда из моделей удобно выделять какие-то подмножества, представлять их в другой форме (сокращенной, видоизмененной). Например, выделять глоссарий, который упростит и упорядочит коммуникации между разными участниками процесса разработки.
Модель
Модель
Модель
Модель
![Page 21: Системный анализ в процессе разработки ПО](https://reader034.fdocuments.net/reader034/viewer/2022050817/557fd57ed8b42aab088b50d0/html5/thumbnails/21.jpg)
22. Не устану повторять, что интеграционная функция модели – главная; ее задача – дать разным участникам процесса разработки общие слова, общий язык для общения. Вторая не менее важная функция модели, которая является жизненно важной на крупных проектах – это описать предметную область максимально широко до начала процесса разработки. Глубина модели менее важна, чем ширина. Углублять и уточнять модель можно впоследствии на разных стадиях реализации.
?
?
?
![Page 22: Системный анализ в процессе разработки ПО](https://reader034.fdocuments.net/reader034/viewer/2022050817/557fd57ed8b42aab088b50d0/html5/thumbnails/22.jpg)
23. Сформированные требования в привязке к моделям передаются проектировщику и разработчикам. Перед этим очень важно расставить приоритеты, обозначив, что важнее для заказчика и пользователя, а также сделать ссылки на ситуации и/ли группы ситуаций – для последующего контроля и для помощи разработчикам и проектировщикам, т.к. понимать, откуда растут ноги у того или иного требования и понятия, им очень важно. Важно для построения собственных микромоделей и уточнения входящих моделей, т.к. аналитик и заказчик передают подчас довольно обобщенную модель, когда считают, что дальше уже проще разработать и посмотреть на результат.
Понятие
Отношение
Требования
Требования
Требования
Требования
Требования