Проектирование информационных систем

Курс Лекций (На другой странице)

Шпаргалка (На другой странице)

Ответы на вопросы (Структурировано)

Неструктурированное

Наше

ERP Система планирования ресурсов предприятия — это интегрированная система на базе ИТ для управления внутренними и внешними ресурсами предприятия (значимые физические активы, финансовые, материально-технические и человеческие ресурсы). Цель системы — содействие потокам информации между всеми хозяйственными подразделениями (бизнес-функциями) внутри предприятия и информационная поддержка связей с другими предприятиями. Построенная, как правило, на централизованной базе данных, ERP-система формирует стандартизованное единое информационное пространство предприятия[1].
CRM Система управления взаимоотношениями с клиентами (CRM, CRM-система, сокращение от англ. Customer Relationship Management — прикладное программное обеспечение для организаций, предназначенное для автоматизации стратегий взаимодействия с заказчиками, в частности, для повышения уровня продаж, оптимизации маркетинга и улучшения обслуживания клиентов путём сохранения информации о клиентах и истории взаимоотношений с ними, установления и улучшения бизнес-процедур и последующего анализа результатов.
Процесс последовательная смена состояний чего-либо, стадий развития рассматриваемого явления, а также определённая совокупность последовательных действий, направленных на достижение некоторой цели. Бизнес-процесс — это совокупность взаимосвязанных мероприятий или задач, направленных на создание определенного продукта или услуги для потребителей. Для наглядности бизнес-процессы визуализируют при помощи блок-схемы бизнес-процессов.
Миссия организации основная цель организации, высшее понятие в иерархии целей. Миссия недостижима – это не цель, а высшее предназначение существования компании, что и определяет отсутствие возможности ее достижения.
Жизненный цикл период времени, который начинается с момента принятия решения о необходимости создания программного продукта и заканчивается в момент его полного изъятия из эксплуатации[1]. Этот цикл — процесс построения и развития ПО.
Информационная система подмножество компонентов ИС в широком смысле, включающее базы данных, СУБД и специализированные прикладные программы. ИС в узком смысле рассматривают как программно-аппаратную систему, предназначенную для автоматизации целенаправленной деятельности конечных пользователей, обеспечивающую, в соответствии с заложенной в нее логикой обработки, возможность получения, модификации и хранения информации. Основной задачей ИС является удовлетворение конкретных информационных потребностей в рамках конкретной предметной области. Современные ИС де-факто немыслимы без использования баз данных и СУБД, поэтому термин «информационная система» на практике сливается по смыслу с термином «система баз данных».
Экономическая информационная система – ИС, предназначенная для выполнения функций управления на предприятии.
MuSCoWметод расстановки приоритетов, используемый в бизнес-анализе и разработке программного обеспечения, для достижения заинтересованными сторонами взаимного понимания важности, которую они придают каждому требованию — также известному как приоритезация MoSCoW или анализ MoSCoW. Заглавные буквы в акрониме MoSCoW означают:
1. M — должен сделать это (англ. — «MUST have this.»)
2. S — должен сделать это, если это вообще возможно (англ. — «SHOULD have this if at all possible.»)
3. C — мог бы сделать это, если это не повлияет отрицательно на что-то другое (англ. — «COULD have this if it does not affect anything else.»)
4. W — не будет достаточно времени на это, но в будущем хотелось бы. Или хочу. (англ. — «WON’T have this time but WOULD like in the future. Alternatively WANT.»)
Процессная потоковая модель это модели, описывающие процесс последовательного во времени преобразования материальных и информационных потоков компании в ходе реализации какой-либо бизнес-функции или функции менеджмента. На верхнем уровне описывается логика взаимодействия участников процесса, на нижнем — технология работы отдельных специалистов на своих рабочих местах. Процессные потоковые модели отвечают на вопросы кто—что—как—кому
Нотация система условных обозначений, принятая в какой-либо области знаний или деятельности. Нотация включает множество символов используемых для представления понятий и их взаимоотношений, составляющее алфавит нотации, а также правила их применения. Пример: различные системы счисления
Декомпозиция научный метод, использующий структуру задачи и позволяющий заменить решение одной большой задачи решением серии меньших задач.
Техническое задание исходный документ для проектирования сооружения, разработки информационных систем. ТЗ содержит основные технические требования, предъявляемые к сооружению, изделию или услуге и исходные данные для разработки. В ТЗ указываются назначение объекта, область его применения, стадии разработки документации, её состав, сроки исполнения и т. д., а также особые требования, обусловленные спецификой самого объекта либо условиями его эксплуатации. Как правило, ТЗ составляют на основе анализа результатов предварительных исследований, расчётов и моделирования. «Техническое задание — исходный документ определяющий порядок и условия проведения работ по Договору, содержащий цель, задачи, принципы выполнения, ожидаемые результаты и сроки выполнения работ».
Классификатор систематизированный перечень наименованных объектов, каждому из которых в соответствие дан уникальный код. Классификация объектов производится согласно правилам распределения заданного множества объектов на подмножества (классификационные группировки) в соответствии с установленными признаками их различия или сходства. Применяется в Автоматизированных системах управления и обработке информации. Классификатор является стандартным кодовым языком документов, финансовых отчётов и автоматизированных систем.
Модель «as is» модель существующего состояния организации – позволяет систематизировать протекающие в данный момент процессы, а также используемые информационные объекты. На основе этого выявляются узкие места в организации и взаимодействии бизнес-процессов, определяется необходимость тех или иных изменения в существующей структуре.
Модель «to be» Найденные в модели AS-IS недостатки исправляются путем создания модели ТО-ВЕ (как будет), т.е. модели новой организации процессов на предприятии.
Методология проектирования это поиск способа, который удовлетворяет требованиям функциональности системы средствами имеющихся технологий с учетом заданных ограничений.
Контекстная диаграмма( что и зачем) Контекстная диаграмма является вершиной древовидной структуры диаграмм и представляет собой самое общее описание системы и ее взаимодействия с внешней средой. После описания системы в целом проводится разбиение ее на крупные фрагменты. Этот процесс называется функциональной декомпозицией, а диаграммы, которые описывают каждый фрагмент и взаимодействие фрагментов, называются диаграммами декомпозиции. После декомпозиции контекстной диаграммы проводится декомпозиция каждого большого фрагмента системы на более мелкие и так далее, до достижения нужного уровня подробности описания. После каждого сеанса декомпозиции проводятся сеансы экспертизы — эксперты предметной области указывают на соответствие реальных бизнес-процессов созданным диаграммам.
3х уровневая архитектура клиентское приложение (обычно говорят «тонкий клиент» или терминал), подключенное к серверу приложений, который в свою очередь подключен к серверу базы данных.
Схема маршрута движения документов заранее намеченный или ус-тановл. путь следования документов. Определение М.д.д. является одним из важнейших средств ускорения продвижения документа к потребителю. Различают потоки входящих, исходящих и внутренних документов, для каждого из к-рых создается своя схема движения. Осн. задача рацион, организации М.д.д. состоит в обеспечении оперативного прохождения и обработки документов, их сохранности.
Референтная модель модель эталонного бизнес-процесса для предприятий конкретных отраслей промышленности. Референтные модели, опираясь на опыт лучших внедрений, объединяют в себе схемы оптимальных бизнес-процессов, проверенные и одобренные на практике.
Что такое унифицированная система документации система документации, созданная по единым правилам и требованиям, содержащая информацию, необходимую для управления в определенной сфере деятельности.
Тестирование методом белого ящика– тестирование кода на предмет логики работы программы и корректности её работы с точки зрения компилятора того языка на котором она писалась. Позволяет проверить внутреннюю структуру программы. Исходя из этой стратегии тестировщик получает тестовые данные путем анализа логики работы программы. Методы тестирования:
1. покрытие операторов
2. покрытие решений
3. покрытие условий
4. покрытие решений и условий
5. комбинаторное покрытие условий
Тестирования методом черного ящика тестирование функционального поведения программы с точки зрения внешнего мира (текст программы не используется). Тестировщик знает только набор вводимых параметров и ожидаемые на выходе результаты, каким образом программа достигает этих результатов ему неизвестно. Он никогда не проверяет программный код и не нуждается в дополнительном знании программы кроме как в ее техническом описании.
Эскизный проект Эскизный проект предусматривает разработку предварительных проектных решений по системе и ее частям. Выполнение стадии эскизного проектирования не является строго обязательной. Если основные проектные решения определены ранее или достаточно очевидны для конкретной ИС и объекта автоматизации, то эта стадия может быть исключена из общей последовательности работ.
Матрица проекций в компактной форме фиксирует информацию о том, кто и что делает в организации. Создается «Положение об организационной структуре» – оно фиксирует продукты и услуги компании; функции, выполняемые в компании; исполнительные звенья, реализующие функции; распределение функций по звеньям. Выясняется, сколько функций связано с деятельностью его компании и какие звенья отвечают за то, чтобы это работало. Из двух списков нужно построить матрицу. В строках ее должны находиться исполнительные звенья, в столбцах – функции, которые выполняются в компании. Затем по каждой функции найти исполнительной звено, которое отвечает за эту функцию.
Модель предметной области система, имитирующая структуру или функционирование исследуемой предметной области и отвечающая основному требованию – быть адекватной этой области.

27. Техническая структура Техническая структура предназначена для правильного выбора и размещения технических средств между компонентами ИС – для реализации всех принятых функций и целей ИС и ее компонентов.
28. Физическая модель данных Физические модели данных служат для отображения моделей данных. Основными понятиями модели данных являются поле, логическая запись, логический файл. Слово “логический” введено, чтобы отличать понятия, относящиеся к логической модели данных, от понятий, относящихся к физической модели данных. Основными понятиями физической модели данных, используемыми для представления логической модели данных, являются поле, физическая запись, физический файл. В частности, логическая запись, состоящая из полей, может быть представлена в виде физической записи (из тех же полей), логический файл – в виде физического файла. Прежде чем конкретизировать понятия, относящиеся к физической модели данных, рассмотрим структуру памяти ЭВМ.
29. Логическая модель данных . Слово “логический” введено, чтобы отличать понятия, относящиеся к логической модели данных, от понятий, относящихся к физической модели данных. Основными понятиями физической модели данных, используемыми для представления логической модели данных, являются поле, физическая запись, физический файл. В частности, логическая запись, состоящая из полей, может быть представлена в виде физической записи (из тех же полей), логический файл – в виде физического файла. Прежде чем конкретизировать понятия, относящиеся к физической модели данных, рассмотрим структуру памяти ЭВМ.

Спасибо Саше 😉

Неструктурированное

1. Жизненный цикл ИС. Виды процессов жизненного цикла ИС. Место проектирования в жизненном цикле ИС.

Это непрерывный процесс, который начинается с момента принятия решения о необходимости создания ис и заканчивается в момент вывода ее из эксплуатации. ЖЦ определяется 3 группами процессов:

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

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

2. Особенности современных ИС. В чем может проявиться влияние этих особенностей при проектировании и внедрении ИС.

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

3. Структурная схема автоматизированной ИС.

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

4. Содержание работ на стадиях и этапах проектирования по стандарту ГОСТ 34.601-90.

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

5. Содержание работ на стадиях и этапах проектирования по стандарту SSADM.

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

6. Национальные стандарты проектирования: структура и основные отличия процесса проектирования согласно стандартам ГОСТ 34.601-90 и SSADM.

Критерий 1. В каждом из стандартов имеются стадии, которые должны завершаться документальным оформлением. ГОСТ 34.601-90 – все стадии; SSADM – 0, 2, 6. ГОСТ 34.601-90 – ориентирован на возможность выполнения каждой стадии независимым разработчиком. Минус – большая бумажная работа, более долгий срок выполнения работ. Необходимость отвлечения специалистов от процесса проектирования на оформление. ГОСТ 34.601-90 предусматривает возможность перерывов между этапами. Ориентирован на длительную коллективную разработку (для крупных разработчиков). SSADM – отчет на стадиях 0, 3, 6. Предусматривает быстрое проектирование с минимальным оформлением документов одним коллективом разработчиков. Критерий 2. Подход к созданию автоматизированной системы. ГОСТ 34.601-90 – оценка реализуемости не обязательна, пункт 1.1 – надо ли разрабатывать. SSADM – стадия 0 – можно ли сделать, стоит ли браться. Критерий 3. Тщательность проектирования (дублирование). ГОСТ 34.601-90: поэтапное дублирование, предусматривающее качественное завершение каждой работы. Дублирования почти нет. SSADM: послеоперационная проверка. Критерий 4. Уровень прогнозирования стандартов. ГОСТ 34.601-90: только на 4-м этапе, и то не обязательно. SSADM: стадия 0 – сразу прогноз, 1, 3, 6.1 – намного больше прогнозирования. ГОСТ 34.601-90 – разработать любой ценой. SSADM – каждое действие проверяют, ничего лишнего делать не будут.

7. Содержание работ на допроектных стадиях – исследование предметной области и предварительное изучение заказчика.

В этой стадии необходимо выполнить работы по изучению предметной области автоматизируемого объекта: 1. Основные понятия; 2. Основные определения; 3. Основные объекты; 4. Их назначение; 5. Взаимосвязи; 6. Роль обслуживающего персонала. Разобраться в предметной области необходимо в объеме, необходимом для ведения, понимания, профессионального диалога с представителями заказчика. Осуществляется знакомство с клиентом. Сбор сведений об организации, желающей разработать некоторую АС. 1. Место ее расположения. 2. Количество персонала, полагаемого к участию в создании и эксплуатации АС. 3. Уровень квалификации персонала среднего и высокого технического и руководящего уровня. 4. Информация о финансовых возможностях компании. 5. Информация об уровне мотивации создать ИС.

8. Содержание работ при определении требований к системе, правила и условия подготовки технического задания.

Требования к интерфейсам ручного ввода данных: 1) Четко различимый шрифт отображения вводимой инф. 2) Использование нейтральных или ярких цветов шрифтов фонов, рамок и других элементов оформления. 3) Рациональное, связанное по смыслу и направлению взгляда размещение инф. на экране. 4) Последовательное автоматическое перемещение между отображаемыми элементами вводимой инф. 5) Система предупреждений и оповещений о пропущенных данных, нарушении формата данных, некорректных операциях. 6) Развитая логическая система автоматического заполнения. 7) Развитая логическая система контроля правильности введенных данных. 8) Средства оперативного отображения доп. справочной инф. о введенных данных. 9) Система управления, позволяющая максимально быстро и эффективно осуществлять переходы, исправления введенных данных, дальнейшую передачу или вывод на печать. 10) Наличие алгоритмов защиты от некорректных действий. 11) Повышенная отказоустойчивость. Процесс подготовки технического задания состоит из следующих этапов: Определение источника финансирования работ по подготовке технического задания; Назначение сотрудников выполняющих разработку и предоставление информации, и подготовку ТЗ. Изучение предметной области Заказчика. Изучение объекта Заказчика, его процессов, персонала, составление модели. Составление списка проблем и требований к системе. Выполнение обследования для определения наличия и уровня существующих решений для автоматизации объектов данной предметной области. Согласование с Заказчиком списка проблем и требований. Подготовка вариантов концепций реализации системы с ориентировочной оценкой стоимости реализации концепции. Желательно использование демонстрационных материалов, прототипов и ссылок на источники информации. Выбор Заказчиком концепции реализации системы. Выбор Разработчиком средств реализации системы. Формулирование требований к разрабатываемой системе и методов и механизмов решения проблем в соответствии с возможностями средств реализации системы. Согласование ответственными за содержание ТЗ Заказчиком и Разработчиком. Оформление ТЗ. Согласование ТЗ со всеми потенциальными пользователями и участниками разработки. Внесение изменений в ТЗ. Подписание ТЗ руководителями Заказчика и Разработчика. Согласование ТЗ в контролирующих организациях (при необходимости).

