• Название:

    пис 2011

  • Размер: 10.94 Мб
  • Формат: PDF
  • или
  • Сообщить о нарушении/Abuse

    ВСЕ МОЛОДЧИКИ! - 22й не готов - там бред!
    Вопросы и ответы для сдачи экзамена
    информационных систем (4 июня 2011)
    Постарайтесь следить за форматированием текста.
    И отмечать, что уже сделано жирным в списке вопросов.

    Распределение вопросов среди студентов
    1. Сергей Шибалов 1-3
    2. Артем Петров 4-6
    3. Олег Бердников 7-9
    4. Михаил Пантелеев 10,11
    5. Ира Савельева 13-15
    6. Ира Игнатьева - Забила болт Отчислена(16-18)
    6. Жуков Сергей - 16, 17
    6. Ася - 18
    7. Аня Иванова 19-21
    8. Паша Варченко 22-24
    9. Саша Сапыгин 25 26 27
    10. Ксюша Горбунова
    11. Лавров Виктор 28, 29, 31
    12. Александр Плетнев 32-33, 12,30

    Коротко про этапы построения ИС, не помню, в какой вопрос
    http://www.prj-exp.ru/dwh/stages_of_model_development.php
    Еще одна очень полезная ссылка про проектирование

    Вопросы и ответы
    1.Жизненный цикл информационной системы. ГОСТ 51 904.

    по

    предмету

    Проектирование

    2.Модели жизненного цикла информационной системы. ГОСТ 15 271.

    Модели жизненного цикла ПО :
    Каскадная модель
    Каскадная модель жизненного цикла («модель водопада», англ. waterfall model) была предложена в 1970
    г. Уинстоном Ройсом. Она предусматривает последовательное выполнение всех этапов проекта в строго
    фиксированном порядке. Переход на следующий этап означает полное завершение работ на предыдущем
    этапе. Требования, определенные на стадии формирования требований, строго документируются в виде
    технического задания и фиксируются на все время разработки проекта. Каждая стадия завершается выпуском
    полного комплекта документации, достаточной для того, чтобы разработка могла быть продолжена другой
    командой разработчиков.
    Этапы проекта в соответствии с каскадной моделью:

    1.

    Формирование требований;

    2.

    Проектирование;

    3.

    Реализация;

    4.

    Тестирование;

    5.

    Внедрение;

    6.

    Эксплуатация и сопровождение.

    Ее плюсы:
    1.

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

    2.

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

    Минусы:
    Основным недостатком каскадного подхода является существенное запаздывание с получением результатов.
    Согласование результатов с пользователями производится только в точках, планируемых после завершения
    каждого этапа работ, требования к ИС "заморожены" в виде технического задания на все время ее создания.
    Таким образом, пользователи могут внести свои замечания только после того, как работа над системой будет
    полностью завершена. В случае неточного изложения требований или их изменения в течение длительного
    периода создания ПО, пользователи получают систему, не удовлетворяющую их потребностям. Модели (как
    функциональные, так и информационные) автоматизируемого объекта могут устареть одновременно с их
    утверждением.
    Спиральная модель
    Спиральная модель (англ. spiral model) была разработана в середине 1980-х годов Барри Боэмом. Она основана
    на классическом цикле Деминга PDCA (plan-do-check-act). При использовании этой модели ПО создается в
    несколькоитераций (витков спирали) методом прототипирования.
    Каждая итерация соответствует созданию фрагмента или версии ПО, на ней уточняются цели и
    характеристики проекта, оценивается качество полученных результатов и планируются работы следующей
    итерации.
    На каждой итерации оцениваются:
    1.
    риск превышения сроков и стоимости проекта;
    2.
    необходимость выполнения ещё одной итерации;
    3.
    степень полноты и точности понимания требований к системе;
    4.
    целесообразность прекращения проекта.
    Один из примеров реализации спиральной модели — RAD (англ. Rapid Application Development, метод
    быстрой разработки приложений).

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

    Итеративная и инкрементальная модель
    Итеративная модель предполагает разбиение жизненного цикла проекта на последовательность итераций,
    каждая из которых напоминает “мини-проект”, включая все фазы жизненного цикла в применении к созданию меньших
    фрагментов функциональности, по сравнению с проектом, в целом. Цель каждой итерации – получение работающей
    версии программной системы, включающей функциональность, определенную интегрированным содержанием всех
    предыдущих и текущей итерации. Результата финальной итерации содержит всю требуемую функциональность
    продукта. Таким образом, с завершением каждой итерации,продукт развивается инкрементально.
    С точки зрения структуры жизненного цикла такую модель называют итеративной (iterative). С точки зрения
    развития продукта – инкрементальной (incremental). Опыт индустрии показывает, что невозможно рассматривать каждый
    из этих взглядов изолировано. Чаще всего такую смешанную эволюционную модельназывают просто итеративной (говоря
    о процессе) и/или инкрементальной (говоря о наращивании функциональности продукта).
    Эволюционная модель подразумевает не только сборку работающей (с точки зрения результатов тестирования)
    версии системы, но и её развертывание в реальных операционных условиях с анализом откликов пользователей для
    определения содержания и планирования следующей итерации. “Чистая” инкрементальная модель не предполагает
    развертывания промежуточных сборок (релизов) системы и все итерации проводятся по заранее определенному
    плану наращивания функциональности, а пользователи (заказчик) получает только результат финальной итерации
    как полную версию системы. С другой стороны, Скотт Амблер [Ambler, 2004], например, определяет эволюционную
    модель как сочетание итеративного и инкрементального подходов. В свою очередь, Мартин Фаулер [Фаулер, 2004, с.47]

    пишет: “Итеративную разработку называют по-разному: инкрементальной, спиральной, эволюционной и постепенной.
    Разные люди вкладывают в эти термины разный смысл, но эти различия не имеют широкого признания и не так важны,
    как противостояние итеративного метода и метода водопада.”
    Брукс пишет [Брукс, 1995, с.246-247], что, в идеале, поскольку на каждом шаге мы имеем работающую систему:




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

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

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

    3.Методологии проектирования. Каноническое проектирование. ГОСТ 34.601-90.
    Проектирование информационных систем
    Каноническое проектирование ИС
    Организация канонического проектирования ИС ориентирована на использование главным образом каскадной
    модели жизненного цикла ИС. Стадии и этапы работы описаны в стандарте ГОСТ 34.601-90.
    В зависимости от сложности объекта автоматизации и набора задач, требующих решения при создании
    конкретной ИС, стадии и этапы работ могут иметь различную трудоемкость. Допускается объединять
    последовательные этапы и даже исключать некоторые из них на любой стадии проекта. Допускается также
    начинать выполнение работ следующей стадии до окончания предыдущей.
    Стадии и этапы создания ИС, выполняемые организациями-участниками, прописываются в договорах и
    технических заданиях на выполнение работ:
    Стадия 1. Формирование требований к ИС.
    На начальной стадии проектирования выделяют следующие этапы работ:
    обследование объекта и обоснование необходимости создания ИС;
    формирование требований пользователей к ИС;
    оформление отчета о выполненной работе и тактико-технического задания на разработку.
    Стадия 2. Разработка концепции ИС.
    изучение объекта автоматизации;
    проведение необходимых научно-исследовательских работ;
    разработка вариантов концепции ИС, удовлетворяющих требованиям пользователей;
    оформление отчета и утверждение концепции.
    Стадия 3. Техническое задание.
    разработка и утверждение технического задания на создание ИС.
    Стадия 4. Эскизный проект.
    разработка предварительных проектных решений по системе и ее частям;
    разработка эскизной документации на ИС и ее части.
    Стадия 5. Технический проект.
    разработка проектных решений по системе и ее частям;
    разработка документации на ИС и ее части;
    разработка и оформление документации на поставку комплектующих изделий;
    разработка заданий на проектирование в смежных частях проекта.
    Стадия 6. Рабочая документация.

    разработка рабочей документации на ИС и ее части;
    разработка и адаптация программ.
    Стадия 7. Ввод в действие.
    подготовка объекта автоматизации;
    подготовка персонала;
    комплектация ИС поставляемыми изделиями (программными и техническими средствами, программнотехническими комплексами, информационными изделиями);
    строительно-монтажные работы;
    пусконаладочные работы;
    проведение предварительных испытаний;
    проведение опытной эксплуатации;
    проведение приемочных испытаний.
    Стадия 8. Сопровождение ИС.
    выполнение работ в соответствии с гарантийными обязательствами;
    послегарантийное обслуживание.
    Oбследование- это изучение и диагностический анализ организационной структуры предприятия, его
    деятельности и существующей системы обработки информации.Материалы, полученные в результате
    обследования, используются для:
    обоснования разработки и поэтапного внедрения систем;
    составления технического задания на разработку систем;
    разработки технического и рабочего проектов систем.
    На этапе обследования целесообразно выделить две составляющие: определение стратегии внедрения ИС и
    детальный анализ деятельности организации.
    Основная задача первого этапа обследования - оценка реального объема проекта, его целей и задач на
    основе выявленных функций и информационных элементов автоматизируемого объекта высокого уровня.
    Эти задачи могут быть реализованы или заказчиком ИС самостоятельно, или с привлечением консалтинговых
    организаций. Этап предполагает тесное взаимодействие с основными потенциальными пользователями
    системы и бизнес-экспертами. Основная задача взаимодействия - получить полное и однозначное понимание
    требований заказчика. Как правило, нужная информация может быть получена в результате интервью, бесед
    или семинаров с руководством, экспертами и пользователями.
    По завершении этой стадии обследования появляется возможность определить вероятные технические
    подходы к созданию системы и оценить затраты на ее реализацию (затраты на аппаратное обеспечение,
    закупаемое программное обеспечение и разработку нового программного обеспечения ).
    Результатом этапа определения стратегии является документ (технико-экономическое обоснование проекта),
    где четко сформулировано, что получит заказчик, если согласится финансировать проект, когда он получит
    готовый продукт (график выполнения работ) и сколько это будет стоить (для крупных проектов должен быть
    составлен график финансирования на разных этапах работ). В документе желательно отразить не только

    затраты, но и выгоду проекта, например время окупаемости проекта, ожидаемый экономический эффект (если
    его удается оценить).
    Ориентировочное содержание этого документа:
    ограничения, риски, критические факторы, которые могут повлиять на успешность проекта;
    совокупность условий, при которых предполагается эксплуатировать будущую систему: архитектура системы,
    аппаратные и программные ресурсы, условия функционирования, обслуживающий персонал и пользователи
    системы;
    сроки завершения отдельных этапов, форма приемки/сдачи работ, привлекаемые ресурсы, меры по защите
    информации;
    описание выполняемых системой функций;
    возможности развития системы;
    информационные объекты системы;
    интерфейсы и распределение функций между человеком и системой;
    требования к программным и информационным компонентам ПО, требования к СУБД;
    что не будет реализовано в рамках проекта.
    На этапе детального анализа деятельности организации изучаются задачи, обеспечивающие реализацию
    функций управления, организационная структура, штаты и содержание работ по управлению предприятием, а
    также характер подчиненности вышестоящим органам управления. На этом этапе должны быть выявлены:
    инструктивно-методические и директивные материалы, на основании которых определяются состав подсистем
    и перечень задач;
    возможности применения новых методов решения задач.
    Аналитики собирают и фиксируют информацию в двух взаимосвязанных формах:
    функции - информация о событиях и процессах, которые происходят в бизнесе;
    сущности - информация о вещах, имеющих значение для организации и о которых что-то известно.
    При изучении каждой функциональной задачи управления определяются:
    наименование задачи; сроки и периодичность ее решения;
    степень формализуемости задачи;
    источники информации, необходимые для решения задачи;
    показатели и их количественные характеристики;
    порядок корректировки информации;
    действующие алгоритмы расчета показателей и возможные методы контроля;
    действующие средства сбора, передачи и обработки информации;
    действующие средства связи;
    принятая точность решения задачи;
    трудоемкость решения задачи;
    действующие формы представления исходных данных и результатов их обработки в виде документов;
    потребители результатной информации по задаче.
    Одной из наиболее трудоемких, хотя и хорошо формализуемых задач этого этапа является описание
    документооборота организации. При обследовании документооборота составляется схема маршрута

    движения документов, которая должна отразить:
    количество документов;
    место формирования показателей документа;
    взаимосвязь документов при их формировании;
    маршрут и длительность движения документа;
    место использования и хранения данного документа;
    внутренние и внешние информационные связи;
    объем документа в знаках.
    По результатам обследования устанавливается перечень задач управления, решение которых целесообразно
    автоматизировать, и очередность их разработки.
    На этапе обследования следует классифицировать планируемые функции системы по степени важности.
    Один из возможных форматов представления такой классификации - MuSCoW [9].
    Эта аббревиатура расшифровывается так: Must have - необходимые функции; Should have - желательные
    функции; Could have - возможные функции; Won't have - отсутствующие функции.
    Функции первой категории обеспечивают критичные для успешной работы системы возможности.
    Реализация функций второй и третьей категорий ограничивается временными и финансовыми рамками:
    разрабатывается то, что необходимо, а также максимально возможное в порядке приоритета число функций
    второй и третьей категорий.
    Последняя категория функций особенно важна, поскольку необходимо четко представлять границы проекта и
    набор функций, которые будут отсутствовать в системе.
    Модели деятельности организации создаются в двух видах:
    модель "как есть"("as-is")- отражает существующие в организации бизнес-процессы;
    модель "как должно быть"("to-be") - отражает необходимые изменения бизнес-процессов с учетом внедрения
    ИС.
    На этапе анализа необходимо привлекать к работе группы тестирования для решения следующих задач:
    получения сравнительных характеристик предполагаемых к использованию аппаратных платформ,
    операционных систем, СУБД, иного окружения;
    разработки плана работ по обеспечению надежности информационной системы и ее тестирования.
    Привлечение тестировщиков на ранних этапах разработки является целесообразным для любых проектов.
    Если проектное решение оказалось неудачным и это обнаружено слишком поздно (на этапе разработки или,
    что еще хуже, на этапе внедрения в эксплуатацию), то исправление ошибки проектирования обходится очень
    дорого. Чем раньше группы тестирования выявляют ошибки в информационной системе, тем ниже стоимость
    сопровождения системы. Время на тестирование системы и на исправление обнаруженных ошибок следует
    предусматривать не только на этапе разработки, но и на этапе проектирования.

    Для автоматизации тестирования следует использовать системы отслеживания ошибок (bug tracking). Это
    позволяет иметь единое хранилище ошибок, отслеживать их повторное появление, контролировать скорость
    и эффективность исправления ошибок, видеть наиболее нестабильные компоненты системы, а также
    поддерживать связь между группой разработчиков и группой тестирования (уведомления об изменениях по email и т.п.). Чем больше проект, тем сильнее потребность в bug tracking.
    Результаты обследования представляют объективную основу для формирования технического задания на
    информационную систему.
    Техническое задание- это документ, определяющий цели, требования и основные исходные данные,
    необходимые для разработки автоматизированной системы управления.
    При разработке технического задания необходимо решить следующие задачи:
    установить общую цель создания ИС, определить состав подсистем и функциональных задач;
    разработать и об