Стратегия

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

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

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

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

Может оказаться, что проект продолжать не имеет смысла, например из-за того, что те или иные требования не могут быть удовлетворены по каким-то объективным причинам.

Если принимается решение о продолжении проекта, то для проведения следующего этапа анализа уже имеются представление об объеме проекта и смета затрат.

Следует отметить, что и на этапе выбора стратегии, и на этапе анализа, и при проектировании независимо от метода, применяемого при разработке проекта, всегда следует классифицировать планируемые функции системы по степени важности. Один из возможных форматов представления такой классификации - MoSCoW - предложен в Clegg, Dai and Richard Barker, Case Method Fast-track A RAD Approach, Adison-Wesley, 1994. Эта аббревиатура расшифровывается так Must have - необходимые функции Should have - желательные функции Could have - возможные функции Won t have - отсутствующие функции.

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

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

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

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

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

К достаточным результатам следует отнести диаграммы потоков данных и диаграммы жизненных циклов сущностей. Довольно часто ошибки анализа возникают при попытке показать жизненный цикл сущности на диаграмме ER. Ниже мы рассмотрим три наиболее часто применяемые методологии структурного анализа диаграммы сущность-связь Entity-Relationship Diagrams, ERD , которые служат для формализации информации о сущностях и их отношениях диаграммы потоков данных Data Flow Diagrams, DFD , которые служат для формализации представления функций системы диаграммы переходов состояний State Transition Diagrams, STD , которые отражают поведение системы, зависящее от времени диаграммы жизненных циклов сущностей относятся именно к этому классу диаграмм.

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

ER-диаграмма содержит информацию о сущностях системы и способах их взаимодействия, включает идентификацию объектов, важных для предметной области сущностей, свойств этих объектов атрибутов и их отношений с другими объектами связей. Во многих случаях информационная модель очень сложна и содержит множество объектов. Рис. 4.2. Пример ER-диаграммы Сущность изображается в виде прямоугольника, вверху которого располагается имя сущности например, TITLES . В прямоугольнике могут быть перечислены атрибуты сущности атрибуты ER-диаграмм, набранные полужирным шрифтом 1, являются ключевыми так Title Identity - ключевой атрибут сущности TITLES, остальные атрибуты ключевыми не являются. Отношение изображается линией между двумя сущностями.

Рис. 4.3. Элемент ER-диаграммы Одиночная линия справа рис. 4.3 означает один, птичья лапка слева - многие, а отношение читается вдоль линии, например один ко многим. Вертикальная черта означает обязательно, кружок - не обязательно, например, для каждого издания в TITLE обязательно должен быть указан издатель в PUBLISHERS, а один издатель в PUBLISHERS может выпускать несколько наименований изданий в TITLES. Следует отметить, что связи всегда комментируются надпись на линии, изображающей связь. Приведем также пример рис. 4.4 изображения рефлексивного отношения сотрудник, где один сотрудник может руководить несколькими подчиненными и так далее вниз по иерархии должностей.

Рис. 4.4. ER-диаграмма рефлексивного отношения Следует обратить внимание на то, что такое отношение всегда является необязательным, в противном случае это будет бесконечная иерархия.

Атрибуты сущностей могут быть ключевыми - они выделяются полужирным шрифтом обязательными - перед ними ставится знак, то есть их значение всегда известно, необязательными optional - перед ними ставится О, то есть значения этого атрибута в какие-то моменты могут отсутствовать или быть неопределенными. ДугиЕсли сущность имеет набор взаимоисключающих отношений с другими сущностями, то говорят, что такие отношения находятся в дуге. Например, банковский счет может быть оформлен или для юридического лица, или для физического лица. Фрагмент ER-диаграммы для такого типа отношений приведен на рис. 4.5. Рис. 4.5. Дуга В этом случае атрибут ВЛАДЕЛЕЦ сущности СЧЕТ имеет особое значение для данной сущности - сущность делится на типы по категориям для физического лица и для юридического лица. Полученные в результате сущности называют подтипами, а исходная сущность становится супертипом.

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

Следует отметить, что злоупотребление подтипами и супертипами является довольно распространенной ошибкой. Изображают их так, как показано на рис. 4.6. Рис. 4.6. Подтипы справа и супертип слева