9. Структура, основные разделы и правила утверждения технического задания по ГОСТ 34.602-89.

Правила оформления 1. Разделы и подразделы ТЗ на АС должны быть размещены в порядке, установленном в разд. 2 настоящего стандарта. 2. ТЗ оформляют на листах формата А4 без рамки, основной надписи и дополнительных граф к ней. Номера листов проставляют после титульного, в верхней части листа после обозначения кода ТЗ на АС. 4. На титульном листе помещают подписи заказчика, разработчика и согласующих организаций, которые скрепляют гербовой печатью. 6. Титульный лист дополнения к ТЗ на АС оформляют аналогично титульном листу ТЗ. 7. На последующих листах дополнения, к ТЗ на АС помещают основание для изменения, содержание изменения и ссылки на документы, в соответствии с которыми вносятся эти изменения. Порядок разработки согласования и утверждения ТЗ на АС Проект ТЗ на АС разрабатывает организация-разработчик системы с участием заказчика на основании технических требований. Необходимость согласования проекта ТЗ на АС с органами государственного надзора и другими заинтересованными организациями определяют совместно заказчик системы и разработчик проекта ТЗ на АС. Срок согласования проекта ТЗ на АС не должен превышать 15 дней со дня его получения ТЗ одновременно во все организации. Замечания по проекту ТЗ на АС должны быть представлены с техническим обоснованием. Если при согласовании проекта ТЗ на АС возникли разногласия между разработчиком и заказчиком, то составляется протокол разногласий и конкретное решение принимается в установленном порядке. Согласование проекта ТЗ разрешается оформлять отдельным документом. Утверждение ТЗ на АС осуществляют руководители предприятий разработчика и заказчика системы. ТЗ на АС до передачи его на утверждение должно быть проверено службой нормоконтроля организации. Согласование и утверждение дополнений к ТЗ на АС проводят в порядке, установленном для ТЗ на АС. Изменения к ТЗ на АС не допускается утверждать после представления системы для ее очереди на приемо-сдаточные испытания. ТЗ на АС содержит следующие разделы, которые могут быть разделены на подразделы: Общие сведения. Назначение и цели создания (развития) системы. Характеристика объектов автоматизации. Требования к системе. Состав и содержание работ по созданию системы. Порядок контроля и приемки системы. Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие. Требования к документированию. Источники разработки. Приложения.

