Лекция 7

ИС (СРС).
2. Технология Microsoft Solution Framework.
3. Технология RUP.
4. Технология Borland

(СРС).

взаимосвязанных технологических процессов в рамках ЖЦ ПО.
Технологический процесс — совокупность

взаимосвязанных технологических операций.
Технологическая операция — основная единица работы, выполняемая определенной ролью, которая:
подразумевает четко определенную ответственность роли;
дает четко определенный результат (набор рабочих продуктов), базирующийся на определенных исходных данных (другом наборе рабочих продуктов);
представляет собой единицу работы с жестко определенными границами, которые устанавливаются при планировании проекта.
Рабочий продукт — информационная или материальная сущность, которая создается, модифицируется или используется в некоторой технологической операции (модель, документ, код, тест и т.п.). Рабочий продукт определяет область ответственности роли и является объектом управления конфигурацией.
Роль — определение поведения и обязанностей отдельного лица или группы лиц в среде организации — разработчика ПО, осуществляющих деятельность в рамках некоторого технологического процесса и ответственных за определенные рабочие продукты.
Руководство — практическое руководство по выполнению одной или совокупности технологических операций. Руководства включают и себя методические материалы, инструкции, нормативы, стандарты и критерии оценки качества рабочих продуктов.
Инструментальное средство (CASE-средство) — программное средство, обеспечивающее автоматизированную поддержку деятельности, выполняемой в рамках технологических операций.

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

систем»;
ГОСТ 34.320—96 «Информационные технологии. Система стандартов по базам данных. Концепции и терминология для концептуальной схемы и информационной базы»;
ГОСТ 34.321—96 «Информационные технологии. Система стандартов по базам данных. Эталонная модель управления данными»;
ГОСТ 34.601—90 «Информационная технология. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Стадии создания»;
ГОСТ 34.602—89 «Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы»;
ГОСТ 34.603—92 «Информационная технология. Виды испытаний автоматизированных систем»;
РД 50-34.698-90 «Автоматизированные системы. Требования к содержанию документов»;
ГОСТ Р ИСО/МЭК 8824-3—2002 «Информационная технология. Абстрактная синтаксическая нотация версии один (АСН. 1). Ч. 3. Спецификация ограничения»;
ГОСТ Р ИСО/МЭК 10746-3—2001 «Информационная технология. Взаимосвязь открытых систем. Управление данными и откры­тая распределенная обработка. Ч. 3. Архитектура»;
ГОСТ Р ИСО/МЭК 15271-02 «Информационная технология. Руководство по применению ГОСТ Р ИСО/МЭК 12207. Процессы жизненного цикла программных средств»;
ГОСТ Р ИСО/МЭК 15910—2002 «Информационная техноло­гия. Процесс создания документации пользователя программного сред­ства»;
ГОСТ Р ИСО/МЭК 15408—2001 «Методы и средства обеспечения безопасности. Критерии оценки безопасности ИТ (ч. 1, 2, 3)»;
ГОСТ Р ИСО/МЭК 9594-8—98 «ИТ. ВОС. Справочник. Ч. 8. Основы аутенти­фикации»;
ISO 12207, ISO 9000, СММ

построена и структурирована проектная группа, для того чтобы можно было

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

моде­ли команды, рассмотренных выше. Она определяет основные роли, закрепленные за

членами проектной группы. Для каждого члена группы определяется роль и зоны ответствен­ности на весь период работы над проектом. То есть каждый сфокуси­рован на успехе проекта и настроен на работу в течение всего цикла проекта. Ключевым фактором успеха являются коммуникации между членами проектной группы. При этом реализуется параллельная ра­бота всех участников группы над проектом, в состав которого в обяза­тельном порядке включаются пользователи и обучающий персонал.
Модель проектной группы MSF практически не связана с органи­зационной структурой, в одной проектной группе могут работать спе­циалисты из различных подразделений. За каждым членом проектной группы закрепляется конкретная роль, для которой строится план ра­боты, являющийся составной частью общего плана проекта. При этом каждая роль в модели проектной группы имеет свою особую компетенцию.
Если численность проектной группы меньше шести человек, то часть ролей может совмещать и выполнять один человек. При чис­ленности проектной группы больше шести человек одна роль может быть закреплена за несколькими специалистами, среди которых на­значается лидер группы.

проводятся работы до того, как сформированы требования. Все работы до

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

