2015-05-30
1371
Процесс – совокупность взаимосвязанных действий, преобразующих некоторые входные данные в выходные. Процессы состоят из набора действий, а каждое действие - из набора задач. Вертикальное измерение отражает статические аспекты процессов и оперирует такими понятиями, как рабочие процессы, действия, задачи, результаты деятельности и исполнители.
Стадия – часть действий по созданию программного обеспечения, ограниченная некоторыми временными рамками и заканчивающаяся выпуском конкретного продукта, определяемого заданными для данной стадии требованиями. Стадии состоят из этапов, которые обычно имеют итерационный характер. Иногда стадии объединяют в более крупные временные рамки, называемые фазами. Горизонтальное измерение представляет собой время, отражает динамические аспекты процессов и оперирует такими понятиями, как фазы, стадии, этапы, итерации и контрольные точки
29. Технология структурного программирования.
Технология программирования – это система методов, способов и приемов обработки и выдачи информации.
|
|
|
Структурное программирование — методология разработки программного обеспечения, в основе которой лежит представление программы в виде иерархической структуры блоков.
Цели структурного программирования:
• Повысить надежность программ
• Повысить эффективность программ
• Уменьшить время и стоимость программной разработки
• Улучшить читабельность программ
Основные принципы структурной методологии:
• Принцип абстракции – этот принцип позволяет разработчику рассматривать программу в нужный момент без лишней детализации.
• Принцип формальности. Он предполагает строгий методический подход к программированию, придает творческому процессу определенную строгость и дисциплину.
• Принцип модульности. В соответствии с этим принципом программа разделяется на отдельные законченные фрагменты, модули, которые просты по управлению и допускают независимую отладку и тестирование.
• Принцип иерархического упорядочения. Взаимосвязь между частями программы должна носить иерархический, подчиненный характер.
Реализации структурного стиля программирования:
• Структура информационного пространства. Задача разбивается на подзадачи, и таким образом выстраивается дерево вложенности подзадач. Информационное пространство структурируется в точном соответствии с деревом вложенности
• Структуры управления. Стиль структурного программирования предполагает использование строго ограниченного набора управляющих конструкций: последовательность операторов, условные и выбирающие операторы, все вычислительные ветви которых сходятся в одной точке программы, а также процедуры, вычисления которых всегда заканчиваются возвратом управления в точку вызова.
|
|
|
• К структурным операторам добавляются либо циклы, либо рекурсии. Концептуальное противоречие между циклами и рекурсиями намного мягче, чем между операторами структурного программирования и структурными переходами, и оно отмечается лишь в виде изредка встречающихся прагматических указаний не смешивать их произвольно.
• Потоки передачи данных. Разбивая задачу на подзадачи, программист предусматривает их взаимодействие по данным: одни подзадачи передают другим данные для переработки.
• Структуры данных. Данные объединяются в логически связанные фрагменты, соответствующие структурам задачи либо вспомогательных конструкций, вводимых для ее решения.
Структурное программирование предполагает точно обозначенные управляющие структуры, программные блоки, отсутствие инструкций безусловного перехода (GOTO), автономные подпрограммы, поддержка рекурсии и локальных переменных.
Суть такого подхода заключается в возможности разбиения программы на составляющие элементы.
30. Стандарты структурного программирования.
Основные принципы структурного программирования:
• Программа работает и решает поставленную задачу
• Минимальное время, затрачиваемое на тестирование и отладку программы
• Уменьшение затрат на сопровождение
• Гибкость программы
• Уменьшение затрат на разработку
• Простота и эффективность
Функциональный блок.
Условная конструкция.
Блок обобщенного цикла.
 |