10. Структурное моделирование, назначение, цели и основные правила составления структурных моделей.

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

11. Правила составления и прочтения SADT- диаграмм. Основные достоинства SADT моделирования.

SADT это графические обозначения и подход к описанию систем. SADT-модель можно представить в виде древовидной структуры диаграмм, где верхняя диаграмма является наиболее общей, а самые нижние наиболее детализированы. Диаграмма отражает, что процесс моделирования в SADT является итеративной последовательностью шагов, приводящих к точному описанию системы. Каждая SADT-диаграмма содержит блоки и дуги. Блоки изображают функции моделируемой системы. Дуги связывают блоки вместе и отображают взаимодействия и взаимосвязи между ними. Диаграмме дается название, которое располагается в центре нижней части ее бланка. На каждой диаграмме написана стандартно идентифицирующая ее информация: автор диаграммы, частью какого проекта является работа, дата создания или последнего пересмотра диаграммы, статус диаграммы. Располагается в верхней части бланка диаграммы. Функциональные модели по методике SADT состоят из совокупности SADT диаграмм, каждая SADT модель описывает функционирование определенного устройства или процесса с большой степенью специализации. Каждая SADT диаграмма изображает один процесс и содержит блоки и дуги. Блоки-прямоугольники с надписями и кодом блока в правом нижнем углу. Каждый блок описывает одну функцию моделирования процесса, поэтому блок всегда подписывается названием этой функции в виде глагола. На одной SADT диаграмме пожжет быть не <3 и не >6 блоков. Дуги в зависимости от соединения с блоком имеет опред. значения: верх-отражает цели и задачи, низ-исполнительные механизмы и персонал, лево-входные данные или исходные для процесса, право-результат. Дуги подписываются. Блоки располагаются таким образом, что бы указать их последовательность или доминирование. Важные-левее и выше, менее важные-правее и ниже. Таким образом, описывается процесс любой сложности.

12. Процесс моделирования с точки зрения методологии SADT.

Процесс моделирования в SADT включает сбор информации об исследуемой области, документирование полученной информации и представление ее в виде модели и уточнение модели посредством итеративного рецензирования. Этот процесс показывает путь выполнения согласованной и достоверной структурной декомпозиции, что является ключевым моментом в квалифицированном анализе системы. SADT уникальна в своей способности обеспечить как графический язык, так и процесс создания непротиворечивой и полезной системы описаний. Диаграмма отражает, что процесс моделирования в SADT является итеративной последовательностью шагов, приводящих к точному описанию системы. Высокая эффективность этого процесса обусловлена его организацией, в основе которой лежит разделение функций, выполняемых участниками создания

13. Определение технологии проектирования. Технологическая операция проектирования. Требования.

ТП – это пооперационный план реализации процесса разработки ИС от первых шагов по реализации технического задания до достижения условий точки завершения. Цель: определение конечных сроков и стоимость проекта. ТП определяется как совокупность трех составляющих: Пошаговые процедуры, определяющие состав и последовательность операций тп; Критерии правила, используемых для оценки результатов выполнения операций. Графических и текстовых средств, используемых для описания проектируемых систем. Каждая технологическая операция состоит из 4-х компонентов: Вход для каждой то: исходные данные в стандартном представлении. Снизу: Исполнители, технологические средства для программы. Сверху: Управление, методические материалы, инструкции. Выход: Результат в стандартном представлении.

Основное содержание технологии – технологические инструкции, состоящие из описания технологических операций, их последовательности и условий в зависимости от которых должна выполняться та или иная операция. Требования для составления технологии проектирования: должна поддерживать полный ЖЦ ИС, должна обеспечивать гарантированное достижение целей разработки с заданным качеством и в установленные строки, обеспечивать возможность выполнения крупных проектов в виде подсистем., должна обеспечивать ведение работ по проектированию отдельных подсистем небольшими группами 3-7 чел. Должна обеспечивать мин время получения работоспособности ИС, должна позволять управлять конфигурацией проекта и выпуск документации, должна обеспечивать независимость выполненных проектных решений от средств проектирования.

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

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

15. Технико-экономического обоснование необходимости и реализуемости разработки ИС назначение и содержание. Место составления приближенной оценки и сметы в структуре процесса проектирования по ГОСТ 34.602-89. Основные способы оценки стоимости проектирования единичных и массовых ИС.

Технико-экономического обоснование – документ, в котором математически или логически обосновывается необходимость и целесообразность создания ИС. Для обоснования необходимости создания ИС используются следующие критерии: 1. Наличие существующих проблем, препятствующих эффективной работе объекта, которые могут быть решены с помощью автоматизации. 2. Потери, обусловленные несовершенством структуры управления. 3. Наличие предпосылок по расширению функциональности объекта. 4. Изменение внешних условий, приводящих к неправильной работе объектов. Чтобы обосновать необходимость создания ИС, нужно: 1. Перечислить все явные проблемы, согласно приведенным критериям. 2. Определить место возникновения этих проблем на функциональной модели и составить список функций, которые нуждаются в изменении при решении перечисленных проблем. 3. Определить в денежном эквиваленте потери по каждой из проблем за отчетный период. Основная задача – выяснить список всех проблем и определить суммарную стоимость этих проблем за некоторый отчетный период. Обычно составляется клиентом. Определение стоимости создания ИС. За расчет по фактическим затратам Группы расходов:1. Прямые расходы на оплату труда; материальные для реализации данного проекта; расходы на создание модели; 2. Косвенные – расходы, которые нужны для поддержания деятельности и развития фирмы-разработчика Компьютеры, ПО (ОС, проектирование) 3. Хозяйственные Электричество, Аренда помещения. С т. з. разработчика, желаемая стоимость S=D+R; С т. з. заказчика, Q=∑PiK1K2*Ki, K1 – коэф. Платежеспособности предприятия K2 – коэф. Готовности заказчика принять ИС Ki – коэф. Различных факторов.Реальная стоимость с т. з. разработчика, Q’=S+P+N, P=10-40%. Стоимость массового продукта ∑Q=∑Qi Цена одного экземпляра равна сумме стоимости затрат Q’ / количество реальных пользователей ∑Qi.

16. Документационное обеспечение проектирования ИС. Виды документации в процессе проектирования согласно структуре ГОСТ 34.601-90, ее назначение, используемые при составлении стандарты, и критерии обоснования необходимости составления.

Ниже приводится описание каждого документа из набора IEEE со ссылками на полные. Другие стандарты внутренне организованы по тому же принципу. SVVP (Software Verification and Validation Plan): План экспертизы про¬граммного обеспечения. Этот план определяет, каким образом и в какой последовательности должны проверяться стадии проекта, а также сам про¬дукт на соответствие поставленным требованиям. Верификация — это процесс проверки правильности сборки приложения; валидация проверя¬ет тот факт, что собран требуемый продукт.. Зачастую валидацию и верификацию осуществляют сторонние организации, в этом случае экспертиза называется независимой (IV&V — Independent V&V). SQAP (Software Quality Assurance Plan): План контроля качества про¬граммного обеспечения. Этот план определяет, каким образом проект должен достигнуть соответствия установленному уровню качества. SCMP (Software Configuration Management Plan): План управления кон¬фигурациями программного обеспечения. SCMP определяет, как и где должны храниться документы, программный код и их версии, а также устанавливает их взаимное соответствие. Было бы крайне неразумным начинать работу без такого плана, так как самый первый созданный до¬кумент обречен на изменения, а мы должны знать, как управлять эти¬ми изменениями до того, как мы начнем составлять документ. В этой главе приводится описание IEEE SCMP. Таким образом, инже¬нерам требуется только научиться следовать предписанным процедурам в соответствии с SCMP. SPMP (Software Project Management Plan): План управления программ ным проектом. Этот план определяет, каким образом управлять проектом Обычно он соответствует известному процессу разработки, например стандартному процессу компании. SRS (Software Requirements Specification): Спецификация требований к программному обеспечению. Этот документ определяет требования к приложению и является подобием контракта и путеводной нити для заказчика и разработчиков. SDD (Software Design Document): Проектная документация программно обеспечения. SDD представляет архитектуру и детали проектирования приложения, обычно с использованием диаграмм объектных моделей и потоков данных. STD (Software Test Documentation): Документация по тестированию программного обеспечения. Этот документ описывает, каким образом должно проводиться тестирование приложения и его компонентов. Иногда в проектах привлекается дополнительная документация. Документация для итеративной разработки может быть организована двумя способами. Некоторые документы, в частности SDD, могут содержать свою версию для каждой итерации. Другой способ — дописывать дополнения, которые появляются по мере развития приложения.

