Причины появления программной инженерии
Основой проектирования программного обеспечения является системный подход.
● Системный подход – это методология исследования объекта любой природы как системы.
● Система – это совокупность взаимосвязанных частей, работающих совместно для достижения некоторого результата. Определяющий признак системы – поведение системы в целом не сводимо к совокупности поведения частей системы.
● Программное обеспечение – это система, включающая в себя: компьютерные программы; документацию; данные, необходимые для корректной работы программ.
● Проектирование ПО – это процесс создания спецификаций ПО на основе исходных требований к нему.
● Проект ПО – совокупность спецификаций ПО (включающих модели и проектную документацию), обеспечивающих создание ПО в конкретной программно-технической среде.
ПО можно разбить на два класса: «малое» и «большое».
«Малое» (простое) программное обеспечение имеет следующие характеристики:
● решает одну несложную, четко поставленную задачу;
● размер исходного кода не превышает нескольких сотен строк;
● скорость работы программного обеспечения и необходимые ему ресурсы не играют большой роли;
● ущерб от неправильной работы не имеет большого значения;
● модернизация программного обеспечения, дополнение его возможностей требуется редко;
● как правило, разрабатывается одним программистом или небольшой группой (5 или менее человек);
● подробная документация не требуется, ее может заменить исходный код, который доступен.
«Большое»(сложное) программное обеспечение имеет 2-3 или более характеристик из следующего перечня:
● решает совокупность взаимосвязанных задач;
● использование приносит значимую выгоду;
● удобство его использования играет важную роль;
● обязательно наличие полной и понятной документации;
● низкая скорость работы приводит к потерям;
● сбои, неправильная работа, наносит ощутимый ущерб;
● программы в составе ПО во время работы взаимодействует с другими программами и программно-аппаратными комплексами;
● работает на разных платформах;
● требуется развитие, исправление ошибок, добавление новых возможностей;
● группа разработчиков состоит из более 5 человек.
Далее рассматривается проектирование «большого» ПО, поскольку создание «малого» не вызывает больших трудностей, не требует специальной технологии и инструментов.
Классификация программных проектов по размеру группы разработчиков и длительности проекта:
● небольшие проекты – проектная команда менее 10 человек, срок от 3 до 6 месяцев;
● средние проекты – проектная команда от 20 до 30 человек, протяженность проекта 1-2 года;
● крупномасштабные проекты – проектная команда от 100 до 300 человек, протяженность проекта 3-5 лет;
● гигантские проекты – армия разработчиков от 1000 до 2000 человек и более (включая консультантов и соисполнителей), протяженность проекта от 7 до 10 лет.
С конца 60-х годов прошлого века до сегодняшних дней продолжается так называемый «кризис ПО». Выражается он в том, что большие проекты выполняются с превышением сметы расходов и/или сроков отведенных на разработку, а разработанное ПО не обладает требуемыми функциональными возможностями, имеет низкую производительность и качество. По результатам исследований американской индустрии разработки ПО, выполненных в 1995 году Standish Group (www.standishgroup.com), только 16% проектов завершились в срок, не превысили запланированный бюджет и реализовали все требуемые функции и возможности. 53% проектов завершились с опозданием, расходы превысили запланированный бюджет, требуемые функции не были реализованы в полном объеме. 31% проектов были аннулированы до завершения. Для двух последних категорий проектов бюджет среднего проекта оказался превышенным на 89%, а срок выполнения – на 122%. В последние годы процентное соотношение трех перечисленных категорий проектов незначительно изменяется в лучшую сторону.
31% аннулируются до завершения | 28% | 23% | 18% |
53% не укладываются в поставленные сроки, превышают запланированные расходы и не реализуют в полном объеме требуемые функции | 46% | 49% | 53% |
16% завершаются в срок | 26% | 28% | 29% |
Причины неудач:
● нечеткая и неполная формулировка требований;
● недостаточное вовлечение пользователей в работу над проектом;
● отсутствие необходимых ресурсов;
● неудовлетворительное планирование и отсутствие грамотного управления проектом;
● частое изменение требований и спецификаций;
● новизна и несовершенство используемой технологии;
● недостаточная поддержка со стороны высшего руководства;
● недостаточно высокая квалификация разработчиков, отсутствие необходимого опыта.
При планировании проектов зачастую по тем или иным причинам устанавливаются невыполнимые сроки, закладываются недостаточные ресурсы. Таким образом, возникают безнадежные проекты (death march projects)[1]. Признаки безнадежного проекта:
● план проекта сжат более чем наполовину по сравнению с нормальным расчетным планом;
● количество разработчиков уменьшено более чем наполовину по сравнению с действительно необходимым для проекта данного размера и масштаба;
● бюджет и связанные с ним ресурсы урезаны наполовину;
● требования к функциям, производительности и другим характеристикам вдвое превышают значения, которые они могли бы иметь в нормальных условиях.
Другой причиной неверного планирования является заблуждение относительно производительности проектировщиков. В большом проекте общая производительность группы разработчиков не равна сумме производительностей отдельных членов группы (посчитанной как если бы они работали в одиночку). Об этом в книге «Мифический человеко-месяц»[2] пишет Фредерик Брукс. Выводы Брукса:
● самая частая причина провала – нехватка времени;
● иногда работы нельзя ускорить, не испортив результат;
● человеко-месяц – опасное заблуждение, поскольку предполагается, что количество людей и месяцы можно поменять местами;
● разделение задачи между несколькими людьми вызывает накладные затраты;
● если проект не укладывается в срок, то добавление людей задержит его еще больше;
● «серебряной пули» нет!
Последнее положение касается технологии разработки. Брукс утверждает, что технологии, позволяющей на порядок повысить производительность разработчиков, не существует. То есть, нельзя полагать, что какая-либо новейшая технология разработки позволит осуществить проект в 10 раз быстрее.
Особенности современных проектов ПО:
● сложность – неотъемлемая характеристика создаваемого ПО;
● отсутствие полных аналогов и высокая доля вновь разрабатываемого ПО;
● наличие унаследованного ПО и необходимость его интеграции с разрабатываемым ПО;
● территориально распределенная и неоднородная среда функционирования;
● большое количество участников проектирования, разобщенность и разнородность отдельных групп разработчиков по уровню квалификации и опыту.
Разработка ПО имеет следующие специфические особенности:
● неформальный характер требований к ПО и формализованный основной объект разработки – программы;
● творческий характер разработки;
● дуализм ПО, которое, с одной стороны, является статическим объектом – совокупностью текстов, с другой стороны, – динамическим, поскольку при эксплуатации порождаются процессы обработки данных;
● при своем использовании (эксплуатации) ПО не расходуется и не изнашивается;
● «неощутимость», «воздушность» ПО, что подталкивает к безответственному переделыванию, поскольку легко стереть и переписать, чего не сделаешь при проектировании зданий и аппаратуры.
Путем выхода из кризиса ПО стало создание программной инженерии (software engineering). Инженерия ПО (software engineering) – совокупность инженерных методов и средств создания ПО. Фундаментальная идея программной инженерии: проектирование ПО является формальным процессом, который можно изучать и совершенствовать.
Освоение и правильное применение методов и средств программной инженерии позволяет повысить качество, обеспечить управляемость процесса проектирования.
Этапы становления и развития SE:
● 70-е и 80-е годы – систематизация и стандартизация процессов создания ПО (структурный подход)
● 90-е годы – начало перехода к сборочному, индустриальному способу создания ПО (объектно-ориентированный подход)
Программная инженерия применяется для удовлетворения требований заказчика ПО. Основные цели программной инженерии:
● Системы должны создаваться в короткие сроки и соответствовать требованиям заказчика на момент внедрения.
● Качество ПО должно быть высоким.
● Разработка ПО должна быть осуществлена в рамках выделенного бюджета.
● Системы должны работать на оборудовании заказчика, а также взаимодействовать с имеющимся ПО.
● Системы должны быть легко сопровождаемыми и масштабируемыми.
Жизненный цикл ПО
Дата добавления: 2021-05-28; просмотров: 367;