31. Технология сборочного программирования.
Сборочное программирование – технология программирования, при которой программа собирается посредством повторного использования уже известных фрагментов программ.
32. Направления развития и модели концепции открытых систем.
Открытая система - это система, реализующая открытые спецификации на интерфейсы, службы и форматы данных, достаточные для того, чтобы обеспечить:
· возможность переноса (мобильность) прикладных систем, разработанных должным образом, с минимальными изменениями на широкий диапазон систем;
· совместную работу (интероперабельность) с другими прикладными системами на локальных и удаленных платформах;
· взаимодействие с пользователями в стиле, облегчающем последним переход от системы к системе (мобильность пользователей).
От применения технологии открытых систем выигрывают все категории специалистов, участвующих в процессе информатизации: пользователи, разработчики, производители и стандартизаторы.
Для обеспечения пользователей и проектировщиков прикладных систем современным инструментарием, позволяющим значительно сократить сроки проектирования и создания открытых систем, повысить качество проектов служит следующий набор средств:
· рекомендации по выбору инструментальных средств проектирования приложений, переносимых между различными аппаратными платформами и операционными средами;
· экспериментальные образцы программных средств для поддержки всего жизненного цикла открытых систем, в том числе - информационной базы, экспертной системы принятия проектных решений, интеллектуального инструментария для проектирования программного обеспечения;
· методы и средства моделирования (имитации) процессов взаимодействия в открытых системах;
· объектно-ориентированные средства проектирования и программирования открытых систем;
· методы и средства конструирования предметно-ориентированных языков, трансляторов с этих языков, синтаксически управляемых редакторов и интерпретирующих сред в открытых системах;
|
|
|
· исследования и разработка распределенных операционных систем и параллельных языков программирования, функционирующих в среде открытых систем.
· Важным инструментом для выявления взаимосвязи различных функциональных компонент, используемых прикладной системой в открытой среде, является модель такой среды.
Модели открытых систем:
· Референсная модель
Модель развивается и используется уже около двадцати лет. Она описывает систему взаимодействий в процессах обмена сообщениями и данными между прикладными системами в вычислительных сетях. Модель является наиболее проработанной с функциональной точки зрения, полноты набора стандартов и определения их совместимости друг с другом. Модель основана на разбиении среды на семь уровней, взаимодействие между которыми описывается соответствующими стандартами
· Модель MIC
Эта модель представляет собой попытку объединить различные подходы к классификации компонент среды. Она строится в виде матрицы 7х4, столбцы которой соответствуют видам взаимодействия (обслуживания) в системе: взаимодействие с пользователем, системные средства, доступ к данным, коммуникационные средства.
· Модель OSE/RF
В рамках этой модели под прикладным обеспечением понимаются собственно прикладные программы, данные, а также документация и средства обучения пользователей.
Прикладная платформа состоит из аппаратной платформы и программного обеспечения. Сюда входят: операционная система, компиляторы, СУБД, графические системы, т. е. все средства, составляющие операционную среду для прикладных систем.
К внешней среде относятся все системные элементы, которые являются внешними по отношению к прикладной платформе и прикладному обеспечению. Это утилиты и подсистемы, реализуемые на других (удаленных) платформах, а также периферийные устройства.
Взаимодействие между прикладным обеспечением и прикладной платформой осуществляется с помощью Прикладных Программных Интерфейсов (API). В области API предусматривается четыре интерфейсных элемента для взаимодействия с: системными службами; коммуникационными службами; информационными службами; службами, обеспечивающими человеко-машинный интерфейс.
|
|
|
· Модель MUSIC
M - Management;
U - User interface;
S - Service interface for programs;
I - Information and data formats;
C - Comunications interfaces.
В модели MUSIC наибольшее внимание уделено тем аспектам взаимодействия и интерфейсам, которые могут оказаться критическими именно для прикладной системы, функционирующей в открытой среде.
Элемент U (User Interface) распадается на две основных компоненты. Первая - представляет группу взаимодействий, которые имеют место между пользователем и прикладной системой в целом (прикладная программа и системные средства, включая аппаратуру), вне зависимости от конкретного типа прикладной системы, которая используется. Вторая компонента соответствует действиям пользователя при взаимодействии с собственно прикладной программой.
Элемент S (Service interfaces for programs) включает интерфейсы для взаимодействия прикладной программы с системными средствами ЭВМ, на которой эта программа выполняется (аппаратура и программы).
Элемент I (Information and Data Formats) объединяет средства, обеспечивающие доступ к данным и обмен данными.
Элемент C (Comunications interfaces). Компоненты, объединяемые в этот элемент, обеспечивают взаимодействие через локальные и глобальные сети.
33. Цели и задачи концепции открытых систем.
Открытая система - это система, реализующая открытые спецификации на интерфейсы, службы и форматы данных, достаточные для того, чтобы обеспечить:
· возможность переноса (мобильность) прикладных систем, разработанных должным образом, с минимальными изменениями на широкий диапазон систем;
· совместную работу (интероперабельность) с другими прикладными системами на локальных и удаленных платформах;
· взаимодействие с пользователями в стиле, облегчающем последним переход от системы к системе (мобильность пользователей).
Цель технологии открытых систем состоит в обеспечении возможности переносимости прикладных программ между различными платформами и обеспечения взаимодействия систем друг с другом. Эта возможность достигается за счет использования международных стандартов на все программные и аппаратные интерфейсы между компонентами систем.
34. Профили открытых ИС и ЖЦ ПС.
Стандартизированные профили открытых систем позволяют заказчику освободиться от диктата какого-то одного поставщика программных или аппаратных продуктов за счет приобретения средств, соответствующих стандартам, нормативным требованиям и рекомендациям профиля. Профили также облегчают повторное использование в проектируемой системе уже разработанных и проверенных прикладных программ. Качество информационных систем тесно связано с методами и технологией их разработки, поэтому важной группой документов в профилях являются стандарты и их рекомендации по непосредственному обеспечению качества ИС.
Между приложениями и средой определяются стандартизированные интерфейсы (Application Program Interface, API). Эти интерфейсы являются необходимой частью профиля любой открытой системы. Кроме того, в профилях ИС могут быть определены унифицированные интерфейсы взаимодействия прикладных программ между собой и интерфейсы взаимодействия между компонентами среды ИС.
Для эффективного применения конкретного профиля необходимо:
- выделить объединенные единой логической связью проблемно-ориентированные области функционирования, где могут использоваться стандарты, общие для одной организации или группы организаций;
- идентифицировать стандарты и нормативные документы, варианты их применения и параметры, которые необходимо включить в профиль;
- документально зафиксировать те части конкретного профиля, где требуется создание новых стандартов или нормативных документов, и идентифицировать характеристики, которые могут оказаться важными для разработки недостающих стандартов и нормативных документов этого профиля;
- формализовать профиль в соответствии с его категорией, включая стандарты, различные варианты нормативных документов и дополнительные возможности, непосредственно связанные с профилем.
Для корректного применения профилей объектов и процессов ИС необходимо разработать систему методических руководств по использованию каждого профиля. В этих руководствах должно быть отражено:
- содержание и описание выбранных пользователем положений стандартов и нормативных документов профиля;
- параметры адаптации стандартов профиля и содержание дополнительных нормативных документов;
- методика и сценарии корректного применения всех обязательных и рекомендуемых положений профиля;
- требования к содержанию отчетов о результатах контроля и тестирования компонентов ИС на соответствие обязательным и рекомендуемым положениям профиля.
Для последующего длительного использования каждый выделенный профиль должен пройти стадию формирования, адаптации и параметризации применительно к характеристикам стандартизируемых объектов или процессов создания ИС. Подготовка профилей к применению должна учитывать реальное состояние проекта ИС.
Жизненный цикл конкретной ИС на каждом этапе должен быть поддержан соответствующими комплектами профилей. Последовательность этапов создания, сопровождения и развития ИС следующая:
- системный анализ объекта информатизации и создание концепции ИС. На этом этапе производится первичный выбор исходного комплекта стандартов, которым должна соответствовать ИС, выявляются необходимость разработки и состав дополнительных нормативных документов; оформляется содержание и определяются параметры исходных комплектов документов предполагаемых профилей;
- проектирование ИС. В этот период определяется архитектура и структура ИС уточняются положения, параметры и адаптируются стандарты комплекта профилей; они дополняются ведомственными или корпоративными нормативными документами; оформляются проекты документов и методических руководств по применению рабочей версии каждого профиля;
- разработка или приобретение готовых компонентов ИС. Здесь утверждаются и применяются все положения профиля, а компоненты ИС проходят испытания на соответствие требованиям и документам конкретного профиля;
- сопровождение, актуализация и развитие ИС. На этом этапе анализируются характеристики применяемой версии каждого профиля; выявляются и устраняются ее дефекты; производится модернизация профиля, с учетом более совершенных технических и программных средств и новых стандартов ИТ; при необходимости осуществляется формирование, документирование и внедрение новых уточненных версий профилей.
35. Технология объектно-ориентированного программирования.
Объектно-ориентированное программирование (ООП) — парадигма программирования, в которой основными концепциями являются понятия объектов и классов.
Объект в программе — это абстракция реального объекта. Объект обладает атрибутами, поведением и индивидуальностью. Атрибуты определяют основные черты объекта, поведение — действия над объектом, индивидуальность — отличие одного объекта от другого с такими же атрибутами по их конкретным значениям.
Класс – это множество объектов с одинаковыми атрибутами и поведением, представляемое в языке программирования в виде абстрактного типа данных, который включает в себя члены класса.
Методология ООП основана на принципе организации программы в виде набора относительно самостоятельных сущностей, называемых объектами. Каждый объект имеет полностью скрытую от внешней среды внутреннюю структуру (принцип инкапсуляции) и строго документированный механизм взаимодействия с другими объектами (интерфейс). Во время исполнения программы объекты, из которых она состоит, взаимодействуют через свои интерфейсы, решая каждый свою часть задачи. Каждый объект принадлежит к некоторому классу. Все объекты одного класса имеют одну и ту же структуру и различаются только значениями данных, инкапсулированных в них.
Между классами могут существовать отношения наследования. Если класс B является наследником класса A, то класс B полностью наследует структуру класса A и может добавлять к ней свои характерные черты. Переменные в программе могут содержать значения разных классов, при этом одно и то же управляющее воздействие на переменную может обрабатываться различным образом, в зависимости от того, к каким объектам оно применяется. Эта возможность различного поведения одних и тех же объектов в различных условиях называется полиморфизмом.
Инкапсуляция, наследование и полиморфизм считаются базовыми понятиями, на которых строится технология ООП.
ООП было разработано с целью получения механизма создания больших и сверхбольших программных комплексов, когда выяснилось, что ранее существовавшие методологии программирования не обеспечивают получения качественного результата в разумные сроки из-за прогрессирующего возрастания сложности программного обеспечения.
36. Основные принципы объектно-ориентированного программирования.
Абстрагирование подразумевает собой процесс изменения уровня детализации программы. Основная его роль - выделение существенных характеристик некоторого объекта, отличающие его от всех других видов объектов и, таким образом, четкое определение его концептуальных границ с точки зрения наблюдателя.
Инкапсуляция есть объединение в едином объекте данных и кодов, оперирующих с этими данными.
Инкапсуляция является важным принципом ООП, организующим защиту информации от ненужных и случайных модификаций, что обеспечивает целостность данных и упрощает отладку программного кода после изменений.
Наследование состоит в процессе создания новых объектов (потомков) на основе уже имеющихся объектов (предков) с передачей их свойств и методов по наследству. Наследование позволяет модифицировать поведение объектов и придает объектно-ориентированному программированию исключительную гибкость.
Полиморфизм - это свойство родственных объектов (то есть тех объектов, классы которых являются производными от одного родителя) вести себя по-разному в зависимости от ситуации, возникающей в момент выполнения программы. Слово полиморфизм происходит от греческих слов poly (много) и morphos (форма) и означает множественность форм методов объектов.
37. Виртуальные и динамические методы ООП.
При обращении к виртуальным и динамическим методам вызываемая процедура или функция определяется только в момент обращения. Такой механизм называется поздним связыванием. Виртуальные и динамические методы определяются по типу фактической объектной переменной. Именно виртуальные и динамические методы позволяют в полной мере реализовать концепцию полиморфизма. При объявлении виртуальных и динамических методов используются директивы virtual и dynamic соответственно. Виртуальные и динамические методы различаются только внутренней реализацией. Кратко опишем их внутренние различия:
При вызове метода адрес метода определяется из таблиц VMT (Virtual Method Table) – для виртуальных или DMT (Dynamic Method Table) – для динамических. Таблицы VMT охватывают виртуальные методы всей иерархии классов, а DMT содержит информацию только о динамических методах текущего класса, следовательно, таблица VMT больше чем DMT. Так как адреса всех виртуальных методов содержаться в одной таблице VMT, то поиск адреса требуемого метода выполняется быстро. При вызове динамического метода адрес кода его реализации сначала ищется в DMT экземпляра и если адрес не найден, то в таблицах DMT всех классов-предков в порядке иерархии, что значительно медленней, чем у виртуальных методов. Следовательно, виртуальные методы выполняются быстрее, чем динамические, но требуют значительно больше памяти.
Для того чтобы изменить поведение виртуальных или динамических методов у потомка (переопределить метод или перекрыть) используется служебное слово override.
38. Описание объекта. Использование объекта в ООП.
В центре ООП находится понятие объекта. Объект — это сущность, которой можно посылать сообщения, и которая может на них реагировать, используя свои данные. Данные объекта скрыты от остальной программы. Сокрытие данных называется инкапсуляцией.
Наличие инкапсуляции достаточно для объектности языка программирования, но ещё не означает его объектной ориентированности — для этого требуется наличие наследования.
Но даже наличие инкапсуляции и наследования не делает язык программирования в полной мере объектным с точки зрения ООП. Основные преимущества ООП проявляются только в том случае, когда в языке программирования реализован полиморфизм; то есть возможность объектов с одинаковой спецификацией иметь различную реализацию.
В парадигме ООП задумано так, что уже написанный сложный объект, может быть использован как модуль в составе какой-нибудь библиотеки (программы), для чего не нужно переписывать его заново, а достаточно лишь перевести исходный код класса (объекта) в другой вид (если нужно), понятный «новой программе», в которой будет реализован алгоритм работы и/или данные этого объекта.
Как правило, при рассмотрении объектов выделяется то, что объекты принадлежат одному или нескольким классам, которые в свою очередь определяют поведение (являются моделью) объекта. Время с момента создания объекта (конструкция) до его уничтожения (деструкция) называется временем жизни объекта. Объект наряду с понятием «класс», является важным понятием объектно-ориентированного подхода в программировании. Объекты обладают свойствами наследования, инкапсуляции и полиморфизма.
39. Основы CASE технологии.
CASE (англ. Computer-Aided Software Engineering) — набор инструментов и методов программной инженерии для проектирования программного обеспечения, который помогает обеспечить высокое качество программ, отсутствие ошибок и простоту в обслуживании программных продуктов.
Также под CASE понимают совокупность методов и средств проектирования информационных систем с интегрированными автоматизированными инструментами, которые могут быть использованы в процессе разработки программного обеспечения.
Классификация по типам:
• Средства анализа;
• Средства проектирования баз данных;
• Средства разработки приложений;
• Средства реинжиниринга;
• Средства планирования и управления проектом;
• Средства тестирования;
• Средства документирования.
Классификация по категориям:
• отдельные локальные средства, решающие небольшие автономные задачи;
• набор частично интегрированных средств, охватывающих большинство этапов жизненного цикла;
• набор полностью интегрированных средств, охватывающий весь жизненный цикл информационной системы и связанных общей базой данных (репозиторием).
40. Определение потребности в CASE – средствах.
Данный этап включает достижение понимания потребностей организации и технологии последующего процесса внедрения CASE-средств. Он должен привести к выделению тех областей деятельности организации, в которых применение CASE-средств может принести реальную пользу. Результатом данного этапа является документ, определяющий стратегию внедрения CASE-средств.
41. Оценка и выбор CASE средств.
Процесс оценки и/или выбора может быть начат только тогда, когда лицо, группа или организация полностью определила для себя конкретные потребности и формализовала их в виде количественных и качественных требований в заданной предметной области.
Входной информацией для процесса оценки является:
• определение пользовательских потребностей;
• цели и ограничения проекта;
• данные о доступных CASE-средствах;
• список критериев, используемых в процессе оценки.
Результаты оценки могут включать результаты предыдущих оценок. При этом не следует забывать, что набор критериев, использовавшихся при предыдущей оценке, должен быть совместимым с текущим набором.
Процесс выбора:
• формулировка задач выбора, включая цели, предположения и ограничения;
• выполнение всех необходимых действий по выбору, включая определение и ранжирование критериев, определение средств-кандидатов, сбор необходимых данных и применение ранжированных критериев к результатам оценки для определения средств с наилучшими показателями. Для многих пользователей важным критерием выбора является интегрируемость CASE-средства с существующей средой;
• выполнение необходимого количества итераций с тем, чтобы выбрать (или отвергнуть) средства, имеющие сходные показатели;
• подготовка отчета по результатам выбора.
Результаты процесса выбора:
• рекомендации по выбору конкретного CASE-средства
• запрос на получение дополнительной информации, необходимой для оценки
42. CASE-модель жизненного цикла ПС.
Жизненный цикл ПО - это непрерывный процесс, который начинается с момента принятия решения о необходимости его создания и заканчивается в момент его полного изъятия из эксплуатации.
Фазы ЖЦ CASE-технологии:
• Прототипирование
• Проектирование спецификаций
• Контроль проекта
• Кодогенерация
• Системное тестирование
• Сопровождение
43. Состав, структура и функциональные особенности CASE-средств.
CASE-средства служат инструментарием для поддержки и усиления методов структурного анализа и проектирования. Эти инструменты поддерживают работу пользователей при создании и редактировании графического проекта в интерактивном режиме, они способствуют организации проекта в виде иерархии уровней абстракции, выполняют проверки соответствия компонентов. Фактически CASE-средства представляют собой новый тип графически-ориентированных инструментов, восходящих к системе поддержки ЖЦ ПО.
Обычно к ним относят любое программное средство, обеспечивающее автоматическую помощь при разработке ПО, его сопровождении или деятельности по управлению проектом, и проявляющее следующие дополнительные черты:
• мощная графика для описания и документирования систем ПО, а также для улучшения интерфейса с пользователем, развивающая творческие возможности специалистов и не отвлекающая их от процесса проектирования на решение второстепенных вопросов;
• интеграция, обеспечивающая легкость передачи данных между средствами и позволяющая управлять всем процессом проектирования и разработки ПО непосредственно через процесс планирования проекта;
• использование компьютерного хранилища (репозитория) для всей информации о проекте, которая может разделяться между разработчиками и исполнителями как основа для автоматического продуцирования ПО и повторного его использования в будущих системах.
Помимо перечисленных основополагающих принципов графической ориентации, интеграции и локализации всей проектной информации в репозитории в основе концептуального построения CASE-средств лежат следующие положения:
1. Человеческий фактор, определяющий разработку ПО как легкий, удобный и экономичный процесс.
2. Широкое использование базовых программных средств, получивших массовое распространение в других приложениях (БД и СУБД, компиляторы с различных языков программирования, отладчики, документаторы, издательские системы, оболочки экспертных систем и базы знаний, языки четвертого поколения и др.).
3. Автоматизированная или автоматическая кодогенерация, выполняющая несколько видов генерации кодов: преобразования для получения документации, формирования БД, ввода/модификации данных, получения выполняемых машинных кодов из спецификаций ПО, автоматической сборки модулей из словарей и моделей данных и повторно используемых программ, автоматической конверсии ранее используемых файлов в форматы новых требований.
4. Ограничение сложности, позволяющее получать компоненты, поддающиеся управлению, обозримые и доступные для понимания, а также обладающие простой и ясной структурой.
5. Доступность для разных категорий пользователей.
6. Рентабельность.
7. Сопровождаемость, обеспечивающая способность адаптации при изменении требований и целей проекта.
44. Особенности и возможности Internet-технологии.
Функции интернета:
• Информационная;
• Коммуникационная.
Информационная функция:
• Получение информации об изучаемом предмете;
• Обучение;
• Получать информацию о событиях в реальном времени;
• Использование серверов для хранения данных.
Коммуникационная функция:
• Электронная почта;
• Общение в режиме online;
• Совместное использование приложений;
• Использование интернет – сервисов.
Средства разработки:
• HTML - стандартный язык разметки документов в Internet;
• CSS используется создателями веб-страниц для задания цветов, шрифтов, расположения отдельных блоков и других аспектов представления внешнего вида этих веб-страниц;
• JavaScript — скриптовый язык программирования.
45. Услуги, предоставляемые Internet.
• Электронная почта;
• Общение в режиме online;
• Обучение;
• Совместное использование приложений;
• Использование интернет – сервисов.
46. Особенности и возможности Intranet-технологии.
Intranet – это, прежде всего, корпоративная - локальная или территориально распределенная сеть, закрытая от внешнего доступа из Internet. Такая сеть возможно использует публичные каналы связи, входящие в Internet, но при этом обеспечивается защита передаваемых данных и меры по пресечению проникновения извне на корпоративные узлы.
Сервисы, предоставляемые Интранетом:
• Просмотр гипертекстовых документов
• Электронная почта
• Службы новостей
• Передача файлов
• Взаимодействие с базами данных с помощью серверных приложений
• Передача мгновенных сообщений
Средства разработки, эксплуатации и сопровождения:
• средства выполнения (Run-time);
• инструментальные средства разработки;
• средства администрирования.
• Средства выполнения включают:
• программы просмотра и навигации (браузеры);
• клиентские приложения и расширения;
• программное обеспечение Web-серверов;
• серверные приложения и расширения;
• средства поиска информации;
• программное обеспечение Internet-серверов;
• средства безопасности.
47. Промышленные технологии разработки ПС.
Промышленная разработка ПО как часть промышленной разработки сложных систем – высокотехнологичный процесс, в который вовлечено множество различающихся по численности, сфере деятельности и квалификации коллективов разработчиков. Одна из основных задач при совместной разработке большого количества разработчиков и их коллективов: обеспечение единой схемы работы, позволяющей планировать выполнение работ, обеспечивать целостность и непротиворечивость различных узлов системы, а также давать гарантии соответствия системы ожиданиям заказчика.
48. Экстремальное программирование.
Экстремальное программирование (ХР) – это дисциплина разработки программного обеспечения и ведения бизнеса в области создания программных продуктов, которая фокусирует усилия обеих сторон (программистов и бизнесменов) на общих, вполне достижимых целях.
Основная цель ХР:
• Создание качественных программ.
Одно из главных средств:
• Отказ от всего, что не поддерживает непосредственно эту цель.
Суть экстремального программирования:
• все задание разбивается на формулировки подзадач, каждая формулировка должна иметь срок выполнения от 1 до 3-х недель, если больше, то - следует разделить, меньше - объединить;
• путем равновесия объема, времени, ресурсов и качества составляется структурный план выпуска версий программы на основании пользовательских формулировок;
• при выполнении очередной итерации проекта важно не добавить функциональности раньше времени;
• перед началом новой итерации создается ее подробный план: формулировки разбиваются на задачи сроком от 1 до 3-х дней и сортируются по важности, добавляются задачи, которые не смогли пройти тест приемки;
• нужно проводить ежедневные утренние планерки, желательно стоя, чтобы не занимали слишком много времени;
• простой дизайн проекта;
• простые имена для создаваемых классов;
• постоянный контакт с заказчиком;
• использовать парное программирование: два программиста за одним компьютером;
• не бояться переделывать старый, работающий, но малоэффективный код;
• оптимизировать систему в последнюю очередь;
• следить за качеством исходных текстов;
• использовать тесты создаваемого "черного ящика" как можно чаще
• не работать сверх графика (переутомление).
Экстремальное программирование доводит использование многих общепринятых и широко используемых принципов программирования до экстремальных уровней:
• Пересмотр кода – каждый участник проекта будет пересматривать код постоянно;
• Проектирование – проектирование в экстремальном программировании нужно сделать составной частью повседневной работы каждого из участников проекта;
• Тестирование – каждый участник проекта будет тестировать код программы постоянно;
• Простота – каждый участник проекта должен сохранять в системе наиболее простой дизайн, обеспечивающий текущий требуемый уровень функциональности;
• Интеграционное тестирование - необходимо собирать и тестировать разрабатываемую систему несколько раз на дню.
49. Оценка качественных показателей ПС.
1) Выбрать 10 показателей качества и сформулировать их сущность. Каждый показатель должен быть существенным, должны быть ясны потенциальные выгоды его использования.
2) Установить веса показателей
где wi – экспертная оценка (вес)
3) Для каждого показателя установить конкретную численную оценку.
Например:
– 0 – свойство в ПС присутствует, но качество его неприемлемо;
– 0.5 – 1 – свойство в ПС присутствует и обладает приемлемым качеством;
– 1 – свойство в ПС присутствует и обладает очень высоким качеством.
4) Оценка качества ПС как иерархической взвешенной суммы всех весов.
где wi – экспертная оценка (вес), ri – оценка, установленная экспериментом
5) Представить выходные данные:
а) перечень всех показателей с указанием причин такой оценки.
б) гистограмма, показывающая распределение показателей по интервалам оценок.
в) какие дефекты ПС обнаружены в результате анализа показателей качества.
50. Оценка сложности ПС.
Метод Холстеда.
1. Мера длины 
где 
– число различных операторов, 
– число различных операндов
2. Объем модуля 
51. Оценка надежности ПС.
Модель Коркорэна.
N0– число безотказных испытаний
N – число испытаний
Ni– количество ошибок i-го типа
ai – вероятность появления ошибки i-го типа
Yi – вероятность появления ошибок Yi=ai, если Ni>0 Yi=0, если Ni=0
k – известное число типов ошибок
R – показатель уровня надёжности
Преимущества: легкий расчёт и получение показателя надёжности в виде числа.
Недостатки: необходимо знать вероятности появления ошибок в том или ином классе задач.
52. Оценка технико-экономических показателей ПС.
• объём программного средства (в операторах языка или строках текста)- О;
• длительность разработки (по фактическому времени)-Д;
Д=Д1-Д2, где Д1 - дата начала разработки технического задания на ПС, Д2- дата сдачи ПС;
• число программных и информационных модулей в ПС -Р;
• количество фактически затраченного времени на разработку ПС- М;
• трудоёмкость разработки ПС (по фактически затраченному времени по стадиям разработки) - Т;
• абсолютное снижение трудовых затрат- ТА
ТА=Т0-Т1, где Т0- трудовые затраты на решение задачи по базовому варианту (вручную), Т1- трудовые затраты на решение задачи по предлагаемому варианту;
• коэффициент относительного снижения трудовых затрат- КТ
КТ=ТА/Т0*100,
• индекс снижения трудовых затрат или повышение производительности труда- УТ
УТ=Т0/Т1,
• абсолютное снижение стоимостных затрат- СА
СА=С0-С1, где С0 - стоимостные затраты на решение задачи по базовому варианту, С1- стоимостные затраты на решение задачи по предлагаемому варианту;
• коэффициент относительного снижения стоимостных затрат- КС
КС=СА/С 0 * 100,
• индекс снижения стоимости затрат -УС
УС=С0/С1,
• срок окупаемости ПС- К
К=КТ/СА, где КТ- затраты на разработку и внедрение программного средства.
53. Управление технологической безопасностью ПС и БД.
Технологическая безопасность – обеспечение устойчивости высоких технологий при осложнениях, возникающих в связи с неблагоприятными тенденциями или конкретными событиями в государстве.
Требования по обеспечению безопасности в различных ИС могут существенно отличаться, однако они всегда направлены на достижение трех основных свойств:
• целостность – информация, на основе которой принимаются решения, должна быть достоверной и точной, защищенной от возможных непреднамеренных и злоумышленных искажений;
• доступность (готовность) – информация и соответствующие автоматизированные службы должны быть доступны, готовы к работе всегда, когда в них возникает необходимость;
• конфиденциальность – засекреченная информация должна быть доступна только тому, кому она предназначена.
54. Маркетинг и реклама на ПС.
Маркетинг — это искусство и наука правильно выбирать целевой рынок, привлекать, сохранять и наращивать количество потребителей посредством создания у покупателя уверенности, что он представляет собой наивысшую ценность для компании», а также «упорядоченный и целенаправленный процесс осознания проблем потребителей и регулирования рыночной деятельности.
Реклама — процесс донесения информации от рекламодателя до целевой аудитории посредством медиа-каналов или иными способами.
Задача рекламы — побудить представителей целевой аудитории к действию (выбору товара или услуги, осуществлению покупки и т. п., а также формированию запланированных рекламодателем выводов об объекте рекламирования).
Проще говоря, маркетинг нужен, чтобы определить тип клиентов, а реклама нужна, чтобы донести до клиента, что это то самое ПС, о котором он мечтал всю свою жизнь и что оно самое лучшее.
55. Методы решения транспортных задач.
В любой транспортной задаче можно найти бесчисленное множество вариантов плана перевозок.
Допустимый – это такой план (такое распределение поставок), в котором все мощности используются, а спрос всех потребителей удовлетворен.
Наиболее распространенные методы построения матрицы перевозок:
• Северо-западного угла
При этом способе «поставки» располагаются, начиная от левого верхнего и кончая нижним правым углом матрицы. На географических картах левый верхний угол соответствует северо-западу, эта аналогия и дала название способу.
• Минимум в столбце
Метод заключается в том, что поочередно в столбцах матрицы отмечаются минимальные показатели и в соответствующие клетки заносятся поставки в зависимости от спроса и предложения. Если при записи поставок спрос по столбцу удовлетворен не полностью, ищется следующий по величине элемент в данном столбце, отмечается новый элемент и так до полного удовлетворения спроса. Только после этого переходят на следующий столбец.
Если в столбце два или несколько одинаковых по величине минимальных показателя, то может быть отмечен любой из них.
• Минимум в строке
Метод заключается в том, что поочередно в строках матрицы отмечаются минимальные показатели и в соответствующие клетки заносятся поставки в зависимости от спроса и предложения. Если при записи поставок спрос по строке удовлетворен не полностью, ищется следующий по величине элемент в данной строке, отмечается новый элемент и так до полного удовлетворения спроса. Только после этого переходят на следующую строку.
Если в строке два или несколько одинаковых по величине минимальных показателя, то может быть отмечен любой из них.
• Двойного предпочтения
Ищется минимальный элемент в первом столбце и проверяется является ли он минимальным в строке, если ответ положительный, то данная клетка запоминается, то есть в зависимости от спроса и предложения в данную графу-клетку ставится поставка, затем, при превращении в нуль, вычеркивается строка либо столбец.
Пройдя таким образом всю матрицу переходят к первому столбцу из оставшихся (не вычеркнутых) и тек до тех пор пока распределение не будет закончено.
• Лебедева
При данном методе подсчитывается Сij по строкам и столбцам и каждая сумма делится на число элементов в строке или строке, в результате чего получаются средние величины.
Каждый элемент вычитается из суммы двух соответствующих средних. При этом разности называются коэффициентами очередности.
Распределение поставок производится сначала в клетку таблицы с наибольшими коэффициентами, далее в следующую за ним по величине и т.д. Коэффициенты вписаны в правых верхних углах каждой клетки.
• Юго - восточного угла.
При этом способе «поставки» располагаются, начиная от правого нижнего и кончая верхним левым углом матрицы. На географических картах правый нижний угол соответствует юго-востоку, эта аналогия и дала название способу.
• Минимального элемента в матрице.
Данный метод дает лучший результат, особенно в более крупных матрицах, но его использование требует большого внимания.
При использовании этого способа удобно после записи очередной поставки отмечать (хотя бы крестиками) все клетки соответствующего столбца или соответствующей строки (в зависимости от того, удовлетворен ли спрос или исчерпана мощность). Тогда количество элементов матрицы, которые нужно просматривать после записи каждого нового кружка, все время уменьшается.
• Фогеля.
Процесс начинается с определения разности между двумя наименьшими Сij каждого столбца и строки. Минимальный элемент в соответствующей строке(столбце) запоминается и на его место записывается поставка, после чего данная строка(столбец) исключается.
Если наибольшая разность оказывается сразу в двух столбцах(строках), тогда проверяют является ли какой-либо элемент минимальным в строке и столбце одновременно. Если ответ положительный, тогда записывают поставку, если нет, тогда произвольно выбираем либо столбец, либо строку.
• Лебедева - Тихомирова.
При данном методе подсчитывается Сij по строкам и столбцам и каждая сумма делится на число элементов в строке или строке, в результате чего получаются средние величины.
Каждый элемент вычитается из суммы двух соответствующих средних. При этом разности называются коэффициентами очередности.
Распределение поставок производится сначала в клетку таблицы с наибольшими коэффициентами, далее в следующую за ним по величине и т.д. Коэффициенты вписаны в правых верхних углах каждой клетки.
После записи каждой поставки исключаются из рассмотрения элементы соответствующего столбца (или строки), пересчитываются средние величины по строкам (столбцам) и заново вычисляются все коэффициенты очередности.
Оптимизация решения задачи может быть осуществлена с помощью различных методов, среди которых:
• Потенциалов.
• Квадратов.
Квадратом называются 4 клетки, стоящие в углах такого прямоугольника, в которых хотя бы по одной диагонали стоят положительные поставки. В клетках, стоящих на другой диагонали могут быть нули, нуль и поставка либо две поставки.
Квадрат называется неправильным, если сумма двух стоимостей, стоящих в клетках с положительными поставками по одной диагонали, больше суммы двух стоимостей по другой диагонали.
Квадрат называется правильным, если сумма двух стоимостей, стоящих в клетках с положительными поставками по одной диагонали, меньше суммы двух стоимостей по другой диагонали.
Квадрат называется нейтральным, если сумма двух стоимостей, стоящих в клетках с положительными поставками по одной диагонали равна сумме двух стоимостей по другой диагонали.
Оптимальный план не содержит неправильных квадратов. Любой неправильный квадрат можно преобразовать в правильный.
Если в таблице несколько неправильных квадратов, то необходимо выполнить последовательную замену, начиная с квадрата, обладающего большей экономической мощностью.
Экономическая мощность неправильного квадрата определяется как произведение модуля разности стоимостей, взятых по диагонали, на наименьшую поставку, стоящую в той диагонали, где сумма стоимостей больше.
Замена неправильного квадрата на правильный осуществляется путем вычитания из поставок, стоящих на диагонали, сумма стоимостей которой больше, наименьшей поставки и прибавления ее к числам другой диагонали.
• Распределительный.
• Венгерский.
• Форда- Фулкерсона.
• Разрешающих слагаемых.
• Дифференциальных рент.
56. Постановка транспортной задачи, ограничения.
Постановка задачи: некоторый однородный продукт, сосредоточенный у m поставщиков в количестве Аi (i=1..m) единиц соответственно, необходимо доставить n потребителям в количестве Вj (j=1..n) единиц. Известна стоимость Сij перевозки единицы груза от i-го поставщика к j-му потребителю. Необходимо определить оптимальный (имеющий минимальную стоимость) план поставок продукции, позволяющий вывести все грузы и полностью удовлетворить потребности потребителей.
Запасы равны суммарным потребностям (закрытая модель транспортной задачи).
57. Оптимизация транспортной задачи. Метод квадратов.
Квадратом называются 4 клетки, стоящие в углах такого прямоугольника, в которых хотя бы по одной диагонали стоят положительные поставки. В клетках, стоящих на другой диагонали могут быть нули, нуль и поставка либо две поставки.
Квадрат называется неправильным, если сумма двух стоимостей, стоящих в клетках с положительными поставками по одной диагонали, больше суммы двух стоимостей по другой диагонали.
Квадрат называется правильным, если сумма двух стоимостей, стоящих в клетках с положительными поставками по одной диагонали, меньше суммы двух стоимостей по другой диагонали.
Квадрат называется нейтральным, если сумма двух стоимостей, стоящих в клетках с положительными поставками по одной диагонали равна сумме двух стоимостей по другой диагонали.
Оптимальный план не содержит неправильных квадратов. Любой неправильный квадрат можно преобразовать в правильный.
Если в таблице несколько неправильных квадратов, то необходимо выполнить последовательную замену, начиная с квадрата, обладающего большей экономической мощностью.
Экономическая мощность неправильного квадрата определяется как произведение модуля разности стоимостей, взятых по диагонали, на наименьшую поставку, стоящую в той диагонали, где сумма стоимостей больше.
Замена неправильного квадрата на правильный осуществляется путем вычитания из поставок, стоящих на диагонали, сумма стоимостей которой больше, наименьшей поставки и прибавления ее к числам другой диагонали.
58. Реализация ПО ТЗ в лабораторной работе.
Насколько я понял, то имеется в виду реализация решения транспортной задачи в лабораторной работе.
59. Особенности современных ПС и БД как объектов разработки.
Современные крупные проекты ИС характеризуются, как правило, следующими особенностями:
· сложность описания (достаточно большое количество функций, процессов, элементов данных и сложные взаимосвязи между ними), требующая тщательного моделирования и анализа данных и процессов;
· наличие совокупности тесно взаимодействующих компонентов (подсистем), имеющих свои локальные задачи и цели функционирования (например, традиционных приложений, связанных с обработкой транзакций и решением регламентных задач, и приложений аналитической обработки (поддержки принятия решений), использующих нерегламентированные запросы к данным большого объема);
· отсутствие прямых аналогов, ограничивающее возможность использования каких-либо типовых проектных решений и прикладных систем;
· необходимость интеграции существующих и вновь разрабатываемых приложений;
· функционирование в неоднородной среде на нескольких аппаратных платформах;
· разобщенность и разнородность отдельных групп разработчиков по уровню квалификации и сложившимся традициям использования тех или иных инструментальных средств;
· существенная временная протяженность проекта, обусловленная, с одной стороны, ограниченными возможностями коллектива разработчиков, и, с другой стороны, масштабами организации-заказчика и различной степенью готовности отдельных ее подразделений к внедрению ИС.
Для успешной реализации проекта объект проектирования (ИС) должен быть, прежде всего, адекватно описан, должны быть построены полные и непротиворечивые функциональные и информационные модели ИС
Особое внимание уделяется качеству документации, которое во многом определяет конкурентоспособность программ и БД.
При создании сложных ПС и обеспечении их ЖЦ надо сделать выборку нужных стандартов, что позволяет строить комплексы ПС из крупных функциональных модулей, отвечающих требованиям стандартов профиля, и применять отработанные проектные решения и методы, обеспечивающие повторное использование компонентов ПС и БД на иных аппаратных и операционных платформах, то есть эффективно решать проблему мобильности и адаптируемости ПС и БД на основе CASE-технологий. Для этого применяют стандартизацию структуры ПС и их интерфейсов с операционной и внешней средой и фиксируют показатели качества ПС, которые не должны снижаться при переносе программ на другие платформы.
Освоение основ экономики создания и применения ИС и их компонентов позволяет рационализировать капиталовложения в средства автоматизации, прогнозировать затраты и длительность разработки систем, научно планировать создание крупных ПС и БД. Так как их разработка требует больших затрат и происходит в условиях ограниченных ресурсов, надо осуществлять баланс между достигаемым их качеством и ресурсами для их реализации, поддерживая его на всём ЖЦ. При этом особенно остро стоит задача борьбы с ростом ошибок в сложных ПС и БД, угрожающим безопасности и надёжности ИС. Для их сокращения применяют типизацию проектов ИС в определённых проблемно ориентированных областях, сборочное программирование, процессы, средства и стандарты управления конфигурацией и качеством ПС и БД.
60. Специфические особенности ПС ВТ. ПС – новый вид товарной продукции.
Прежде всего, следует отметить некоторое противостояние, неформальный характер требований к ПС постановки задачи и понятия ошибки в нем, неформализованный основной объект разработки - программы ПС. Разработка ПС носит существенно творческий характер на каждом шаге приходится делать какой-либо выбор, принимать какое-либо решение, а не сводится к выполнению какой-либо последовательности регламентированных действий. Тем самым эта разработка ближе к процессу проектирования каких-либо сложных устройств, но никак не к их массовому производству. Этот творческий характер разработки ПС сохраняется до самого ее конца. Следует отметить также особенность продукта разработки. Он представляет собой некоторую совокупность текстов, т.е. статических объектов, смысл же семантика этих текстов выражается процессами обработки данных и действиями пользователей, запускающих эти процессы, т.е. является динамическим. Это предопределяет выбор разработчиком ряда специфичных приемов, методов и средств. Продукт разработки имеет и другую специфическую особенность ПС при своем использовании эксплуатации не расходуется и не расходует используемых ресурсов.