17. Методика календарного планирования с использованием сетевых графиков. Преимущества перед диаграммами и матрицами. Определение критических путей и резервов времени.

Представление календарного плана в форме сетевого графика – это классический графический способ наглядного представления проекта. Сетевой график представляет собой ориентированный граф. Узлами графа обозначаются события. Дугами графа обозначаются работы. Работы соединяют события в их последовательности. Событие – абстрактное или реальное, привязанное к этапу работ. Исходные данные – таблица работ. Узел сетевого графика делится на 4 части. Верх – резерв времени. В левой – раннее начала события. В правой – позднее начала события. низ– номер события. Каждая работа снизу подписывается кодом из таблицы работ, сверху длительность. Путь это траектория составляемая по последовательно следуемым работам от начального события к последнему. Протяженность пути это сумма длительностей работ находящихся на траектории пути. Критический путь это путь имеющий макс протяженность (срок реализации проекта), не имеет резерва времени и его изменение влияет на общий срок реализации проекта. Алгоритм построения: составляется топология сетевого графика. Рассчитываются и проставляются ранние начала всех событий, путем сложения длительности работы с ранним началом пред. события. Определяются все возможные пути, рассчитывается их протяженность и выбирается критический путь, кот. отмечается более жирной линией. Для каждого события опред время позднего начала путем отнимания длит работы от даты события завершающего работу. Рассчитываются резервы времени для каждого события. Резерв времени равен разнице между сроками раннего и позднего начал события. Фиктивные работы – для связи двух событий на сетевом графике, которые имеют одинаковые сроки начала, но для наступления этих событий работали разные исполнители. Для конечного события срок раннего и позднего начала равен длительности критического пути. После определения критического пути рассчитывают поздние начала событий и резервы времени расчетом справа налево.

18. Методика календарного планирования с помощью временных диаграмм и матриц. Преимущества перед сетевым графиком. Определение критических путей и резервов времени.

Временная диаграмма – графический способ в виде гистограммы является наиболее доступным для восприятия способом представления календарного плана. По у основные исполнители, по х время. Исходными данными из таблицы работ. На временной диаграмме указываются работы и их протяженность по одному определенному виду ресурсов. Каждая работа подписывается кодом. Временные диаграммы очень наглядны. В отличие от сетевых графиков они позволяют увидеть: 1) Распределение работ по всем имеющимся видам ресурсам. 2) Протяженность работ в масштабе времени. 3) Резервы времени по каждому виду ресурсов, а не только по основным исполнителям; 4) Для их составления можно использовать простые в использовании стандартные объекты для построения гистограмм. Матрицы работ Матрицы использую для компактного представления последовательности и хода выполнения работ. В заголовках строк и колонок таблицы матричного представления перечисляются последовательно все необходимые работы. При начальном заполнении матрицы, указывается требуемая последовательность работ. В строке с текущей работой на пересечении с колонками работ, которые должны полностью завершиться к началу работы строки отмечается их зависимость символом. Для контроля выполнения плана, символ связи работ заменяется условным обозначением процентного соотношения выполнения текущей работы. Матрицы позволяют наглядно и компактно представлять план и ход выполнения работ. Временная протяженность работ не отображается.

19. Классификация и основные отличия сред разработки ПО ИС. Критерии выбора готовых компонент, сред и средств проектирования.

Основные языки программирования используемые в данное время это С++, Object Pascal. Основные различия между ними это язык С++ является системным языком и имеет большую функциональность в ООП. Но имеет более упрощенную описательную структуру, что влечет за собой не наглядность кода программы, что усложняет процесс ее написания, и отладки. В свою очередь Object Pascal строго структурирован, что накладывает ограничения на функциональность языка, но делает его более понятным для разработчика. На основе этих двух языков созданы различные системы проектирования ПО на различных платформах. Для Windows это Delphi, C++ Builder, Visual C++ и т.д Эти два разработчика систем проектирования ПО Borland и MicroSoft. Тоже имеют свои плюсы и минусу Borland является сторонней фирмой занимающейся разработкой систем проектирования которые она разрабатывает на различные платформы и с поддержкой роботы с различным ПО. В свою очередь MicroSoft ориентирован на совместимость только с продукцией MicroSoft. Поэтому по выборе среды разработки, необходимо учитывать. 1. На какой платформе будет работать, и с каким базовым ПО будет взаимодействовать ИС; 2. Необходимую функциональность языка; 3. И уровень знания разработчиками данного языка программирования.

22. Требования к интерфейсам ввода данных.

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

23. Требования к интерфейсам вывода информации.

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

24. Правила составления комментариев в исходных текстах программ.

Основным способом фиксирования информации о разрабатываемой программе являются комментарии в исходных текстах. Грамотно составленные комментарий значительно повышают восприятие исходного текста и назначения программы и ускоряют нахождение ошибок. Кроме того, комментарии используются для автоматизированной обработки текстов программ. Также комментарии используются для автоматизированного составления технической документации на исходные тексты программ. Некоторые основные правила составления комментариев: должны быть достаточно подробными и понятными для чтения другим специалистам. должны иметь графическое выделение символами для легкого визуального отделения комментариев от основного текста программы. при изменении готовой программы должны содержать код специалиста выполнившего изменение, дату изменения, причину изменения и первоначальный фрагмент текста программы. Каждый фрагмент исходного теста, содержащий сложные или специфические действия должен содержать грамотное и подробное описание выполняемых действий. Каждая глобальная переменная должна иметь комментарий. Каждый модуль должен иметь комментарий. Каждая подпрограмма должна иметь развернутый комментарий, содержащий назначение этой подпрограммы, описание, тип, назначение, и условия наличия значения каждой формальной и фактической переменной. В комментариях необходимо использовать некоторые комбинации символов для функционального разделения комментариев. Соблюдение правил использования специальных символов при составлении комментариев к собственным программам можно значительно упростить процесс составления описания программы.

Ответы

1. Основные процессы жизненного цикла информационной системы. Место проектирования в жизненном цикле ИС.

Это непрерывный процесс, который начинается с момента принятия решения о необходимости создания информационной системы и заканчивается в момент вывода информационной системы из эксплуатации.

ЖЦ ИС базируется на трех циклах:

Основные процессы ЖЦ – к ним относятся:

Разработка;
Приобретение;
Эксплуатация;
Сопровождение.

Вспомогательный обеспечивает выполнение основных процессов ЖЦ:

Документирование;
Настройка;
Обеспечение качеством;
Решение проблем.

Организационные процессы:

Управление проектами;
Создание инфраструктуры;
Оценка улучшения самого ЖЦ и обучение.

Разработка включает в себя все работы по проектированию ИС, ее компоненты в соответствии с заданными требованиями, оформление проекта, эксплуатация, документация материалов для контроля качества и обучения персонала.

Приобретение – процесс закупки ИС:

Анализ рынка;
Выявление;
Закупка и доставка.

Внедрение – комплекс работ по запуску созданной ИС в эксплуатацию:

Сборка и установка ИС;
Настройка рабочих мест для людей;
Обеспечение эксплуатационной документацией;
Обучение персонала.

Эксплуатация – использование ИС по прямому назначению, решение текущих проблем в его работе, подготовка материала по совершенствованию, развитию и модернизации ИС.

Сопровождение – комплекс работ по изменению ИС в целях повышения производительности, а также адаптации с новыми элементами и изменениями внутренней и внешней ИС.

2.1 Документирование – процесс формализации на носителе по определенным правилам основных действий, правил и результатов основных процессов ЖЦ.

Документация разделяется на несколько видов:

Проектная документация (в процессе разработки);
Методическая документация (эксплуатация);
Техническое описание (описание созданной ИС).

