Проектирование АИС. С аратовский госуниверситет м еханико математический факультет проектирование информационных систем Составил
 Скачать 3.17 Mb.
|
|
Итерации Итеративная разработка увеличивает гибкость процесса. Разделите ваш план на итерации продол- жительностью от 2 до 3 недель. Сохраняйте постоянную продолжительность итерации на время проекта. Пусть итерации будут пульсом вашего проекта. Это тот ритм который позволит сделать измерение прогресса и планирование простым и надежным. Не планируйте задач заранее. Вместо этого собирайте Планирование Итерации в начале каждой итерации чтобы запланировать что будет сделано. Также нарушением правил считается забегать вперед и делать то, что не запланировано в этой итерации. Таким образом, становится возможным держать под контролем изменяющиеся требования Заказчика. Принимайте всерьез сроки завершения итерации. Измеряйте прогресс в процессе работы. Если видно, что вы не сможете сделать все запланированные задачи к сроку, то снова собирайте Плани- рование Итерации и оцените задачи заново и отложите часть задач. Сконцентрируйте усилия на завершении самых важных задач, выбранных Заказчиком, вместо того чтобы иметь несколько незаконченных задач, выбранных разработчиком. Меняйтесь задачами Необходимо периодически менять задачи у разработчиков для уменьшения риска концентрации зна- ний и узких мест в коде. Если только один человек в вашей команде может работать в данной области и этот человек уходит или вам просто надо много всего сделать в данном сегменте программы, вы обнаружите что ваш проект еле-еле продвигается вперед. Cross Training обычно является важным аспектом в компаниях которые стараются избежать кон- центрации знаний в одном человеке. Перемещение людей по коду в комбинации с парным програм- мированием незаметно делает Cross Training для вас. Вместо одного человека, который знает все о данном куске кода, каждый в вашей команде знает много о коде в каждом модуле. Команда становится намного более гибкой если все знают достаточно о каждой части системы что- бы начать работать над ней. Вместо того чтобы ждать пока "гуру"закончит работу над критическим куском кода, несколько программистов могут работать над ним одновременно. При начале новой итерации каждый разработчик должен перейти на новую задачу. Парное про- граммирование помогает преодолеть проблему адаптации (это значит что новый разработчик может начать работать в паре с опытным в данной области разработчиком). Такая практика также стимулирует появление новых идей и улучшение кода. Оставляйте оптимизацию на потом Никогда не оптимизируйте ничего до окончания кодирования. Никогда не пытайтесь угадать где будут узкие места по производительности. Измеряйте! Сделайте чтобы это работало, затем чтобы работало правильно, затем чтобы работало быстро. Парное программирование Весь код для продукционной системы (а это значит за исключением пробных решений) пишется парами. Два разработчика сидят рядом. Один набирает, другой смотрит. Время от времени они меняются. Не разрешается работать в одиночку. Если по какой-то причине второй из пары пропустил что-то (болел, отходил и т.п.) он обязан просмотреть все изменения сделанные первым. Звучит необычно, но XP утверждает что после небольшого периода адаптации большинство лю- дей прекрасно работают в парах. Им даже нравится, поскольку работа делается заметно быстрее. Действует принцип "Одна голова хорошо, а две лучше". Пары обычно находят более оптимальные ре- шения. Кроме того существенно увеличивается качество кода, снижается число ошибок и ускоряется обмен знаниями между разработчиками. Рефакторинг Мы, программисты, склонны держаться за дизайн долго после того как он становится неуклюжим. Мы продолжаем повторно использовать неудобный в сопровождении код поскольку он все еще как- то работает и мы боимся испортить его. Но действительно ли это выгодно? XP принимает точку зрения что это невыгодно. Когда мы убираем избыточность, улучшаем устаревший дизайн убираем неиспользуемые куски - мы делаем рефакторинг. Рефакторинг в конечном итоге экономит время и улучшает качество продукта. Безжалостно пересматривайте любой код для того, чтобы сохранять дизайн простым по мере разработки. Сохраняйте код ясным и понятным чтобы его было легко понять, модифицировать и расширять. Удостоверьтесь что все написано один и только один раз. В конечном итоге, это занимает меньше времени чем доводить до ума запутанную систему. План Релиза План Релиза разрабатывается на собрании по планированию Релиза. Релиз Планы описывают взгляд на весь проект и используются в дальнейшем для планирования итераций. Важно, чтобы технические люди делали технические решения и люди бизнеса - бизнес решения. Планирование Релиза определяет набор правил, которые позволяют всем принимать свои решения. Эти правила определяют метод выработки удовлетворяющего всех плана работ. Сущность собрания по планированию релиза для команды разработчиков в том, чтобы оценить каждую User Story в идеальных неделях. Идеальная неделя - это сколько по-вашему займет время выполнение задачи если ничто больше вас не будет отвлекать. Ни зависимостей, ни дополнительных задач, но включая тесты. Заказчик затем решает какие задачи наиболее важны или имеют более высокий приоритет. User Stories записываются на карточках. Разработчики и Заказчик вместе тасуют карточки на сто- ле пока не получится набор User Stories которые вместе будут составлять первый (или следующий) Релиз. Всем хочется выпустить как можно раньше полезную систему которую можно протестиро- вать. Релиз можно планировать по времени или по обьему. Для того чтобы определить сколько User Stories могут быть реализованы к конкретной дате или сколько реального времени займет данный набор задач используют скорость проекта. Если планируете по времени, умножьте количество ите- раций на скорость проекта для того чтобы узнать сколько User Story может быть реализовано. При планировании по обьему, разделите общее количество идеальных недель необходимых для всех User Stories на скорость проекта и вы получите количество итераций необходимых для окончания релиза. Если менеджмент не устраивают сроки завершения, может появиться соблазн уменьшить оцен- ки объема работ. Вы никогда не должны этого делать. Заниженные оценки обязательно создадут множество проблем позже. Вместо этого ведите переговоры с менеджерами, разработчиками и за- казчиками пока не выработаете приемлемый для всех план релиза. Частые Релизы Разработчики должны выпускать версии системы пользователям (или бета-тестерам) как можно чаще. Планирование Релиза используется для поиска небольших функциональных фрагментов имеющих значимый бизнес-смысл и которые могут быть выпущены в реальное окружение на ранних стадиях разработки. Это критично для своевременного получения полезных отзывов, чтобы иметь возмож- ность влиять на процесс разработки. Чем больше вы задерживаете выпуск важной части системы тем меньше у вас будет времени исправить ее. Пробное решение Создавайте пробные решения для ответа на сложные технические вопросы, для обоснования тех или иных технологических решений. При принятии любого технологического решения существует риск и пробные решения призваны уменьшить его. Сделайте программу которая воспроизводит исследуемую проблему и игнорирует все остальное. Большинство пробных решений не предназначены для последующего использования так что ожи- дайте что они будут выброшены. Цель их создания - уменьшить риск принятия неправильного технического решения или более точная оценка времени на реализацию User Story. Собрание стоя Каждое утро проводится собрание для обсуждения проблем, их решений и для усиления концентра- ции команды. Собрание проводится стоя для избежания длительных дискуссий не интересных всем членам команды. В типичном собрании большинство участников ничего не вносят, просто участвуют чтобы послу- шать что скажут другие. Большое количество времени людей тратится чтобы получить небольшое количество коммуникации. Поэтому участие всех людей в собраниях уводит ресурсы из проекта и создает хаос в планировании. Для такого рода коммуникаций и нужно собрание стоя. Намного лучше иметь одно короткое обязательное собрание, чем множество длинных на которых большинство разработчиков должно все равно присутствовать. Если у вас проводятся ежедневные собрания стоя, то все остальные собрания должны посещать только те люди, которые необходимы и будут что-либо привносить. Более того, имеется возможность даже избежать некоторых собраний. С ограничением участников, большинство собраний может быть проведено спонтанно перед монитором, где обмен идеями намного более интенсивен. Ежедневное утреннее собрание это не еще одна трата времени. Оно позволит вам избежать многих других собраний и сэкономит больше времени, чем на него затрачено. Метафора Системы Всегда выбирайте System Metaphor - простую и понятную концепцию чтобы члены команды назы- вали все вещи одинаковыми именами. Для понимания системы и исключения дублирующего кода чрезвычайно важно как вы называете объекты. Если вы можете предположить как называется какой- либо объект в системе (если вы знаете что он делает) и он правда так называется - вы сохраните уйму времени и сил. Создайте систему имен для своих объектов так, чтобы каждый член команды мог пользоваться ею без специальных знаний о системе. Unit Test-ы Unit тесты играют ключевую роль в XP. Они позволяют быстро менять код не боясь наделать новых ошибок. Unit тест пишется для каждого класса, тест должен проверять все аспекты работы класса - тестировать все что может не работать. Хитростью здесь является то, что тест для класса должен быть написан раньше самого класса. Это значит, что как только вы выпустите первый работающий результат, он будет поддерживаться системой тестирования. Для проведения тестов пишется специальная система тестирования со своим интерфейсом. Unit тест для класса хранится в общем репозитории вместе с кодом класса. Никакой код не может быть выпущен без Unit теста. Перед отдачей кода разработчик должен удостовериться что все тесты проходят без ошибок. Никто не может отдать код, если все не прошли 100%. Другими словами поскольку до ваших изменений все тесты проходили, то если вы имеете ошибки, то это результат ваших изменений. Вам и исправлять. Иногда бывает неправильным или неполным код теста. В таком случае надо исправлять его. Огромным искушением является сэкономить на Unit тестах когда мало времени. Но этим Вы только обманываете себя. Чем сложнее написать тест, тем больше времени он потом сэкономит. Это доказано практикой. Unit тесты позволяют осуществить коллективное владение кодом. Они позволяют относительно легко пересматривать плохой код. Также Unit тесты позволяют в любой момент иметь стабильно работающую систему. User Story User Story (что-то типа рассказа пользователя) - это описание того как система должна работать. Каждая User Story написана на карточке и представляет какой-то кусок функциональности системы, имеющий логический смысл с точки зрения Заказчика. Форма - один-два абзаца текста понятного пользователю (не сильно технического). User Story пишется Заказчиком. Они похожи на сценарии использования системы, но не огра- ничиваются пользовательским интерфейсом. По каждой истории пишутся функциональные тесты, подтверждающие что данная история корректно реализована - их еще называют приемочными (Acceptance tests). Каждой User Story дается приоритет со стороны бизнеса (пользователь, заказ- чик, отдел маркетинга) и оценка времени выполнения со стороны разработчиков. Каждая история разбивается на задачи и ей назначается время когда ее начнут реализовывать. User Stories используются в XP вместо традиционных требований. Главное отличие User Story от требований (requirements) - уровень детализации. User Story содержит минимум информации, необходимой для обоснованной оценки того, сколько времени надо на ее реализацию. Типичная User Story занимает 1-3 недели идеального времени. История требующая менее 1 неде- ли слишком детализирована. История требующая более 3 недель может быть разбита на части - отдельные истории. Скорость проекта Скорость Проекта (или просто скорость) это мера того, как быстро выполняется работа в вашем проекте. Чтобы измерить скорость проекта, вы просто должны посчитать объем User Stories, или как много (по времени) задач было выполнено за итерацию. Просто посчитайте суммарное время оценки объема работы (идеальное время). Во время планирования релиза скорость проекта используется для оценки того сколько User Stories может быть сделано. Во время планирования итерации, скорость проекта в предыдущей итерации используется для определения того сколько User Stories надо планировать в текущую итерацию. Этот простой механизм позволяет разработчикам восстановиться после трудной итерации. Если у вас после восстановления остается свободное время - идете к заказчику и просите еще User Story. В результате скорость опять возрастет. Не надо использовать этот параметр как абсолютный. Он не подходит для сравнения продуктивно- сти двух проектов, поскольку каждая команда имеет свои особенности. Этот параметр важен только для команды чтобы держать ее на "ровном киле". Вы должны ожидать небольшие изменения скорости проекта во время работы. Но если скорость изменяется сильно, необходимо провести перепланирование релиза. Как только новая система уходит к пользователям, ожидайте изменения скорости проекта, так как у вас появятся задачи по поддержке. Когда обнаружена ошибка Если обнаруживается ошибка, то создается тест, чтобы предотвратить ее повторное появление. Ошибка, произошедшая в рабочей системе (уже установленной), требует написания функционально- го теста. Создание функционального теста непосредственно перед диагностикой ошибки позволяет заказчикам четко описать проблему и довести эту проблему до разработчиков. Не выполнившийся функциональный тест требует создания Unit Test. Это помогает сфокусировать усилия по отладке и четко показывает когда ошибка исправлена. Вам это не понадобится Воздержитесь от заполнения системы вещами, которые понадобятся вам в будущем. Только 10% от ожидаемого действительно понадобится вам в первоначальном виде, то есть 90% вашего времени будет потрачено впустую. Всегда есть искушение добавить функциональность сейчас а не потом, потому что мы видим как сейчас добавить ее и чувствуем что система будет намного лучше. Но мы всегда должны напоми- нать себе что это нам никогда не понадобится. Дополнительная функциональность только замедляет прогресс и съедает ресурсы. Забудьте про будущие требования и дополнительную гибкость. Скон- центрируйтесь на том, что необходимо сделать сейчас. Контрольные вопросы 1. Какие из перечисленных действий являются стадиями создания ИС? Проведение научно-исследовательских работ Разработка технического задания Обследование объекта Формирование требований к ИС 2. Какие из указанных этапов создания ИС входят в стадию технического проектирования? Разработка предварительных проектных решений по системе и её частям Разработка и адаптация программ Разработка и оформление документации на поставку комплектующих изделий Разработка проектных решений по системе и её частям 3. На какой стадии создания ИС осуществляется разработка и адаптация программ? Эскизного проектирования Технического проектирования Разработки рабочей документации 4. Какие из перечисленных показателей отражаются в схеме маршрута движения документов? Действующие алгоритмы расчета показателей и возможные методы контроля Количество документов Действующие средства связи Место формирования показателей документа 5. В каком разделе технического задания указываются требуемые значения производственно-экономических показателей объекта, которые должны быть достигнуты при внедрении ИС? Требования к системе Назначение и цели создания (развития) системы Характеристика объектов автоматизации 6. В каком разделе технического проекта приводится обоснование выделения подсистем ИС? Постановка задач и алгоритмы решения Функциональная и организационная структура системы Пояснительная записка 7. Сформулируйте цель методологии проектирования ИС Формирование требований, направленных на обеспечение возможности комплексного исполь- зования корпоративных данных в управлении и планировании деятельности предприятия Автоматизация ведения бухгалтерского аналитического учета и технологических процессов Регламентация процесса проектирования ИС и обеспечение управления этим процессом с тем, чтобы гарантировать выполнение требований как к самой ИС, так и к характеристикам процесса разработки 8. Решение каких задач обеспечивается внедрением методологии проектирования ИС? Обеспечить нисходящее проектирование ИС (проектирование «сверху-вниз», в предположе- нии, что одна программа должна удовлетворять потребности многих пользователей) Гарантировать создание системы с заданным качеством в заданные сроки и в рамках уста- новленного бюджета проекта Обеспечить удобную дисциплину сопровождения, модификации и наращивания системы 9. Укажите составляющие этапа проектирования ИС. + Проектирование объектов данных Спецификация требований к приложениям Выбор архитектуры ИС Разработка программного кода приложений Инсталляция базы данных 10. К какому классу ТПР относится используемая в ИС СУБД? Элементные ТПР Подсистемные ТПР Объектные ТПР 11. Что отражают бизнес-правила при модельно-ориентированном проектировании? Выполнение работ для модели бизнес-функций Условия корректности совместного применения различных компонентов ИС и используются для поддержания целостности создаваемой системы.(формулировка не соответствует вопросу) 12. Что отражает модель функций при модельно-ориентированном проектировании? Иерархическую декомпозицию функциональной деятельности предприятия Иерархическую структуру подчинения подразделений и персонала Набрано баллов |