использования объектов различными приложениями и средствами разработки программного обеспечения.
Информационная

модель инструментария – это описание систем или процессов, опубликованных в репозитарии. В нем может находиться любое число таких моделей, каждая с описанием своей системы или процесса. Модель определяет объек­ты, интерфейсы, отношения и связи, образующие систему. С другой стороны, данную модель можно рассматривать и как своего рода шаблон для систем конкретного типа. Стандартизация моделей позволяет разным средам и средствам разработки взаимодействовать с данными в хра­нилище.
Repository Browser – позволяет просматривать содержимое репозитария.
Визуальный диспетчер компонентов - обеспечивает разработчику возмож­ность сохранять программные компоненты в репозитарии и тем са­мым упростить повторное использование кода. Таким образом, появ­ляется возможность повысить производительность труда коллектива разработчиков за счет классификации и публикации компонентов и обеспечения доступа к ним. Работая с диспетчером, программист может найти необходимый фрагмент кода и воспользоваться им, загрузить шаблон проекта, за­пустить мастер или добавить в проект управляющий элемент ActiveX. Кроме того, репозитарии может играть роль центра хранения доку­ментации, включая принятые стандарты программирования, функ­циональные спецификации или архитектурные диаграммы.

инкрементным
Прецеденты – это основной артефакт, на основании которого уста-навливается

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

инкрементным
Основным решением, принимаемым в ходе проекта, является архитектура ПС.

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

инкрементным
Итеративным называется процесс, который предполагает управление потоком исполня-емых версий системы.
Инкрементный

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

в рамках каждой из которых возможно проведение нескольких итераций. Кроме

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

организации;
определение требований – описывается основанный на прецедентах метод постановки требований;
анализ

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

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

система, и убедиться, что все заинтересованные лица понимают его одинаково, осознать имеющиеся проблемы, оценить их возможные решения и их последствия для бизнеса организации, в которой будет работать система. В результате моделирования предметной области должна появиться ее модель в виде набора диаграмм классов (объектов предметной области) и деятельностей (представляющих бизнес-операции и бизнес-процессы). Эта модель служит основой модели анализа.
Определение требований. Задачи – понять, что должна делать система, и убедиться во взаимопонимании по этому поводу между заинтересованными лицами, определить границы системы и основу для планирования проекта и оценок затрат ресурсов в нем. Требования принято фиксировать в виде модели вариантов использования.
Анализ и проектирование. Задачи – выработать архитектуру системы на основе требований, убедиться, что данная архитектура может быть основой работающей системы в контексте ее будущего использования. В результате проектирования должна появиться модель проектирования, включающая диаграммы классов системы, диаграммы ее компонентов, диаграммы взаимодействий между объектами в ходе реализации вариантов использования, диаграммы состояний для отдельных объектов и диаграммы развертывания.
Реализация. Задачи – определить структуру исходного кода системы, разработать код ее компонентов и протестировать их, интегрировать систему в работающее целое.
Тестирование. Задачи – найти и описать дефекты системы (проявления недостатков ее качества), оценить ее качество в целом, оценить выполнены или нет гипотезы, лежащие в основе проектирования, оценить степень соответствия системы требованиям.
Развертывание. Задачи – установить систему в ее рабочем окружении и оценить ее работоспособность на том месте, где она должна будет работать.
Управление конфигурациями и изменениями. Задачи – определение элементов, подлежащих хранению в репозитории проекта и правил построения из них согласованных конфигураций, поддержание целостности текущего состояния системы, проверка согласованности вносимых изменений.
Управление проектом. Задачи – планирование, управление персоналом, обеспечение взаимодействия на благо проекта между всеми заинтересованными лицами, управление рисками, отслеживание текущего состояния проекта.
Управление средой проекта. Задачи – подстройка процесса под конкретный проект, выбор и замена технологий и инструментов, используемых в проекте.

формализует контекст системы;
модель вариантов использования – формализует функциональные требования к

системе;
модель анализа – формализует идею проекта;
модель проектирования – формализует словарь предметной области и области решения;
модель процессов (необязательная) – формализует механизмы параллелиз­ма и синхронизации в системе;
модель развертывания – формализует топологию аппаратных средств, на которых выполняется система;
модель реализации – описывает части, из которых собирается физическая система;
модель тестирования – формализует способы проверки и приемки системы.