2.2 Настройка – изменение конфигурации средств программного и технического обеспечения, используемого при создании, эксплуатации ИС, а также конфигурирование самой ИС.

2.3 Обеспечение качества – процесс, определяющий характеристики эффективности этапов и операций основных процессов ЖЦ.

Виды контроля качества:

Верификация – определяет соответствие контролируемого параметра или устройства, заявленным характеристикам.
Проверка – процесс проверки наличия заявленных операций и их работоспособности.
Тестирование – определяет правильность работы, функций или устройства.

2.4 Решение проблем – процесс управления, состоящий в принятии и реализации решений в соответствии с текущим состоянием процесса.

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

3.2 Создание инфраструктуры – комплекс мероприятий по созданию условий для выполнения основных процессов и организации связей с окружающим миром.

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

3.3 Оценка улучшения ЖЦ – процесс, непрерывно используемый в течение всего ЖЦ, целью которого является определение путей оптимизации, повышение эффективности основных процессов ЖЦ, т.е. фактически этот организационный процесс должен всегда стоять как вопрос об оптимизации. В итоге, повышается качество.

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

2. Особенности современных информационных систем. В чем может проявиться влияние этих особенностей при проектировании и внедрении информационных систем.

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

3.Структурная схема автоматизированной информационной системы.

Все начинается с объекта управления.

Подсистема сбора информации – набор датчиков и других устройств, основная задача является определение характеристик и состояния объектов.

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

В ИС есть БД истории работы объектов и есть математическая модель объекта и полученный набор сравнивается с математической моделью.

Полученная информация о состоянии объекта сравнивается с БД истории состояния и сравнивается с математической моделью объекта для получения виртуальной картины состояния объекта: результат этого сравнения поступает на вход устройства принятия управленческого решения.

4.Содержание работ на стадиях и этапах проектирования по стандарту ГОСТ 34.601-90.

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

Обследование объекта и обоснование необходимости создания АС.

Формирование требований пользователя к АС.

Оформление отчета о выполненной работе и заявки АС.

2. Разработка концепции автоматизированной системы.

Изучение объекта.

Проведение необходимых исследовательских работ.

Разработка варианта концепции АС и выбор варианта, который удовлетворяет пользователя.

Оформление отчета о выполненной работе.

3. Техническое задание.

Разработка и утверждение технического задания на создание АС.

4. Эскизные проекты (необязательно).

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

Разработка документации на АС и ее части.

5. Технический проект.

Разработка проектных решений на АС и ее частям.

Разработка документации на АС.

Разработка и оформление документов на поставку изделий на комплектование АС и техзаданий на разработку системы сторонними разработчиками.

Разработка заданий на проектирование в смежных частях объекта автоматизации.

6. Рабочая документация.

Разработка рабочей документации на систему и ее части.

Разработка или адаптация ПО

7. Ввод в эксплуатацию.

8. Сопровождение.

1. Содержание работ на стадиях и этапах проектирования по стандарту SSADM.

0. Оценка реализуемости (необязательно).

Определить рамки и составить план разработки АС.

Определить первоначальный вариант требований к АС.

Выбрать вариант оценки реализуемости.

Оформить отчет о возможности создания АС.

1. Предпроектное обследование.

Определить рамки предпроектного обследования.

Определить основные требования к АС.

Изучить процессы обработки информации в системе.

Изучить данные, обрабатываемые в существующей системе.

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

Обобщить результаты предпроектного обследования.

2. Выбор варианта автоматизации.

3. Разработка технического задания.

Разработать общие требования к автоматизируемым функциям.

Разработать необходимую логическую модель данных.

Уточнить к требования к функциям и задачам.

Уточнить логическую МД.

Разработать демо-прототип.

Разработать требования к обработке данных.

Уточнить цели разработки АС.

Оформить техническое задание.

4. Выбор варианта технической реализации.

Разработать вариант технической реализации.

Выбор варианта технической реализации.

5. Разработка логического проекта.

Определить порядок взаимодействия пользователей и системы.

Разработать постановку задачи изменения существующих БД.

Разработать в постановке задачи обработки информации.

Завершить разработку логического проекта.

6. Физическое проектирование.

Подготовить план физического проектирования.

Разработать физическую организацию БД.

Разработать спецификации требований к программным компонентам.

Оптимизировать физическую структуру БД.

Уточнить спецификации требований к программным компонентам.

Согласовать интерфейс между БД и программами.

Оформить физический проект.

6.Национальные стандарты проектирования: структура и основные отличия процесса проектирования согласно стандартам ГОСТ 34.601-90 и SSADM.

Критерий 1. В каждом из стандартов имеются стадии, которые должны завершаться документальным оформлением.

ГОСТ 34.601-90 – все стадии;

SSADM – 0, 2, 6.

ГОСТ 34.601-90 – ориентирован на возможность выполнения каждой стадии независимым разработчиком.

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

ГОСТ 34.601-90 предусматривает возможность перерывов между этапами. Ориентирован на длительную коллективную разработку (для крупных разработчиков).

SSADM – отчет на стадиях 0, 3, 6. Предусматривает быстрое проектирование с минимальным оформлением документов одним коллективом разработчиков.

Критерий 2. Подход к созданию автоматизированной системы.

ГОСТ 34.601-90 – оценка реализуемости не обязательна, пункт 1.1 – надо ли разрабатывать.

SSADM – стадия 0 – можно ли сделать, стоит ли браться.

Критерий 3. Тщательность проектирования (дублирование).

ГОСТ 34.601-90: поэтапное дублирование, предусматривающее качественное завершение каждой работы. Дублирования почти нет.

SSADM: послеоперационная проверка.

Критерий 4. Уровень прогнозирования стандартов.

ГОСТ 34.601-90: только на 4-м этапе, и то не обязательно.

SSADM: стадия 0 – сразу прогноз, 1, 3, 6.1 – намного больше прогнозирования.

ГОСТ 34.601-90 – разработать любой ценой. SSADM – каждое действие проверяют, ничего лишнего делать не будут.

В этой стадии необходимо выполнить работы по изучению предметной области автоматизируемого объекта:

Основные понятия;
Основные определения;
Основные объекты;
Их назначение;
Взаимосвязи;
Роль обслуживающего персонала.

Разобраться в предметной области необходимо в объеме, необходимом для ведения, понимания, профессионального диалога с представителями заказчика.

Осуществляется знакомство с клиентом.

Сбор сведений об организации, желающей разработать некоторую АС.

Место ее расположения.
Количество персонала, полагаемого к участию в создании и эксплуатации АС.
Уровень квалификации персонала среднего и высокого технического и руководящего уровня.
Информация о финансовых возможностях компании.
Информация об уровне мотивации создать ИС.

9. Определение требований к ИС. Порядок их оформления с согласования.

Требования к интерфейсам ручного ввода данных:

1) Четко различимый шрифт отображения вводимой текстовой и цифровой информации.

2) Использование нейтральных или ярких цветов шрифтов фонов, рамок и других элементов оформления для выделения вводимой, справочной и контрольной информации.

3) Рациональное, связанное по смыслу и направлению взгляда размещение информации на экране.

4) Последовательное автоматическое перемещение между отображаемыми элементами вводимой информации.

5) Система предупреждений и оповещений о пропущенных данных, нарушении формата данных, некорректных операциях.

6) Развитая логическая система автоматического заполнения данных или заполнения значениями.

7) Развитая логическая система контроля правильности введенных данных.

8) Средства оперативного отображения дополнительной справочной информации о введенных данных.

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

10) Наличие алгоритмов защиты от некорректных действий («защита от дурака»).

11) Повышенная отказоустойчивость системы в целом и в особенности от конфликтов обработки неполных данных или данных неверного формата.

К интерфейсам АРМ предъявляются дополнительные требования, к которым относятся:

1) Четко различимый шрифт текстовой и цифровой информации;

2) Использование нейтральных или ярких цветов шрифтов фонов, рамок и других элементов оформления для выделения существенной информации.

3) Рациональное, связанное по смыслу и направлению взгляда размещение информации на экране.

4) Развитая логическая система предупреждений и оповещений о штатных событиях.

5) Логическая система активных предупреждений и оповещений о нештатных событиях.

6) Система управления, позволяющая максимально быстро и эффективно осуществлять необходимые действия с поступающей информацией.

7) Повышенная отказоустойчивость.

8.Правила составления, оформления и утверждения технического задания по ГОСТ 34.602-89.

Правила оформления

