Содержание других частей.
- Анонс и введение
- 1 этап (требования)
- 2 этап (требования)
- 3 этап (требования)
- 4 этап (пред. проект)
- 5 этап (пред. проект)
- 6 этап (ок. проект)
- 7 этап (ок. проект)
Анонсирую цикл статей про этапы разработки программного обеспечения, в особенности про его проектирование. Не буду особо останавливаться на важных стандатрах, например таких, как их комплекс ГОСТ 34 серии и прочих. Знание стандартов либо уже осознанно специалистом, либо ещё предстоит. Целью данной статьи является краткое описание RUP/ICONIX, активно применяемое у нас.
RUP/ICONIX используется как методология проектирования для небольших и средних проектов, сложность которых косвенно оценивается до 1 млн. строк кода и меньше. Для более сложных проектов рекомендуется RUP без упрощений. Модели строятся в Sparx EA, что позволяет генерировать документы, связанные с изменениями в проекте, выполнять обратный инжиниринг и многое из того, что упрощает работу по приведению документации, моделей и кода в соответствие друг другу. Читатель без труда выберет для себя удобный CASE-инструмент, кроме Sparx EA, т.к. описываемое здесь выполнимо и с другими инструментами.
Повествование в целом согласуется с методичкой «Применение объектного моделирования с использованием UML и анализ прецедентов на примере разработки книжного Internet-магазина» Кендалла Скотта и Дуга Розенберга. Хотя обстоятельное освоение UML как такового рекомендуется начать с «UML 2.0. Объектно-ориентированное моделирование и разработка» Джеймса Рамбо и М. Блаха.
В цикле статей в основном затрагивается структура работ для таких ролей, как бизнес аналитик, системный аналитик и системный архитектор. И если в полноценном RUP легче провести грань между этими ролями как по отдельным работам, так и по артефактам, производимыми ими, то в ICONIX, как в упрощённом RUP, роли бизнес аналитика и системного аналитика смешиваются, а часть артефактов общая с системным архитектором.
Также обращу внимание, что в анонсируемом цикле статей в явном виде используется объектно-ориентированное проектирование. Т.е. упор делается на формировании объектов, их классов, и сообщения между ними, а не фукнций, как последовательности действий, переводящих систему из одного состояния в другое. Одно с другим связано, хотя подход с фукнциями мыслится уже как давно архаичный из 70-ых годов.
Статьи будут полезными как для начинающих аналитиков, так и для тех, кто хочет укрепиться во владении своей профессией. Конечно же статьи также полезны и ИТ-архитекторам разных уровней. Любителям масала-диаграмм и проектирования на коленке в особенности рекомендуется прочесть анонсируемый материал, как возможность освоить профессию, пройдя от стадии отрицания до стадии принятия методологии и связанного с ней инструментария. Многим аналитикам на рынке труда, чья роль сводится сейчас к передаче слов заказчика с оформлением в Word и прикладыванием пары Visio-картинок на UML также очень рекомендуется к прочтению, т.к. у них появляется шанс всё-таки начать осваивать свою профессию.