Проектирование АИС. С аратовский госуниверситет м еханико математический факультет проектирование информационных систем Составил
 Скачать 3.17 Mb.
|
|
3.3 ISO/IEC 12207 В соответствии с базовым международным стандартом ISO/IEC 12207 все процессы ЖЦ ПО делятся на три группы: 1. Основные процессы: • приобретение; • поставка; • разработка; • эксплуатация; • сопровождение. 2. Вспомогательные процессы: • документирование; • управление конфигурацией; • обеспечение качества; • разрешение проблем; • аудит; • аттестация; • совместная оценка; • верификация. 3. Организационные процессы: • создание инфраструктуры; • управление; • обучение; • усовершенствование. В таблице 3.1 приведены ориентировочные описания основных процессов ЖЦ. Вспомогательные процессы предназначены для поддержки выполнения основных процессов, обеспечения качества про- екта, организации верификации, проверки и тестирования ПО. Организационные процессы опреде- ляют действия и задачи, выполняемые как заказчиком, так и разработчиком проекта для управления своими процессами. Позднее был разработан и в 2002 г. опубликован стандарт на процессы жизненного цикла систем (ISO/IEC 15288 System life cycle processes). К разработке стандарта были привлечены специалисты различных областей: системной инженерии, программирования, управления качеством, человече- скими ресурсами, безопасностью и пр. Был учтен практический опыт создания систем в правитель- ственных, коммерческих, военных и академических организациях. Стандарт применим для широкого класса систем, но его основное предназначение - поддержка создания компьютеризированных систем. Таблица 3.1: Содержание основных процессов ЖЦ ПО ИС (ISO/IEC 12207) Действия Вход Результат Приобретение (заказчик) Инициирование. Подго- товка заявочных предло- жений. Подготовка дого- вора. Контроль деятель- ности поставщика. При- емка ИС. Решение о начале работ по внедрению ИС. Результаты обследования деятельности заказчика. Результаты ана- лиза рынка ИС/ тендера. План поставки/ разработки. Комплексный тест ИС. Технико-экономическое обоснование внедрения ИС. Техническое задание на ИС. Договор на поставку/ разработку. Акты приемки этапов работы. Акт приемно-сдаточных испытаний. Поставка (разработчик ИС) Инициирование. Ответ на заявочные пред- ложения. Подготовка договора. Планирование исполнения. Поставка ИС. Техническое задание на ИС. Решение руководства об уча- стии в разработке. Результа- ты тендера. Техническое зада- ние на ИС. План управления проектом. Разработанная ИС и документация. Решение об участии в разработке. Ком- мерческие предложения/ конкурсная за- явка. Договор на поставку/ разработ- ку. План управления проектом. Реа- лизация/ корректировка. Акт приемно- сдаточных испытаний. Действия Вход Результат Разработка (разработчик ИС) Подготовка. Анализ тре- бований к ИС. Проек- тирование архитектуры ИС. Разработка требова- ний к ПО. Проектиро- вание архитектуры ПО. Детальное проектирова- ние ПО. Кодирование и тестирование ПО. Ин- теграция ПО и квали- фикационное тестирова- ние ПО. Интеграция ИС и квалификационное те- стирование ИС. Техническое задание на ИС. Техническое задание на ИС, модель ЖЦ. Техническое за- дание на ИС. Подсистемы ИС. Спецификации требования к компонентам ПО. Архитекту- ра ПО. Материалы детально- го проектирования ПО. План интеграции ПО, тесты. Архи- тектура ИС, ПО, документа- ция на ИС, тесты. Используемая модель ЖЦ, стандарты разработки. План работ. Состав подси- стем, компоненты оборудования. Специ- фикации требования к компонентам ПО. Состав компонентов ПО, интерфейсы с БД, план интеграции ПО. Проект БД, спецификации интерфейсов между ком- понентами ПО, требования к тестам. Тексты модулей ПО, акты автономно- го тестирования. Оценка соответствия комплекса ПО требованиям ТЗ. Оцен- ка соответствия ПО, БД, техническо- го комплекса и комплекта документации требованиям ТЗ. Согласно стандарту ISO/IEC серии 15288 в структуру ЖЦ следует включать следующие группы процессов: 1. Договорные процессы: • приобретение (внутренние решения или решения внешнего поставщика); • поставка (внутренние решения или решения внешнего поставщика). 2. Процессы предприятия: • управление окружающей средой предприятия; • инвестиционное управление; • управление ЖЦ ИС; • управление ресурсами; • управление качеством. 3. Проектные процессы: • планирование проекта; • оценка проекта; • контроль проекта; • управление рисками; • управление конфигурацией; • управление информационными потоками; • принятие решений. 4. Технические процессы: • определение требований; • анализ требований; • разработка архитектуры; • внедрение; • интеграция; • верификация; • переход; • аттестация; • эксплуатация; • сопровождение; • утилизация. 5. Специальные процессы: • определение и установка взаимосвязей исходя из задач и целей. Стадии создания системы, предусмотренные в стандарте ISO/IEC 15288, несколько отличаются от рассмотренных выше. Перечень стадий и основные результаты, которые должны быть достигнуты к моменту их завершения: 1. Формирование концепции. Анализ потребностей, выбор концепции и проектных решений. 2. Разработка. Проектирование системы. 3. Реализация. Изготовление системы. 4. Эксплуатация. Ввод в эксплуатацию и использование системы. 5. Поддержка. Обеспечение функционирования системы. 6. Снятие с эксплуатации. Прекращение использования, демонтаж, архивирование. 3.4 Экстремальное программирование 3.4.1 Теория Экстремальное программирование (XP) – методология быстрой разработки программного обеспе- чения. Состоит из набора методик и принципов, позволяющих как по отдельности, так и в комплексе, оптимизировать процесс разработки. Этот подход также регламентирует права разработчиков и за- казчиков. Права и роли В экстремальном программировании чётко описаны все роли. Каждая роль предусматривает харак- терный набор прав и обязанностей. Здесь существуют две ключевые роли: заказчик и разработчик. Заказчик Человек или группа людей, заинтересованных в создании конкретного программного продукта. Он имеет следующие права и обязанности: • зафиксировать сроки выпуска версий продукта; • принимать решения относительно запланированных составляющих программы; • знать ориентировочную стоимость каждой функциональной составляющей; • принимать важные бизнес - решения; • знать текущее состояние системы; • изменять требования к системе, когда это действительно важно. Для успешного использования своих прав заказчик должен полагаться на данные, предоставляе- мые разработчиками. Разработчик Один или группа от двух до десяти человек, занимающихся непосредственно программированием и сопутствующими инженерными вопросами. Разработчик наделён следующими правами и обязанно- стями: • получить достаточное знание вопросов, которые должны быть запрограммированы; • иметь возможность выяснения деталей в процессе разработки; • предоставлять ориентировочные, но откровенные оценки трудозатрат на каждую функциональ- ную часть или историю пользователя; • корректировать оценки в пользу более точных в процессе разработки; • предоставлять оценку рисков, связанных с использованием конкретных технологий. Роли внутри роли Каждая из базовых ролей экстремального программирования может быть уточнена более мелкими ролями. В XP разрешено совмещение ролей в рамках одного человека. Сторона заказчика Составитель историй – специалист предметной области, обладающий способностями доступно из- ложить и описать требования к разрабатываемой системе. Этот человек или группа людей ответ- ственны за написание историй пользователя и прояснения недопонимания со стороны программистов. Приёмщик – человек, контролирующий правильность функционирования системы. Хорошо вла- деет предметной областью. В обязанности входит написание приёмочных тестов. Большой босс – следит за работой всех звеньев, от разработчиков до конечных пользователей. Он контролирует внедрение системы и сопутствующие организационные моменты. Может быть также инвестором проекта. Сторона разработчика Программист – человек, занимающийся кодированием и проектированием на низком уровне. Он достаточно компетентен для решения текущих задач разработки и предоставления правдивых оценок запланированным задачам. Инструктор – опытный разработчик, хорошо владеющий всем процессом разработки и его мето- диками. Несёт ответственность за обучение команды аспектам процесса разработки. Внедряет и кон- тролирует правильность выполнения методик используемого процесса. Обращает внимание команды на важные, но по каким-то причинам упущенные моменты разработки. Вместе с тем инструктор, как и любой другой человек, не всезнающий и с вниманием относится к идеям других членов команды. Наблюдатель – член команды разработчиков, пользующийся доверием всей группы, который следит за прогрессом разработки. Он сравнивает предварительные оценки трудозатрат и реально потраченные, выводя количественные показатели работы команды. Это такие как средняя скорость и процентное соотношение выполненных и запланированных задач. Данная информация предостав- ляется заказчику для своевременного контроля над ситуацией. Часть этой информации ненавязчиво предоставляется и разработчикам, для знания состояния проекта, мест возникновения затруднений и что ещё можно успеть сделать. Дипломат – коммуникабельная личность, инициирующая общение между членами команды. Так как документооборот минимизирован, важно постоянное общение и передача опыта внутри команды, лучшее понимание требований к системе. Дипломат регулирует и упрощает общение между заказ- чиками и разработчиками. Является важным звеном на собраниях. Он препятствует недомолвкам, разгару страстей и ненужным ссорам. Дипломат не может навязывать своего мнения дискуссирую- щим. Внешние роли Консультант – специалист, обладающий конкретными техническими навыками, для помощи разра- ботчикам в трудно разрешимых задачах. Обычно привлекается со стороны. 3.4.2 Правила Соглашение о кодировании Вы в команде, которая работает над данным проектом продолжительное время. Люди приходят и уходят. Никто не кодирует в одиночку и код принадлежит всем. Всегда будут моменты, когда необходимо будет понять и скорректировать чужой код. Разработчики будут удалять или изменять дублирующий код, анализировать и улучшать чужие классы и т.п. Со временем нельзя будет сказать кто автор конкретного класса. Следовательно, все должны подчиняться общим стандартам кодирования - форматирование кода, именование классов, переменных, констант, стиль комментариев. Таким образом, мы будем уверены, что внося изменения в чужой код (что необходимо для агрессивного и экстремального продвижения вперед) мы не превратим его в Вавилонское Столпотворение. Вышесказанное означает, что все члены команды должны договориться об общих стандартах кодирования. Неважно каких. Правило заключается в том, что все им подчиняются. Те, кто не желает их соблюдать покидает команду. Коллективное владение кодом Коллективное владение кодом стимулирует разработчиков подавать идеи для всех частей проекта, а не только для своих модулей. Любой разработчик может изменять любой код для расширения функциональности, исправления ошибок или рефакторинга. С первого взгляда это выглядит как хаос. Однако принимая во внимание что как минимум лю- бой код создан парой разработчиков, что Unit тесты позволяют проверить корректность внесенных изменений и что в реальной жизни все равно так или иначе приходится разбираться в чужом ко- де, становится ясно что коллективное владение кодом значительно упрощает внесение изменений и снижает риск связанный с высокой специализацией того или иного члена команды. CRC Сессия Используйте Class, Responsibilities, Collaboration (CRC - Класс, Обязанности, Взаимодействие) кар- точки для дизайна системы командой. Использование карточек позволяет легче приучиться мыслить объектами а не функциями и процедурами. Также карточки позволяют большему количеству людей участвовать в процессе дизайна (в идеале - всей команде), а чем больше людей делает дизайн, тем больше интересных идей будет привнесено. Каждая CRC карточка представляет собой экземпляр обьекта. Класс обьекта может быть написан сверху, обязанности слева, взаимодействия справа. Мы говорим "могут быть написаны поскольку когда CRC сессия в разгаре, участникам обычно нужно небольшое число карточек с именами классов и не обязательно они должны быть полностью заполнены. CRC сессия происходит так: каждый из участников воспроизводит систему говоря какие сообще- ния он шлет каким объектам. Проходит по всему процессу сообщение за сообщением. Слабые места и проблемы сразу выявляются. Альтернативы дизайна также хорошо видны при симуляции процес- са. Для наведения порядка часто используется ограничение числа одновременно взаимодействующих двумя. Заказчик Одно из требований XP - заказчик всегда доступен. Он должен не просто помогать команде раз- работчиков, а быть ее членом. Все фазы XP проекта требуют коммуникации с заказчиком, лучше всего лицом к лицу - на месте. Лучше всего, просто назначить одного или нескольких заказчи- ков в команду разработчиков. Остерегайтесь, заказчик потребуется на длительное время, и контора заказчика может постараться отдать вам какого-нибудь стажера в качестве эксперта. Вам нужен эксперт. User Stories пишутся заказчиком с помощью разработчиков. Заказчик помогает удостовериться что большинство желаемых функций системы покрыто User Story. Во время планирования релиза заказчику необходимо обсудить выбор User Stories которые будут включены в планируемый релиз. Также, возможно, потребуется согласовывать период самого релиза. Заказчик принимает решения относящиеся к целям бизнеса. Выбирайте самое простое решение Простой дизайн всегда легче реализовать, чем сложный. Поэтому всегда делайте простейшее реше- ние, которое может работать. Если находите что-нибудь сложное - замените это чем-нибудь простым. Всегда оказывается быстрее и дешевле заменить сложный код простым до того как начнешь разби- раться в сложном коде. Рефакторите чужой код если он кажется вам сложным. Если что-то выглядит сложным - это верный признак проблемы в коде. Сохраняйте решения насколько возможно простыми как можно дольше. Никогда не добавляйте функциональность на будущее - до того как появляется в ней необходимость. Однако имейте в виду: сохранять дизайн простым - тяжелая работа. Функциональные тесты Приемочные тесты (ранее их также называли Функциональные) пишутся на основе User Story. Они рассматривают систему как черный ящик. Заказчик ответственен за проверку корректности функци- ональных тестов. Эти тесты используются для проверки работоспособности системы перед выпуском ее в производство. Функциональные тесты автоматизируются так, чтобы имелась возможность их часто запускать. Результат сообщается команде и команда отвечает за планирование исправлений функциональных тестов. Частая интеграция Разработчики, по-возможности, должны интегрировать и выпускать свой код каждые несколько часов. В любом случае никогда нельзя держать изменения дольше одного дня. Частая интеграция позволяет избежать отчуждения и фрагментирования в разработке, когда разработчики не могут общаться в смысле обмена идеями или повторного использования кода. Каждый должен работать с самой последней версией. Каждая пара разработчиков должна отдавать свой код как только для этого появляется разумная возможность. Это может быть когда все UnitTest-ы проходят на 100%. Отдавая изменения несколько раз в день, Вы сводите проблемы интеграции практически к нулю. Интеграция - это деятельность вида "заплати сейчас или заплати больше позднее". Поэтому интегрируя изменения ежедневно ма- ленькими порциями вы не окажетесь перед необходимостью тратить неделю чтобы связать систему в одно целое непосредственно перед сдачей проекта. Всегда работайте над последней версией системы. Для менеджера. Если разработчик не отдает изменений дольше одного дня - это ясный индикатор серьезной проблемы. Вы должны немедленно разобраться в чем дело. Весь опыт XP команд говорит что всегда причиной задержки является плохой дизайн и его всегда потом приходится переделывать. Планирование Итерации Iteration Planning Meeting созывается перед началом каждой итерации для планирования задач которые будут сделаны в этой итерации. Для итерации выбираются User Stories, которые выбрал заказчик в плане релиза начиная с самых важных для заказчика и самых плохих (сопряженных с риском) для разработчиков. Также в итерацию включаются неработающие Функциональные тесты. User Stories и невыполненные Функциональные тесты разбиваются на задачи. Задачи записыва- ются на карточках. Эти карточки и есть детальный план на итерацию. Каждая задача должна быть продолжительностью от 1 до 3 идеальных дней. Разработчики разбирают задачи и оценивают про- должительность времени, необходимого для их выполнения. Таким образом, каждый разработчик оценивает сколько времени задача займет именно у него. Это важно, чтобы конечную оценку обьема работ делал сам разработчик. Скорость проекта определяет помещаются ли ваши задачи в итерацию или нет. Общая продол- жительность задач запланированных на итерацию не должна превышать скорости, достигнутой в предыдущей итерации. Если вы набрали слишком много, то заказчик должен решить какие User Stories, отложить на следующую итерацию. Если набрали слишком мало, то надо добавить следую- щую User Story. В некоторых случаях можно попросить заказчика разделить одну из User Story, на две, чтобы включить часть в текущую итерацию. Откладывание User Story на следующую итерацию может выглядеть страшно, но не позволяйте себе жертвовать рефакторингом и Unit Test-ами чтобы сделать больше. Задолженность по этим ка- тегориям быстро замедлит вашу скорость. Не делайте того, что по-вашему понадобится в следующих итерациях - делайте только то что необходимо для выполнения текущих User Stories. Следите за скоростью проекта и отложенными User Stories. Вполне возможно, что план релиза придется переделывать каждые три-пять итераций. Это нормально. Ведь план релиза - это взгляд в будущее и естественно ожидать что ваши предсказания придется корректировать. |