Разделы и подразделы ТЗ на АС должны быть размещены в порядке, установленном в разд. 2 настоящего стандарта.
ТЗ на АС оформляют в соответствии с требованиями ГОСТ 2.’105 на листах формата А4 по ГОСТ 2.301 без рамки, основной надписи и дополнительных граф к ней. Номера листов (страниц) проставляют, начиная с первого листа, следующего за титульным листом, в верхней части листа (над текстом, посередине) после обозначения кода ТЗ на АС.
Значения показателей, норм и требований указывают, как правило, с предельными отклонениями или максимальным и минимальным значениями. Если эти показатели, нормы, требования однозначно регламентированы НТД, в ТЗ на АС следует приводить ссылку на эти документы или их разделы, а также дополнительные требования, учитывающие особенности создаваемой системы. Если конкретные значения показателей, норм и требований не могут быть установлены в процессе разработки ТЗ на АС, в нем следует сделать запись о порядке установления и согласования этих показателей, норм и требований.
На титульном листе помещают подписи заказчика, разработчика и согласующих организаций, которые скрепляют гербовой печатью. При необходимости титульный лист оформляют на нескольких страницах. Подписи разработчиков ТЗ на АС и должностных лиц, участвующих в согласовании и рассмотрении проекта ТЗ на АС, помещают на последнем листе.
При необходимости на титульном листе ТЗ на АС допускается помещать установленные в отрасли коды, например: гриф секретности, код работы, регистрационный номер ТЗ и др.
Титульный лист дополнения к ТЗ на АС оформляют аналогично титульном листу ТЗ. Вместо наименования «Техническое задание» пишут «Дополнение № … к ТЗ на АС…».
На последующих листах дополнения, к ТЗ на АС помещают основание для изменения, содержание изменения и ссылки на документы, в соответствии с которыми вносятся эти изменения.
При изложении текста дополнения к ТЗ следует указывать номера соответствующих пунктов, подпунктов, таблиц основного ТЗ на АС и т.п. и применять слова: «заменить», «дополнить», «исключить», «изложить в новой редакции».

Порядок разработки согласования и утверждения ТЗ на АС

Проект ТЗ на АС разрабатывает организация-разработчик системы с участием заказчика на основании технических требований. При конкурсной организации работ варианты проекта ТЗ на АС рассматриваются заказчиком, который либо выбирает предпочтительный вариант, либо на основании сопоставительного анализа подготавливает с участием будущего разработчика АС окончательный вариант ТЗ на АС.
Необходимость согласования проекта ТЗ на АС с органами государственного надзора и другими заинтересованными организациями определяют совместно заказчик системы и разработчик проекта ТЗ на АС. Работу по согласованию проекта ТЗ на АС осуществляют совместно разработчик ТЗ на АС и заказчик системы, каждый в организациях своего министерства.
Срок согласования проекта ТЗ на АС в каждой организации не должен превышать 15 дней со дня его получения ТЗ на АС (копий) одновременно во все организации.
Замечания по проекту ТЗ на АС должны быть представлены с техническим обоснованием. Решения по замечаниям должны быть приняты разработчиком проекта ТЗ на АС и заказчиком системы до утверждения ТЗ на АС.
Если при согласовании проекта ТЗ на АС возникли разногласия между разработчиком и заказчиком, то составляется протокол разногласий и конкретное решение принимается в установленном порядке.
Согласование проекта ТЗ на АС разрешается оформлять отдельным документом. В этом случае под грифом «Согласовано» делают ссылку на этот документ.
Утверждение ТЗ на АС осуществляют руководители предприятий разработчика и заказчика системы.
ТЗ на АС до передачи его на утверждение должно быть проверено службой нормоконтроля организации – разработчика ТЗ и, при необходимости, подвергнуто метрологической экспертизе. Копии, утвержденного ТЗ на АС в 10-дневный срок после утверждения высылаются разработчиком ТЗ на АС участникам создания системы.
Согласование и утверждение дополнений к ТЗ на АС проводят в порядке, установленном для ТЗ на АС.
Изменения к ТЗ на АС не допускается утверждать после представления системы для ее очереди на приемо-сдаточные испытания.
Регистрация, учет и хранение ТЗ на АС и дополнений к нему проводят в соответствии с требованиями ГОСТ 2.501.

9.Разделы технического задания и их краткое содержание по ГОСТ 34.602-89.

ТЗ на АС содержит следующие разделы, которые могут быть разделены на подразделы:

1. Общие сведения.

1.1 Полное наименование системы и ее условное обозначение;

1.2 Шифр темы или шифр (номер) договора;

1.3 Наименование предприятий разработчика и заказчика системы и их реквизиты;

1.4 Перечень документов, на основании которых создается система, кем и когда утверждены эти документы;

1.5 Плановые сроки начала и окончания работы по созданию системы;

1.6 Сведения об источниках и порядке финансирования работ;

1.7 Порядок оформления и предъявления заказчику результатов работ по созданию системы по изготовлению и наладке.

1.8 Отдельных средств (технических, программных и информационных) и программно-технических (программно-методических) комплексов системы.

2. Назначение и цели создания (развития) системы.

Назначение системы;
Цели создания системы.

3. Характеристика объектов автоматизации.

3.1 Краткие сведения об объекте автоматизации или ссылки на документы, содержащие такую информацию;

3.2 Сведения об условиях эксплуатации объекта автоматизации и характеристиках окружающей среды.

4. Требования к системе.

4.1 Требования к системе в целом;

4.2 Требования к функциям (задачам), выполняемым системой.

5. Состав и содержание работ по созданию системы.

5.1 Перечень стадий и этапов работ по созданию системы;

5.2 Сроки их выполнения;

5.3 Перечень организаций – исполнителей работ;

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

5.5 Перечень документов, по ГОСТ 34.201, предъявляемых по окончании соответствующих стадий и этапов работ;

5.6 Вид и порядок проведения экспертизы технической документации (стадия, этап, объем проверяемой документации, организация-эксперт);

5.7 Программу работ, направленных на обеспечение требуемого уровня надежности разрабатываемой системы (при необходимости);

5.8 Перечень работ по метрологическому обеспечению на всех стадиях создания системы с указанием их сроков выполнения и организаций-исполнителей (при необходимости).

6. Порядок контроля и приемки системы.

Виды, состав, объем и методы испытаний системы и ее составных частей;

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

ЗУ статус приемочной комиссии.

7. Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие.

7.1 Приведение поступающей в систему информации к виду, пригодному для обработки с помощью ЭВМ;

7.2 Изменения, которые необходимо осуществить в объекте автоматизации;

7.3 Создание условий функционирования объекта автоматизации;

7.4 Создание необходимых для функционирования системы подразделений и служб;

7.5 Сроки и порядок комплектования штатов и обучения персонала.

8. Требования к документированию.

Согласованный разработчиком и Заказчиком системы перечень подлежащих разработке комплектов и видов документов, соответствующих требованиям ГОСТ 34.201 и НТД отрасли заказчика; перечень документов, выпускаемых на машинных носителях; требования к микрофильмированию документации;

Требования по документированию комплектующих элементов межотраслевого применения в соответствии с требованиями ЕСКД и ЕСПД;

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

9. Источники разработки.

9.1 Документы и информационные материалы, на основании которых разрабатывалось ТЗ и которые должны быть использованы при создании системы.

10. Приложения.

10.1 Расчет ожидаемой эффективности системы;

10.2 Оценка научно-технического уровня системы.

10.Структурное моделирование, назначение, цели и основные правила составления структурных моделей.

Структурные модели отражают состав системы (перечень основных объектов и подсистем и возможные между ними связи(направление и сила)).

Структурная модель включает в себя структурную схему

Каждый объект

Взаимодействие

Направление взаимодействия

Мера взаимодействия обозначается толщиной связи

Основные объекты имеют одинаковый уровень специализации.

Наличие дуг желательно.

Иерархическая – возможность подчеркивания доминирования одних объектов над другими.

Функциональная схема.

Система SADP структурный анализ данных и таблиц. IDEFO появился в1969 г.

11.Правила составления и прочтения SADT– диаграмм. Основные достоинства SADT моделирования.

12.Процесс моделирования с точки зрения методологии SADT.

Метод SADT представляет собой совокупность правил и процедур, предназначенных для построения функциональной модели объекта какой-либо предметной области. Функциональная модель SADT отображает функциональную структуру объекта, т.е. производимые им действия и связи между этими действиями. Основные элементы этого метода основываются на следующих концепциях:

• графическое представление блочного моделирования. Графика блоков и дуг SADT-диаграммы отображает функцию в виде блока, а интерфейсы входа-выхода представляются дугами, соответственно входящими в блок и выходящими из него. Взаимодействие блоков друг с другом описывается посредством интерфейсных дуг, выражающих “ограничения”, которые, в свою очередь, определяют, когда и каким образом функции выполняются и управляются;

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

