Конспект лекций

Конспект лекций по курсу «Объектно-ориентированный анализи проектирование»Лекция 1. Основы программной инженерииОсновой проектирования программного обеспечения является системный подход.Системный подход – это методология исследования объекта любой природы как системы.Система – это совокупность взаимосвязанных частей, работающих совместнодля достижения некоторого результата.

Определяющий признак системы – поведениесистемы в целом не сводимо к совокупности поведения частей системы.Программное обеспечение – это система, включающая в себя: компьютерныепрограммы; документацию; данные, необходимые для корректной работы программ.Проектирование ПО – это процесс создания спецификаций ПО на основе исходныхтребований к нему.Проект ПО – совокупность спецификаций ПО (включающих модели и проектнуюдокументацию), обеспечивающих создание ПО в конкретной программно-техническойсреде.ПО можно разбить на два класса: «малое» и «большое».«Малое» программное обеспечение имеет следующие характеристики: решает одну несложную, четко поставленную задачу; размер исходного кода не превышает нескольких сотен строк; скорость работы программного обеспечения и необходимые ему ресурсы не играютбольшой роли; ущерб от неправильной работы не имеет большого значения; модернизация программного обеспечения, дополнение его возможностей требуетсяредко; как правило, разрабатывается одним программистом или небольшой группой (5 илименее человек); подробная документация не требуется, ее может заменить исходный код, которыйдоступен.«Большое» программное обеспечение имеет 2-3 или более характеристикиз следующего перечня: решает совокупность взаимосвязанных задач; использование приносит значимую выгоду; удобство его использования играет важную роль; обязательно наличие полной и понятной документации; низкая скорость работы приводит к потерям; сбои, неправильная работа, наносит ощутимый ущерб; программы в составе ПО во время работы взаимодействует с другими программами ипрограммно-аппаратными комплексами; работает на разных платформах; требуется развитие, исправление ошибок, добавление новых возможностей; группа разработчиков состоит из более 5 человек.Далее рассматривается проектирование «большого» ПО, поскольку создание«малого» не вызывает больших трудностей, не требует специальной технологии иинструментов.Классификация программных проектов по размеру группы разработчиков идлительности проекта: небольшие проекты – проектная команда менее 10 человек, срок от 3 до 6 месяцев; средние проекты – проектная команда от 20 до 30 человек, протяженность проекта 12 года;1крупномасштабные проекты – проектная командаот 100 до 300 человек,протяженность проекта 3-5 лет; гигантские проекты – армия разработчиков от 1000 до 2000 человек и более (включаяконсультантов и соисполнителей), протяженность проекта от 7 до 10 лет.С конца 60-х годов прошлого века до сегодняшних дней продолжаетсятак называемый «кризис ПО».

Выражается он в том, что большие проекты выполняютсяс превышением сметы расходов и/или сроков отведенных на разработку, а разработанноеПО не обладает требуемыми функциональными возможностями, имеет низкуюпроизводительность и качество. По результатам исследований американской индустрииразработки ПО, выполненных в 1995 году Standish Group (www.standishgroup.com), только16% проектов завершились в срок, не превысили запланированный бюджет и реализоваливсе требуемые функции и возможности. 53% проектов завершились с опозданием,расходы превысили запланированный бюджет, требуемые функции не были реализованыв полном объеме.

31% проектов были аннулированы до завершения. Для двух последнихкатегорий проектов бюджет среднего проекта оказался превышенным на 89%, а сроквыполнения – на 122%. В последние годы процентное соотношение трех перечисленныхкатегорий проектов незначительно изменяется в лучшую сторону.199519982004200931% аннулируются до завершения28%18%24%53% не укладываются в поставленные сроки,превышают запланированные расходы и нереализуют в полном объеме требуемые функции16% завершаются в срок46%53%44%26%29%32%Причины неудач:нечеткая и неполная формулировка требований;недостаточное вовлечение пользователей в работу над проектом;отсутствие необходимых ресурсов;неудовлетворительное планирование и отсутствие грамотного управления проектом;частое изменение требований и спецификаций;новизна и несовершенство используемой технологии;недостаточная поддержка со стороны высшего руководства;недостаточно высокая квалификация разработчиков, отсутствие необходимого опыта.Проблемы, возникающие при создании программной системы, иллюстрируеткарикатура «Качели» появившаяся в программистском фольклоре в 1970-х.2Первый рисунок (верхний слева) показывает, что заказчик не может толкомсформулировать требования, завышает их.

На втором рисунке (верхнем в середине)демонстрируется, что ответное предложение поставщика не вполне соответствует заявкезаказчика, детали поняты превратно. Аналитик предлагает ошибочную эскизнуюархитектуру (вверху справа). Программисты создают код с ошибками (внизу слева). Послеотладки система введена в действие (внизу в середине). То, что на самом делетребовалось, указано на последнем рисунке (внизу справа).При планировании проектов зачастую по тем или иным причинам устанавливаютсяневыполнимые сроки, закладываются недостаточные ресурсы. Таким образом, возникаютбезнадежные проекты (death march projects)1. Признаки безнадежного проекта: план проекта сжат более чем наполовину по сравнению с нормальным расчетнымпланом; количество разработчиков уменьшено более чем наполовину по сравнениюс действительно необходимым для проекта данного размера и масштаба; бюджет и связанные с ним ресурсы урезаны наполовину; требования к функциям, производительности и другим характеристикам вдвоепревышают значения, которые они могли бы иметь в нормальных условиях.Другой причиной неверного планирования является заблуждение относительнопроизводительности проектировщиков.

В большом проекте общая производительностьгруппы разработчиков не равна сумме производительностей отдельных членов группы(посчитанной как если бы они работали в одиночку). Об этом в книге «Мифическийчеловеко-месяц»2 пишет Фредерик Брукс. Выводы Брукса: самая частая причина провала – нехватка времени; иногда работы нельзя ускорить, не испортив результат; человеко-месяц – опасное заблуждение, поскольку предполагается, что количестволюдей и месяцы можно поменять местами; разделение задачи между несколькими людьми вызывает накладные затраты; если проект не укладывается в срок, то добавление людей задержит его еще больше; «серебряной пули» нет!Последнее положение касается технологии разработки.

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

Как зверь не может освободить из смолы одну лапу, не утопив глубжедругие, так и руководитель проекта может решать одну проблему (например, повышаеткачество ПО) только за счет усугубления других (отладка, шлифовка требуют времени,денег, людей).Особенности современных проектов ПО: сложность – неотъемлемая характеристика создаваемого ПО; отсутствие полных аналогов и высокая доля вновь разрабатываемого ПО; наличие унаследованного ПО и необходимость его интеграции с разрабатываемымПО; территориально распределенная и неоднородная среда функционирования; большое количество участников проектирования, разобщенность и разнородностьотдельных групп разработчиков по уровню квалификации и опыту.Разработка ПО имеет следующие специфические особенности:1Понятие безнадежного проекта введено Эдвардом Йорданом.