Общие требования к методологии и технологии проектирования
Институт управления проектами, который специализируется не только на производстве ПО, приводит в своем Руководстве РМВОК® неплохо сформулированное определение. Согласно PMI®, проект рассматривается как временное усилие, предпринятое для того, чтобы создать уникальный продукт или услугу с определенной датой начала и окончания действия, отличающегося от продолжающихся, повторных действий и требующего прогрессивного совершенствования характеристик. Эти определения проекта имеют несколько общих характеристик. Цель. У проекта должна быть четко определенная цель или ряд целей. В ходе осуществления проекта должен быть получен какой-либо результат. Если проект имеет много целей, то они должны быть связаны между собой и не конфликтовать друг с другом. Момент начала и завершения действия. Проект — это продукт временного приложения усилий. Он должен иметь четко определенное начало и конец действия, обычно выражаемое в виде каких-либо дат. Поддержка ПО обычно представляет собой продолжающееся действие и не является проектом, но может включать строго очерченные проекты, которые происходят в его пределах, например, как отдельные версии. Уникальность. Проект — одноразовая сущность, не всегда повторяющая один и тот же путь. Но это не значит, что повторяющаяся работа не является проектом. Постройка дома обычно классифицируется как проект даже в том случае, когда подрядчики уже до этого сконструировали миллионы зданий. Хотя образец и процесс в основном те же самые (шаблон), имеется достаточное количество различий в каждом доме (участок земли и его местоположение, варьирующиеся материалы, изменения программы и разработки проекта). В противном случае речь будет идти о поточной линии, когда идентичные части выполняются аналогичным образом. То же самое справедливо и для профессионалов в области разработки ПО — они никогда не создают какую-либо идентичную программную систему, хотя могут ее копировать или переносить произвольным образом. Ограничения. Проект имеет ограничения по стоимости, графику и качеству выполнения. Итак, практическое определение термина " проект" в терминах разработки ПО таково: проект — это уникальное, временное действие с определенными датами начала и конца, направленное на то, чтобы достичь одной или нескольких целей в пределах ограничений стоимости, графика и качества выполнения. Основу проекта любой ИС составляют [4]: - методологии, - технологии, - инструментальные средства проектирования (CASE-средства).
Рис.2.10 - Представление технологической операции проектирования
Методология реализуется через конкретные технологии и поддерживающие их стандарты, методики и инструментальные средства, которые обеспечивают выполнение процессов ЖЦ (рис.2.10). Технология проектирования определяется как совокупность трех составляющих: - пошаговой процедуры, определяющей последовательность технологических операций проектирования; - критериев и правил, используемых для оценки результатов выполнения технологических операций; - нотаций (графических и текстовых средств), используемых для описания проектируемой системы. Технологические инструкции, составляющие основное содержание технологии, должны состоять из описания последовательности технологических операций, условий, в зависимости от которых выполняется та или иная операция, и описаний самих операций. Технология проектирования, разработки и сопровождения ИС должна удовлетворять следующим общим требованиям: - технология должна поддерживать полный ЖЦ ПО; - технология должна обеспечивать гарантированное достижение целей разработки ИС с заданным качеством и в установленное время; - технология должна обеспечивать возможность выполнения крупных проектов в виде подсистем (т.е. возможность декомпозиции проекта на составные части, разрабатываемые группами исполнителей ограниченной численности с последующей интеграцией составных частей). Опыт разработки крупных ИС показывает, что для повышения эффективности работ необходимо разбить проект на отдельные слабо связанные по данным и функциям подсистемы. Реализация подсистем должна выполняться отдельными группами специалистов. При этом необходимо обеспечить координацию ведения общего проекта и исключить дублирование результатов работ каждой проектной группы, которое может возникнуть в силу наличия общих данных и функций; - технология должна обеспечивать возможность ведения работ по проектированию отдельных подсистем небольшими группами (3-7 человек). Это обусловлено принципами управляемости коллектива и повышения производительности за счет минимизации числа внешних связей; - технология должна обеспечивать минимальное время получения работоспособной ИС. Речь идет не о сроках готовности всей ИС, а о сроках реализации отдельных подсистем. Реализация ИС в целом в короткие сроки может потребовать привлечения большого числа разработчиков, при этом эффект может оказаться ниже, чем при реализации в более короткие сроки отдельных подсистем меньшим числом разработчиков. Практика показывает, что даже при наличии полностью завершенного проекта, внедрение идет последовательно по отдельным подсистемам; - технология должна предусматривать возможность управления конфигурацией проекта, ведения версий проекта и его составляющих, возможность автоматического выпуска проектной документации и синхронизацию ее версий с версиями проекта; - технология должна обеспечивать независимость выполняемых проектных решений от средств реализации ИС (систем управления базами данных (СУБД), операционных систем, языков и систем программирования); - технология должна быть поддержана комплексом согласованных CASE-средств, обеспечивающих автоматизацию процессов, выполняемых на всех стадиях ЖЦ. Реальное применение любой технологии проектирования, разработки и сопровождения ИС в конкретной организации и конкретном проекте невозможно без выработки ряда стандартов (правил, соглашений), которые должны соблюдаться всеми участниками проекта. К таким стандартам относятся следующие: - стандарт проектирования; - стандарт оформления проектной документации; - стандарт пользовательского интерфейса. Стандарт проектирования должен устанавливать: - набор необходимых моделей (диаграмм) на каждой стадии проектирования и степень их детализации; - правила фиксации проектных решений на диаграммах, в том числе: правила именования объектов (включая соглашения по терминологии), набор атрибутов для всех объектов и правила их заполнения на каждой стадии, правила оформления диаграмм, включая требования к форме и размерам объектов, и т. д.; - требования к конфигурации рабочих мест разработчиков, включая настройки операционной системы, настройки CASE-средств, общие настройки проекта и т. д.; - механизм обеспечения совместной работы над проектом, в том числе: правила интеграции подсистем проекта, правила поддержания проекта в одинаковом для всех разработчиков состоянии (регламент обмена проектной информацией, механизм фиксации общих объектов и т.д.), правила проверки проектных решений на непротиворечивость и т. д. Стандарт оформления проектной документации должен устанавливать: - комплектность, состав и структуру документации на каждой стадии проектирования; - требования к ее оформлению (включая требования к содержанию разделов, подразделов, пунктов, таблиц и т.д.), - правила подготовки, рассмотрения, согласования и утверждения документации с указанием предельных сроков для каждой стадии; - требования к настройке издательской системы, используемой в качестве встроенного средства подготовки документации; - требования к настройке CASE-средств для обеспечения подготовки документации в соответствии с установленными требованиями. Стандарт интерфейса пользователя должен устанавливать: - правила оформления экранов (шрифты и цветовая палитра), состав и расположение окон и элементов управления; - правила использования клавиатуры и мыши; - правила оформления текстов помощи; - перечень стандартных сообщений; - правила обработки реакции пользователя.
|