Метод SADT может использоваться для моделирования самых разнообразных систем и определения требований и функций с последующей разработкой информационной системы, удовлетворяющей этим требованиям и реализующей эти функции. В существующих системах метод SADT может применяться для анализа функций, выполняемых системой, и указания механизмов, посредством которых они осуществляются.

СОСТАВ ФУНКЦИОНАЛЬНОЙ МОДЕЛИ

Результатом применения метода SADT является модель, которая состоит из диаграмм, фрагментов текстов и глоссария, имеющих ссылки друг на друга. Диаграммы — главные компоненты модели, все функции организации и интерфейсы на них представлены как блоки и дуги соответственно. Место соединения дуги с блоком определяет тип интерфейса. Управляющая информация входит в блок сверху, в то время как входная информация, которая подвергается обработке, показана с левой стороны блока, а результаты (выход) показаны с правой стороны. Механизм (человек или автоматизированная система), который осуществляет операцию, представляется дугой, входящей в блок снизу (рис.1).

Одной из наиболее важных особенностей метода SADT является постепенное введение все больших уровней детализации по мере создания диаграмм, отображающих модель.

Рис. 1. Функциональный блок и интерфейсные дуги

При составлении модели надо уяснить:

Цель и задачи моделирования;
Определиться с мнением человека, который дает информацию о системе;
Сбор информации об объекте;
Формализация;
Согласование – руководитель и персонал разработчика управляется целями;
Рецензирование;
Утверждение модели;

13.Определение технологии проектирования. Технологическая операция проектирования.

ТП определяется как совокупность:

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

Каждая технологическая операция состоит из 4-х компонентов:

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

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

Сверху: Управление, методические материалы (инструкции, нормативы, стандарты, критерии оценки результатов)

Выход: Результат в стандартном представлении.

Требования к технологии проектирования

Чтобы правильно спроектировать технологию:

Технология должна поддерживать полный ЖЦ ИС.
Технология должна обеспечивать гарантированное достижение целей разработки с заданным качеством и в установленные строки.
Технология должна обеспечивать возможность выполнения крупных проектов в виде подсистем, т.е. должна быть декомпозиция на составные части, разработанные отдельными группами исполнителей ограниченной численности с последней интеграцией составных частей.

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

При этом надо обеспечить координацию проектов и исключить дублирование результатов каждой группы.

Технология должна обеспечивать возможность проектирования отдельных подсистем группами от 3-х до 7-ми человек.

Технология должна обеспечивать минимальное время получения работоспособности ИС. Минимальное время – не готовность системы в целом, а полная рабочая готовность отдельных функциональных узлов.

Чтобы сделать полностью ИС в короткие сроки, требуется большое количество разработчиков, при этом качество создания системы будет не самым высоким, чем при реализации отдельных подсистем в более короткие сроки меньшим количеством разработчиков.

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

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

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

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

К таким стандартам относятся 3 вида:

Проектирование;
Стандарт оформления проектируемой документации;
Стандарт пользовательского интерфейса.

Стандарт проектирования должен установить список необходимых моделей (схем, диаграмм) на каждой стадии проектирования, степень их детализации

Правило фиксации проектных решений на схемах:

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

Стандарт оформления проектной документации должна включать в себя:

Комплектность, состав и структуру документации на каждой стадии проектирования;
Требования к содержанию разделов, подразделов и пунктов, таблиц и правил нумерации.

Стандарт интерфейса пользователя должен устанавливать правила оформления экрана, в т.ч. состав, расположение окон, элементов управления, вид шрифтов, цветовое решение интерфейсов.

Правило использования клавиатуры и мыши;
Правило оформления текстов помощи;
Перечень стандартов сообщений;
Правило обработки реакции пользователя.

15.Технико-экономического обоснование необходимости и реализуемости разработки ИС назначение и содержание. Место составления приближенной оценки и сметы в структуре процесса проектирования по ГОСТ 34.602-89. Основные способы оценки стоимости проектирования единичных и массовых ИС.

Технико-экономического обоснование – документ, в котором математически или логически обосновывается необходимость и целесообразность создания ИС.

Для обоснования необходимости создания ИС используются следующие критерии:

Наличие существующих проблем, препятствующих эффективной работе объекта, которые могут быть решены с помощью автоматизации. Это любые ошибки человеческих факторов, потери документов, искажение при передаче, различия квалификаций пользователей, и т.д.
Потери, обусловленные несовершенством структуры управления (недостаточное количество информации для анализа, неоправданное поступление информации, избыток ненужной информации, трудность анализа большого количества информации).
Наличие предпосылок по расширению функциональности объекта, что приведет к обострению пунктов 1 и 2.
Изменение внешних условий, приводящих к неправильной работе объектов.

Чтобы обосновать необходимость создания ИС, нужно:

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

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

Определение стоимости создания ИС.

За расчет по фактическим затратам

Группы расходов:

Прямые

расходы на оплату труда;
материальные для реализации данного проекта (носители информации, базовое ПО);
расходы на создание модели;

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

Компьютеры
ПО (ОС, проектирование)

Хозяйственные

Электричество (коммунальные платежи)
Аренда помещения.

С т. з. разработчика, желаемая стоимость S=D+R;

С т. з. заказчика, Q=∑PiK1K2*Ki

K1 – коэф. Платежеспособности предприятия

K2– коэф. Готовности заказчика принять ИС

Ki – коэф. Различных факторов.

Реальная стоимость с т. з. разработчика, Q’=S+P+N

P=10-40%

Стоимость массового продукта ∑Q=∑Qi

Цена одного экземпляра равна сумме стоимости затрат Q’ / количество реальных пользователей ∑Qi.

16.Документационное обеспечение проектирования ИС. Виды документации в процессе проектирования согласно структуре ГОСТ 34.601-90, ее назначение, используемые при составлении стандарты, и критерии обоснования необходимости составления.

Ниже приводится описание каждого документа из набора IEEE со ссылками на полные. Другие стандарты внутренне организованы по тому же принципу.

 SVVP (Software Verification and Validation Plan): План экспертизы про¬граммного обеспечения. Этот план определяет, каким образом и в какой последовательности должны проверяться стадии проекта, а также сам про¬дукт на соответствие поставленным требованиям. Верификация — это процесс проверки правильности сборки приложения; валидация проверя¬ет тот факт, что собран требуемый продукт.. Зачастую валидацию и верификацию осуществляют сторонние организации, в этом случае экспертиза называется независимой (IV&V — Independent V&V).

 SQAP (Software Quality Assurance Plan): План контроля качества про¬граммного обеспечения. Этот план определяет, каким образом проект должен достигнуть соответствия установленному уровню качества.

 SCMP (Software Configuration Management Plan): План управления кон¬фигурациями программного обеспечения. SCMP определяет, как и где должны храниться документы, программный код и их версии, а также устанавливает их взаимное соответствие. Было бы крайне неразумным начинать работу без такого плана, так как самый первый созданный до¬кумент обречен на изменения, а мы должны знать, как управлять эти¬ми изменениями до того, как мы начнем составлять документ. В этой главе приводится описание IEEE SCMP. Таким образом, инже¬нерам требуется только научиться следовать предписанным процедурам в соответствии с SCMP.

 SPMP (Software Project Management Plan): План управления программ ным проектом. Этот план определяет, каким образом управлять проектом Обычно он соответствует известному процессу разработки, например стандартному процессу компании.

 SRS (Software Requirements Specification): Спецификация требований к программному обеспечению. Этот документ определяет требования к приложению и является подобием контракта и путеводной нити для заказчика и разработчиков.

 SDD (Software Design Document): Проектная документация программно обеспечения. SDD представляет архитектуру и детали проектирования приложения, обычно с использованием диаграмм объектных моделей и потоков данных.

 STD (Software Test Documentation): Документация по тестированию программного обеспечения. Этот документ описывает, каким образом должно проводиться тестирование приложения и его компонентов.

Иногда в проектах привлекается дополнительная документация. Документация для итеративной разработки может быть организована двумя способами. Некоторые документы, в частности SDD, могут содержать свою версию для каждой итерации. Другой способ — дописывать дополнения, которые появляются по мере развития приложения.

17.Методика календарного планирования с использованием сетевых графиков. Преимущества перед диаграммами и матрицами. Определение критических путей и резервов времени.

18.Методика календарного планирования с помощью временных диаграмм и матриц. Преимущества перед сетевым графиком. Определение критических путей и резервов времени.

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

Свойства проекта:

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

Руководитель проекта должен составить проект так, чтобы рационально распределить трудовые ресурсы, минимизировать материальные, финансовые затраты, обосновать стоимость проектирования, спланировать 100% завершение проекта в выбранные им сроки.

