Добавил:
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Лекции 2010.doc
Скачиваний:
26
Добавлен:
10.05.2014
Размер:
2.28 Mб
Скачать

1.Индивидуальная разработка.

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

  1. Знание предметной области разработчиком исчерпывающее (т.к. разработчик является специалистом в этой области.)

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

  3. Из-за ограниченного количества разработчиков никакой специальной организации коллектива не требуется.

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

  5. Продукт не имеет коммерческой стоимости, и если распространяется, то коллегам, друзьям, знакомым.

Промышленный подход.

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

  2. Объем ПС может достигать десятки и сотни тысяч операторов, что естественно требует большого количества работников.

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

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

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

2. Основные задачи, решаемые при разработке ПС.

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

  1. Определить процесс и этапы разработки ПС.

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

  3. Разработать методы и оценки, длительность разработки ПС и трудозатраты.

  4. Оценить факторы, определяющие производительность труда коллектива разработчиков.

  5. Изучить варианты организации коллектива разработчиков и выбрать из них наиболее подходящий.

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

  1. Определить структуры построения комплексных программ (КП).

  2. Определить структуры переменных и базы данных КП.

  3. Разработать методы распределения ресурсов ВС для построения конкретных КП.

  4. Разработать структуры КП надежно функционирующие при наличии ошибок ПС и в аппаратуре.

III. Для реализации сложных КП при решении конкретных задач конкретным коллективом разработчиков необходимо решение технологических задач.

  1. Создание четкой технологической схемы разработки (этапы, ответственные лица, методы контроля количества и качества)

  2. Охват технологической сферы всего жизненного цикла в разработке КП.

  3. Создание или выбор средств и методов автоматизации разработки сложных КП (создание структур базы данных, создание средств автоматизации отладки).

  4. Создание автоматизированных средств подготовки документации.

  5. Стандартизация процессов и средств разработки ПС (например, именование данных одной программы всеми разработчиками одинаково).

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

  1. Создание структур ВС как для разработчика, так и для конечного пользователя (мощность ВС разработчика, как правило, многократно превышает мощность ВС пользователя)

  2. Выбор технологических средств ПС разработки (средств автоматизации, компиляции, отладчиков)

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

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

Будем рассматривать сложные системные программы или КП, предназначенные для решения задач обработки информации в “административных” задачах (АИС) и задач реального масштаба времени (РМВ).

Характерные черты сложных систем:

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

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

  3. Наличие иерархической структуры: подчинение одних компонентов другим (вызов из центральной управляющей части КП ее подсистемы и т.д., наличие иерархических структур данных: например деканат знает всю информацию о студентах).

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

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

6. Устойчивость к возмущениям, вызванным как внутренними, так и внешними причинами.

Для КП: изменение характеристик входных потоков, изменение условий функционирования из - за изменения состава программы и программных средств.

7. Надежность функционирования системы в целом при ненадежном функционировании отдельных компонентов.

8. Наличие целей систем и критерия качества, который определяет достоинства сложных систем.

Функциональность сложной системы определяется алгоритмом ее работы.

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

Программа– алгоритм, заданный на некотором языке, доступной в этой вычислительной системе.

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

4. Особенности кп в срмв.

Программа СРМВ (систем реального масштаба времени) – программа, в которой время используется в качестве одной из текущих переменных, от которой зависит результат.

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

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

Чистыми примерами СРМВ являются управление движущимися объектами (самолеты, подводные лодки, военные объекты), а также многие научные программы, работающие с конкретными установками.

Особые требования к КП СРМВ

1.) Выдача и прием информации на объекте управления.

2.) Исключительно высокие требования к надежности программы (к сбоям и отказам).

3.) Ограничения на временные задержки, часто весьма строгие.

  1. Жизненный цикл сложных КП.

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

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

Реально жизненный цикл близок к каскадной системе.

Затраты

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

6. Понятие резидентных и кросс систем автоматизации.

ИВС – исполнительная вычислительная система

ТВС – технологическая вычислительная система

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

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

Возможны 2 ситуации: когда ИВС и ТВС совпадают, по меньшей мере, на уровне системы команд и когда не совпадают.

В первом случае мы имеем резидент.

Во втором – кросс-системы автоматизации и разработки.

Преимущества первого варианта: прозрачность разработки, отсутствие необходимости создания специализированных средств разработки, простота переноса программного обеспечения. Недостатки: логические ВС, используемые в качестве ИВС могут быть излишне мощными и дорогими.

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

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

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