ТЕОРИТИЧЕСКАЯ ЧАСТЬ

Вопрос 1. Понятие технологии программирования.

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

В ТП входит:

1. архив с контролируемым доступом (для предотвращения внесения изменений в последний момент (пусть даже и из лучших побуждений), для отчуждения «программы от её автора»)

2. Машинная документация (на машинном носителе) – должна быть актуальна, должны оперативно вноситься исправления

3. Использование инструментальных средств. (в частности программы можно писать и отлаживать на инструментальных ЭВМ, а уже затем транслировать под целевые – тогда возможна параллельная разработка)

4. Соглашение о связях (напр. все рассматривают стек слева направо, возвращают значение через регистр R10 (даже если напр. кто-то вдруг выяснит, что через R7 быстрее), каждая процедура должна сохранять регистры…).

//Нельзя всё сводить только к программному инструментарию.

Вопрос 2. Жизненный цикл программы.

Наша задача, чтобы цикл был конечный.

Первая модель – водопадная (waterfall)(не возвращаемся к предыдущему этапу):

Постановка

Планирование (люди, ресурсы)

Проект (структура, связи)

Реализация

Отладка

Документирование

Сдача

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

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

Циклическая модель с возвратами (если что-то не устраивает, возвращаемся к предыдущим этапам).

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

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