Виды сетевых моделей:

Сетевой график;
Табличное представление;
Матричное представление;
Временная диаграмма.

Табличный способ – составляется таблица работ.

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

№ работы	Какие работы должны закончиться к этому времени
A	–
B	–
C	A
D	A, B, C

Сетевой график

Структура сетевой модели образуется из трех типов элементов

Событие – момент времени начала или окончания к. – л. Работы.
Работы – неделимая часть комплекса действий, направленных на решение некоторых задач.
Фиктивная работа 0 условный элемент структуры сетевого графика, используется для указания логической связи отдельных событий.

Узлы – события, дуги – работы.

Продолжительность работы – календарное время.
Раннее время начала работы – наиболее ранний срок начала этой работы.
Раннее время окончания = Раннее время начала работы + Продолжительность работы.
Позднее время окончания – наиболее поздний из допустимых сроков окончания работы.
Позднее время начала работы = Позднее время окончания – Продолжительность работы.
Раннее время наступления события характеризует наиболее раннее из возможных наступлений событий
Позднее время характеризует более поздний из допустимых сроков возникновения событий.
Путь – любая последовательность непосредственно идущих друг за другом работ сетевых моделей.
Сумма продолжительности выполнения работ составляющих путь, называется продолжительностью пути.
Самый продолжительный путь из начального события в конечное называется критическим путем.

Работы, лежащие на критическом пути, называется критическими, события – критическими.

Резерв времени наступления события – разница между поздним и ранним сроком наступления этого события.

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

Резерв времени 5 – 3,5 = 1,5

При определении путей расчетов используются 2 подхода

Используется раннее начало.

Матричный способ

	1	2	3	4	5
1	*	1	1
2		*			1
3			*	1
4				*	1
5					*

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

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

19. Классификация и основные отличия сред разработки ПО ИС. Критерии выбора готовых компонент, сред и средств проектирования.

Основные языки программирования используемые в данное врамя это С++, Object Pascal.

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

В свою очередь Object Pascal строго структурирован, что накладывает ограничения на функциональность языка, но делает его более понятным для разработчика.

На основе этих двух языков созданы различные системы проектирования ПО на различных платформах. Для Windows это Delphi, C++ Builder, Visual C++ и т.д

Эти два разрабочика систем проектирования ПО Borland и MicroSoft. Тоже имеют свои плюсы и минусу Borland является сторонней фирмой занимающейся разработкой систем проектирования которые она разрабатывает на различные платформы и с поддержкой роботы с различным ПО (Серверами Oracle, Interbase, СУБД Paradox, dBase и т.д.). В свою очередь MicroSoft ориентирован на совместимость только с продукцией MicroSoft.

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

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

20.Состав и возможности системы автоматизации документооборота «1С Предприятие 7.7».

Система 1С:Предприятие 7.7 – это универсальная экономическая интегрированная среда для проектирования и работы в различных экономических задачах.

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

Ядро – 1С:Предприятие содержит в себе функции среды проектирования и среды выполнения электронной системы документооборота, включает в себя:

Создание структуры БД.
Создание диалоговых окон для работы с БД и пользователем.
Интерпретатор языка 1С:7.7.
Средства для создания шаблонов печатных форм.
Средства для создания списка пользователей, наборов прав и видов главного меню и панели инструментов.
Различные средства администрирования и конфигурирования.
Алгоритм по запуску и выполнению метаданных.

Библиотека.

Оперативный учет (Остаток 1С:Торговля и склад) расширяет возможность оболочки для создания дополнительных таблиц и дополнительных функций с целью автоматического расчета и использования накопленных значений, остатков и оборотов.
Бухгалтерский учет (1С: Бухгалтерия) расширяет функцию ядра для хранения плана счетов, видов субконто и добавляет систему функций для работы с ними.
Расчет (1С:Зарплата и кадры) расширяет функцию ядра до создания и хранения алгоритмов автоматического расчета значений на указанный период и на данную дату.

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

Информационная база включает:

Файл метаданных 1CV7.7.md содержит все настройки данной программы (структуры БД, шаблоны диалоговых печатных форм, исходники, все остальные настройки).
БД, состоящая из множества файлов формата dbase, в которой содержится информация о пользователях, содержатся отдельные подкаталоги, содержащие определенные настройки пользователей.

21.Структура и основные объекты модели документооборота реализованной в среде «1С Предприятие 7.7».

Константы – переменная в БД, обращение программно и интерактивно.

Справочники – таблица, объект метаданных, предназначенная для работы со списком заданной структуры.

Режим 1С:Предприятие – Запуск метаданных на выполнение , пользователь работает с экономическими данными.
Режим 1С:Конфигуратор – Запуск метаданных для редактирования, а также в не выполняются административные функции, режим администратора.
Режим 1С:Отладчик – возможно частичное выполнение алгоритмов с использованием точек останова.
Режим 1С:Монитор – определит список пользователей, работающих в данной системе.
Содержание работ на допроектных стадиях – исследование предметной области и предварительное изучение заказчика.

22.Требования к интерфейсам ввода данных.

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

Требования к интерфейсам ручного ввода данных:

1) Четко различимый шрифт отображения вводимой текстовой и цифровой информации.

3) Рациональное, связанное по смыслу и направлению взгляда размещение информации на экране.

4) Последовательное автоматическое перемещение между отображаемыми элементами вводимой информации.

6) Развитая логическая система автоматического заполнения данных или заполнения значениями.

7) Развитая логическая система контроля правильности введенных данных.

8) Средства оперативного отображения дополнительной справочной информации о введенных данных.

10) Наличие алгоритмов защиты от некорректных действий («защита от дурака»).

23.Требования к интерфейсам вывода информации.

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

К таким интерфейсам предъявляются дополнительные требования, к которым относятся:

1) Четко различимый шрифт текстовой и цифровой информации;

3) Рациональное, связанное по смыслу и направлению взгляда размещение информации на экране.

4) Развитая логическая система предупреждений и оповещений о штатных событиях.

5) Логическая система активных предупреждений и оповещений о нештатных событиях.

7) Повышенная отказоустойчивость.

24.Правила составления комментариев в исходных текстах программ.

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

Также комментарии используются для автоматизированного составления технической документации на исходные тексты программ.

Некоторые основные правила составления комментариев:

1) Комментарии должны быть достаточно подробными и понятными для чтения другим специалистам.

2) Комментарии должны иметь графическое выделение символами для легкого визуального отделения комментариев от основного текста программы.

3) Комментарии при изменении готовой программы должны содержать код специалиста выполнившего изменение, дату изменения, причину изменения и первоначальный фрагмент текста программы.

4) Каждый фрагмент исходного теста, содержащий сложные или специфические действия (расчеты, обработки, операции с БД или памятью, ссылки на другое ПО) должен содержать грамотное и подробное описание выполняемых действий.

5) Каждая глобальная переменная должна иметь комментарий.

6) Каждый модуль должен иметь комментарий.

7) Каждая подпрограмма должна иметь развернутый комментарий, содержащий назначение этой подпрограммы, описание, тип, назначение, и условия наличия значения каждой формальной и фактической переменной.

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

Например:

1) Выделение подпрограммы

//*****************Название процедуры****************

//******************Конец процедуры с конкретным названием*****

2) Изменения при внедрении.

//@нZerg010203№567

Начало изменения исходного текста выполненного программистом с ником Zerg 1 февраля 2003 года описанного в реестре изменений по номером 567.

//@ кZerg010203№567

конец изменения

3) Комментарий к специфическому алгоритму под номером 134 в описании программы.

//=134 Алгоритм декульзирования:

// Необходимо для ……

4) Глобальная переменная

Var Scanner1:Variant; {Переменная через которую обращаемся к сканеру штрих-кодов}

5) Информация о программисте выполнившем изменения.

//i_Zerg – Карганов Олег Петрович , OOO «Софт-Сибирь» тел:.44-33-55

Соблюдение правил использования специальных символов при составлении комментариев к собственным программам можно значительно упростить процесс составления описания программы.

25.Инфраструктура проектируемой ИС – назначение, состав, методы согласования.

26.Внедрение и сопровождение ИС. Состав работ и условия взаимодействия с клиентом.

27.Перечень работ руководителя проекта при управлении созданием новой ИС.

Are you hiring? Check out my CV

MOAR

Проектирование информационных систем

Курс Лекций (На другой странице)

Шпаргалка (На другой странице)

Ответы на вопросы (Структурировано)

Неструктурированное

Наше

Неструктурированное

Ответы

1. Основные процессы жизненного цикла информационной системы. Место проектирования в жизненном цикле ИС.

MOAR