Вопросы к лекциям Инчура В.А. Техническая документация информационных систем
 Скачать 24.48 Kb.
|
|
Вопросы к лекциям: ТЕХНИЧЕСКАЯ ДОКУМЕНТАЦИЯ ИНФОРМАЦИОННЫХ СИСТЕМ 1. Что такое нормативно-методическое обеспечение? Нормативно-методическое обеспечение – это совокупность документов организационного, организационно - методического, организационно - распорядительного, технического, технико-экономического и экономического характера, а также нормативно - справочные материалы и прочие документы, утверждённые в установленном порядке компетентными органами или руководством организации. 2. Каково основной назначение технической документации информационных систем? Основным назначением технической документации является обеспечение эффективных процедур разработки и использования информационной системы как программного продукта, а также организация обмена между разработчиками и пользователями ИС. 3. Каковы функции технической документации? дает описание возможностей системы обеспечивает фиксацию принятых и реализованных проектных решений определяет условия функционирования ИС предоставляет информацию об эксплуатации и обслуживании ИС регламентирует процедуру защиты информации, регулирует права различных групп пользователей определяет возможности модернизации системы 4. В чьи обязанности входят работы по документированию информационной системы? обязанности по документированию системы лежат на ее разработчике; Для повышения эффективности работы с документами должны использоваться стандарты, регламентирующие форму и содержание документов. Исходя из последнего требования к документации, необходимо рассмотреть основные стандарты, которые используются в области информационных систем на территории Российской Федерации. СТАНДАРТЫ В ОБЛАСТИ ИНФОРМАЦИОННЫХ СИСТЕМ 5. Что такое стандарты «де-факто»? Стандартами «де-факто» являются официально никем не утвержденные, но фактически действующие стандарты (таким долгое 14 время был SQL и язык программирования С), а также фирменные стандарты (Microsoft ODBC, IBM SNA). 6. Что такое корпоративные стандарты? Для большинства сложных проектов приходится создавать свои комплексы нормативных и методических документов, регламентирующих процессы, этапы, работы и документы конкретных программных продуктов. Такие стандарты называют корпоративными и представляют собой соглашение о единых правилах организации технологии или управления в организации. За основу корпоративных стандартов могут приниматься отраслевые, национальные или международные стандарты. Сюда 16 могут относиться различные методические материалы ведущих фирмразработчиков ПО, научных центов, фирм-консультантов, консорциумов по стандартизации. 7. Что устанавливает стандарт проектирования? набор необходимых моделей (диаграмм) на каждой стадии проектирования и степень их детализации; правила именования объектов, оформления диаграмм, включая требования к форме и размерам объектов и т. д. требования к конфигурации рабочих мест разработчиков, включая настройки операционной системы; правила интеграции подсистем проекта, правила поддержания проекта в одинаковом для всех разработчиков состоянии, правила проверки проектных решений на непротиворечивость. 8. Что определяет международный стандарт ISO/IEC 12207? В стандарте ISO/IEC 12207 описаны пять основных процессов жизненного цикла программного обеспечения: 1) процесс приобретения определяет действия предприятия - покупателя информационной системы, программного продукта или службы программного обеспечения; 2) процесс поставки определяет действия предприятия-поставщика по снабжению покупателя информационной системой, программным продуктом или службы программного обеспечения ПРОГРАММНЫЕ ДОКУМЕНТЫ ПО ФАЗАМ ЖИЗНЕННОГО ЦИКЛА 10. Что такое жизненный цикл информационной системы? Жизненный цикл информационной системы – это непрерывный процесс, который начинается с момента принятия решения о необходимости создания ИС и заканчивается в момент ее полного изъятия из эксплуатации. 11. Для чего нужно моделирование предметной области? Моделирование предметной области необходимо для выявления, классификации и формализации сведений обо всех аспектах предметной области, определяющих свойства разрабатываемой системы. 12. К какой стадии жизненного цикла относится составление технического задания? Формирование требований к АС 13. Какие работы, согласно ГОСТ34.601-90, включает стадия сопровождения автоматизированной системы? Выполнение работ в соответствии с гарантийными обязательствами Послегарантийное обслуживание ПРЕДПРОЕКТНОЕ ОБСЛЕДОВАНИЕ ОБЪЕКТА АВТОМАТИЗАЦИИ 14. Для чего необходимо предпроектное обследование объекта автоматизации? предварительное обследование (сбор сведений об объекте); анализ сведений (описание и моделирование предметной области); оценка эффективности и целесообразности проекта. 15. Какие документы используют для сбора сведений об объекте? устав и регламенты организации, государственные законы, постановления и другие нормативно-правовые акты 16. Что включает в себя аналитический отчет? Объект, цели исследования и методология проведения работ. Основные конструктивные, технологические и техникоэксплуатационные характеристики. Основные требования пользователя к АС. Степень внедрения и рекомендации по внедрению АС. Область применения АС. Обоснование экономической эффективности создания АС. Прогнозы и предположения о развитии объекта исследования. 17. В каком виде представляется информация в аналитическом отчете? Документы, входящие в аналитический отчет, могут быть представлены в виде текстового описания или таблиц с описанием операций, исполнителей и документов бизнес-процессов. ФОРМИРОВАНИЕ ТРЕБОВАНИЙ К ИНФОРМАЦИОННОЙ СИСТЕМЕ 18. Что такое техническое задание на создание системы? Техническое задание (ТЗ) – исходный документ для проектирования и разработки информационной системы, который содержит основные технические требования, предъявляемые к ИС. 19. Что позволяет техническое задание заказчику и исполнителю как инструмент коммуникации? Как инструмент коммуникации в связке общения заказчик- исполнитель, техническое задание позволяет: обеим сторонам представить готовый продукт; выполнить попунктную проверку готового продукта; уменьшить число ошибок, связанных с изменением требований в результате их неполноты или ошибочности (на всех стадиях и этапах создания, кроме испытаний); заказчику осознать, что именно ему нужно; требовать от исполнителя соответствия продукта всем условиям, оговоренным в ТЗ; исполнителю понять суть задачи, показать заказчику технический облик будущего программного изделия или автоматизированной системы; спланировать выполнение проекта и работать по намеченному плану; отказаться от выполнения работ, не указанных в ТЗ. ЭСКИЗНЫЙ И ТЕХНИЧЕСКИЙ ПРОЕКТЫ 20. Какова основная задача эскизного проекта? Основная задача эскизного проекта – создать прообраз будущей автоматизированной системы. Разработчик определяет основные контуры будущей системы, получает представление об основных чертах будущего объекта автоматизации и анализирует их возможную применимость в последующей работе. 21. Какую информацию содержит документ «Схема организационной структуры»? описание организационной структуры организации, которая будет использовать создаваемую автоматизированную систему в практической работе 22. Что такое «технический проект»? Технический проект – это пакет документации, который описывает окончательные решения по проектированию автоматизированной системы. 23. На основании чего составляется технический проект? Технический проект составляется на основании требований технического задания по определенным стадиям. Сначала проходит составление общего проекта, а на его основании составляются технические проекты первой и второй очереди. Причем работы по разработке документов первой и второй очереди могут вестись независимо друг от друга. СПЕЦИФИКАЦИЯ 24. Что такое спецификация программы? Спецификация программы – это описание задачи, которую решает программа. Слово «спецификация» буквально означает «описание» или «получение описания», а «специфицировать» значит «описывать». Спецификация – это задание для программиста, написанное постановщиком задачи. Она служит основой дальнейшей детализации и разработки. 25. В чем различие между функциональной и эксплуатационной спецификациями? Функциональная спецификация. Она описывает функции программы, решающей задачу (разбиение задачи на подзадачи, входные и выходные данные, связи между ними, процессы и действия, реакции на исключительные ситуации и т. д.). Эксплуатационная спецификация. Она касается таких аспектов, как скорость работы программы или используемые ею ресурсы, характеристики аппаратуры, на которой она должна работать, специальные требования к надежности и безопасности и т. д. 26. Какие разделы должна содержать спецификация? Введение, Общее описание, Требования, Специальные требования, Модели РАБОЧАЯ ДОКУМЕНТАЦИЯ 27. Для чего необходимо руководство пользователя? Основной целью руководства пользователя является обеспечение пользователя необходимой информацией для самостоятельной работы с программой или автоматизированной системой. 28. Чем руководство оператора отличается от руководства пользователя? Роль оператора по своим функциям ближе всего к роли пользователя, однако, отличается от нее тем, что перед оператором не ставятся прикладные задачи, которые он может решить с помощью программы тем или иным способом, в том или ином порядке. 29. Что включает в себя руководство программиста? назначение и условия применения программы (назначение и функции, выполняемые программой, объем оперативной памяти, требования к составу и параметрам периферийных устройств, требования к программному обеспечению и т. п.); характеристики программы (временные характеристики, режим работы, средства контроля правильности выполнения и самовосстанавливаемости программы и т. п.); обращение к программе (описание процедур вызова программы, способы передачи управления и параметров данных и др.); входные и выходные данные (описание организации используемой входной и выходной информации и, при необходимости, ее кодирования); сообщения (тексты сообщений, выдаваемых программисту или оператору в ходе выполнения программы, описание их содержания и действия, которые необходимо предпринять по этим сообщениям). ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ 30. Из каких процессов состоит жизненный цикл программного обеспечения? Процесса планирования. Процесса разработки, который включает: * процесс определения требований к ПО; * процесс проектирования ПО; * процесс кодирования ПО; * процесс интеграции. Интегральных процессов, к которым относятся: * процесс верификации ПО; * процесс управления конфигурацией ПО; * процесс обеспечения качества ПО; * процесс сертификационного сопровождения. 31. Что содержит план обеспечения качества ПО? План разработки ПО содержит описание целей, стандартов и моделей ЖЦ ПО, которые должны быть использованы в процессах разработки ПО. 32. Что включает в себя итоговый документ разработки ПО? Итоговый документ разработки ПО – основной документ по демонстрации соответствия Плану сертификации в части ПО. Этот документ должен содержать следующие разделы: Краткий обзор системы. Данный раздел содержит краткий обзор системы, включая описание ее функций и их распределение на программную и аппаратную реализацию, архитектуру, используемые процессоры, интерфейсы аппаратных средств/ПО, требования по обеспечению безопасности. Этот раздел также описывает все отличия от краткого обзора системы в Плане сертификации в части ПО. Краткий обзор ПО. Этот раздел кратко описывает функции ПО с акцентированием на обеспечении безопасности и используемой концепции разбиения и объясняет отличия от краткого обзора ПО в Плане сертификации в части ПО. Вопросы сертификации. Этот раздел вновь рассматривает вопросы сертификации, определенные в Плане сертификации в части ПО, и объясняет все существующие от указанного плана отличия. Характеристики ПО. В этом разделе указаны размер исполняемого объектного кода, ограничения по времени и памяти, ограничения ресурсов и способы измерения каждой характеристики. Жизненный цикл ПО. Этот раздел описывает фактически используемую модель жизненного цикла ПО и объясняет ее отличия от предложенной в Плане сертификации в части ПО. Документы жизненного цикла ПО. В этом разделе даны ссылки на документы жизненного цикла ПО, являющиеся выходными результатами процессов разработки ПО и интегральных процессов. Здесь описаны связь между представляемыми документами и другими документами, определяющими систему, а также способы передачи документов жизненного цикла ПО сертифицирующей организации. В этом разделе также рассмотрены любые отклонения в описании документов от Плана сертификации в части ПО. Идентификация ПО. Этот раздел идентифицирует конфигурацию ПО посредством указания регистрационного номера и версии. Хронология изменения. В случае необходимости этот раздел включает в себя резюме изменений ПО с указанием изменений, вызванных отказами, влияющими на безопасность, и идентификацией изменений, выполненных после предыдущей сертификации. Текущее состояние ПО. Этот раздел содержит резюме сообщений о дефектах, не устраненных ко времени сертификации, включая заявления о функциональных ограничениях. Утверждение о соответствии. Этот раздел включает в себя утверждение о соответствии требованиям стандарта ГОСТ Р 51904 и резюме методов, позволяющих показать выполнение критериев, определенных в планах ПО. Этот раздел также указывает дополнительные соглашения и отклонения от требований планов, стандартов разработки и настоящего стандарта. 33. Что определяет план передачи ПО? План передачи ПО определяет аппаратное и программное обеспечение, а также другие ресурсы, необходимые для поддержки жизненного цикла передаваемого ПО, и описывает планы разработчиков для поставки передаваемых элементов через организации, осуществляющие поддержку. Данный план разрабатывают в том случае, если используют концепцию передачи ПО отдельной организации, осуществляющей поддержку. 34. Для чего необходим план установки ПО? План установки ПО содержит описание работ для установки ПО на пользовательских местах, включая подготовку, обучение пользователей и адаптацию существующих систем. Данный план необходим, когда разработчик должен выполнить установку ПО на пользовательских местах и когда процесс установки ПО настолько сложен, что без оформленного в виде документа плана обойтись невозможно. |