Вопрос 3. Постановка задачи. Оценка осуществимости

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

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

В ТП входит:

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

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

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

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

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

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

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

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

Постановка

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

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

Реализация

Отладка

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

Сдача

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

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

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

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

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

Вопрос 3. Постановка задачи. Оценка осуществимости.

Обычно заказчик выдаёт две-три страницы текста задания и сразу же просит оценить время исполнения заказа и его стоимость. Надо быть сумасшедшим, чтобы с этим согласиться. Не редки случаи, когда целые коллективы ошибаются в пять-десять раз и попадают в кабалу или теряют профессиональную репутацию. Чтобы избежать такой ситуации, нужно предложить заказчику оформить начальный договор на две-четыре недели, с тем, чтобы два-три системных аналитика разобрались в задаче, с помощью каких-то инструментальных средств выполнили декомпозицию системы на компоненты, прикинули возможные объёмы этих компонент и, соответственно, время их реализации. Такая начальная стадия ЖЦП называется "оценкой осуществимости".

Постановка задачи – наиболее творческая часть ЖЦП, которая содержит в себе почти что философские проблемы.

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

Разрешают это противоречие с помощью постепенного уточнения поведения, как системы, так и её окружения (т.е. делают декомпозицию).

Декомпозицию необходимо производить обязательно – лишь она позволяет вычислить более-менее реальные сроки реализации.

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

Например, в технологии REAL разработчикам предлагается использовать следующие типы моделей:

1. Диаграмма случаев использования, в которой описываются интерфейсы системы с внешним миром и основные функции системы, которые за эти интерфейсы отвечаю.

2. Диаграмма функций – для каждой основной функции рисуется дерево более мелких функций.

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

4. Диаграмма классов. В этой диаграмме на основании рассмотрения различных вариантов диаграмм объектов фиксируются типы объектов, которые могут служить основой для генерации многих экземпляров объектов. Соотношение между классом и объектом в точности такое же, как соотношение между типом и значением в языках программирования. Например, real – это тип, а 3.14 и 2.72 – примеры значений этого типа. В диаграмме классов используются мощные выразительные средства (наследование, агрегирование и т.п.), позволяющие минимизировать диаграмму, повышая тем самым её наглядность.

//1-2 – Пользовательская модель

//3-4 – Структурная модель

//1-4 – все это есть в UML, но в UML нет временнЫх моделей. Можно рассмотреть рекомендацию z.120 (ITU): рисуем вертикально время, нити процессов, сообщения. Полезна также STD диаграмма конечных автоматов (состояния; переходы - по сообщениям) – позволяет специфицировать поведение отдельных объектов. Есть также рекомендация z.100 – SDL диаграмма (обычная блок схема, но с сообщениями (прием + отправка)) – позволяет изображать параллельные процессы, а также избежать ошибок при взаимодействии модулей (когда послали сообщение, а его не ждут). Постановка задачи выдает два документа – 1. четкая спецификация + 2. распределение по времени.

Вопрос 4. Планирование.

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

Критический путь – самый длинный путь от начала до конца.

Все ветви должны быть равнонагружены (хотя это тоже плохо – нет резерва).

Если сроки срываются, то либо увеличивать ресурсы, либо раздвигать сроки.

Планирование неразрывно связано с управлением.

Добавлять людей, деньги («стимулирование»). //У МикроМягких же за срыв сроков лишают премии весь коллектив.

Кроме сетевого графика можно также строить диаграмму Ганта:

-По вертикали выписываем работы, по горизонтали – сроки, ставим промежутки исполнения – удобно смотреть, что должно быть завершено в настоящий момент, какие работы идут. //Диаграмма Ганта более удобна при управлении, чем при планировании.

Управление должно быть постепенным, регулярным. Должен быть запас ресурсов.

Если горит работа на критическом пути, то надо сокращать сроки на последующие работы (увеличивать технологии производства).

//Основа всего – ТЕХНИЧЕСКАЯ ВООРУЖЕННОСТЬ