Системный анализ в процессе разработки ПО

Системный анализ в процессе разработки ПО

Максим Галимов

директор по перспективным исследованиям,

DIRECTUM

Процесс

1. В идеальном мире любая мысль материализуется точно и без лишних сложностей.

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

воплощение

2. Если переложить это на разработку программного решения, то получается та же картинка в новых терминах.

ИдеяПрограммное

решение

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

Продукт

Программное решение


Идея

Идея

Идея

Идея

Идея

Идея

Идея Программное решение

4. Для простоты мы пока будем говорить о сферической идее в вакууме и о сферическом программном решении в составе продукта.


решение

5. Мы не Гарри Поттеры, и для того, чтобы идея воплотилась, нужно поработать.


решение Процесс разработки

6. Процесс разработки – это последовательная детализация идеи и перевод ее в программный код. (Обратите внимание, английское слово development означает и разработку, и развитие – в нашем случае, развитие идеи). Степень проработанности идеи растет и достигает своего апогея к моменту реализации. Иногда идеи воплощаются не полностью, иногда не так, как изначально задумывалось, но это, в конечном счете, не так важно.


решение Процесс разработки

7. Перевод идеи в программный код – это не единственный перевод в процессе разработки. Очень часто нужно переводить с «птичьего языка» заказчика на человеческий, затем на язык проектировщика, разработчика, пользователя и т.д. Усилия на уточнение того, чего хочет автор идеи, в начале очень высокие, затем снижаются. (Между прочим, это очень хорошо согласуется с процессами разработки, описанными в RUP и MSF.)


решение

Э-э-э... Э + <Э> + <э> Э: а! <Э>: А! <э>: а! а++ А++ а++Э, Ээ, ЭЭЭ, эээ, Ээ, ...

8. С точки зрения аналитика процесс разработки содержит фазы анализа, моделирования, проектирования и разработки. Тестирование, документирование и другие последующие этапы разработки входят в фазу «Разработка».


решение

Моделирование Проектирование РазработкаАнализ

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


решение


Аналитик Проектировщик РазработчикАналитикЗаказчик

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


решение

Общая цель / бизнес-задачаОграничения и предположения

Сроки и ресурсы

Аналитик Проектировщик РазработчикЗаказчик

(Аналитик)

Заказчик

Исходные ситуации и шаблоны ситуацийАнализ конкурентов и ориентиров

МодельТребования

АрхитектураСтруктура БД

Технические решения

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


решение

Концепция исследования

Аналитик Проектировщик РазработчикЗаказчик

(Аналитик)

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

Технический проект

Заказчик

Системный анализ

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


решение

Выяснение ситуаций,

ознакомление с их списком и шаблонами

Представление модели,

проверка на соответствие

ситуациям

Проверка технических решений на

соответствие модели и

контрольным ситуациям

Оценка прототипов и проверка на соответствие техпроекту, модели и

контрольным ситуациям


Тестирование и оценка на

соответствие техпроекту, детальным проектам,

контрольным ситуациям и

модели

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

Идея



14. Взаимопонимание между участниками процесса очень важно. Иногда, если позволяет сложность задачи, этапы могут совмещаться. Признаки, когда это можно сделать: этапы во времени находятся близко друг к другу, объем задачи небольшой, очень сильные начальные ограничения, допущения уже выглядят как модель и т.д. Совмещаются в одном лице и роли. Упрощается документооборот процесса. Например, при прикладной разработке проектировщик экономит на моделировании и на проектировании архитектуры (очень сильные ограничения: число объектов, которыми можно манипулировать, невелико), иногда в ущерб гибкости, конечно. Agile-технологии также призывают сокращать дистанцию от заказчика до разработчика и анализировать, моделировать и проектировать «на лету». Но Ситуации, Модель и требования, Технический проект так или иначе имеются (в документальном виде или в головах).


решение

Проектирование Разработка

Проектировщик Разработчик

Ситуации, Модели и Требования

15. Самое время определиться с тем, что же такое «Ситуации», «Модель» и «Требования». Выше мы говорили, что каждый этап в процессе помогает сделать перевод с одного языка на другой. Ситуации, модель и требования – это промежуточный перевод задачи между заказчиком и проектировщиком. Модель формирует единую систему понятий предметной области, выделяет основные субъекты и объекты (кто управляет, кем управляют), описывает отношения между этими понятиями (кто и что в какие связи с кем и чем может вступать), описывает поведение и разные характеристики этих субъектов и объектов, – и все это в контексте какой-то среды, «места действия».

Понятия Отношения Поведение Среда

Объекты Субъекты

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

Ситуация

Ситуация

Ситуация

Ситуация

Ситуация

Ситуация

Ситуация Модель

Шаблон (группа)

ситуаций

Шаблон (группа)

ситуацийШаблон (группа)

ситуаций

17. Небольшой «лайфхак»: обязательно нужно обсуждать процессы и ситуации и обязательно нужно дать время им уложиться в голове (отложить работу, подождать). Тогда мозг сам упорядочит входную информацию, отбросит лишнее и позволит быстрее построить модель. Зафиксировать же модель можно разными способами (схемы и/или словесные описания).

18. Кроме ситуаций еще очень важно проанализировать аналогичные продукты (ориентиры), в том числе конкурирующие продукты – там уже заложена какая-то модель, а значит, можно сэкономить время на моделировании, предварительно, конечно, проверив на соответствие нашим ситуациям.

Модель

Модель

Модель Модель

19. Проверка на соответствие ситуациям – очень важная составляющая моделирования. Итерации в процессе моделирования дают возможность уточнять, видоизменять модель. Другая сторона – проверка на техническую реализуемость. Очень часто в результате этих проверок модель значительно упрощается, правда, часто за счет усложнения работы пользователя или невозможности закрыть все его потребности. Сравните, например, концепты автомобилей и серийные модели. В конечном итоге очень полезно бывает выделить небольшое количество контрольных ситуаций, которые будут переданы проектировщикам и разработчикам и на которых проверяется вся полнота решения задачи (они обеспечивают полное покрытие задачи).

МодельАрхитектура и технические

решенияСитуация

Ситуация

Ситуация

Ситуация

Ситуация

Ситуация

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

Понятие

Отношение

Требования





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

Модель

Модель

Модель

Модель

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

?

?

?

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

Понятие

Отношение






Системный анализ в процессе разработки ПО

Documents