КАТЕГОРИИ: Архитектура-(3434)Астрономия-(809)Биология-(7483)Биотехнологии-(1457)Военное дело-(14632)Высокие технологии-(1363)География-(913)Геология-(1438)Государство-(451)Демография-(1065)Дом-(47672)Журналистика и СМИ-(912)Изобретательство-(14524)Иностранные языки-(4268)Информатика-(17799)Искусство-(1338)История-(13644)Компьютеры-(11121)Косметика-(55)Кулинария-(373)Культура-(8427)Лингвистика-(374)Литература-(1642)Маркетинг-(23702)Математика-(16968)Машиностроение-(1700)Медицина-(12668)Менеджмент-(24684)Механика-(15423)Науковедение-(506)Образование-(11852)Охрана труда-(3308)Педагогика-(5571)Полиграфия-(1312)Политика-(7869)Право-(5454)Приборостроение-(1369)Программирование-(2801)Производство-(97182)Промышленность-(8706)Психология-(18388)Религия-(3217)Связь-(10668)Сельское хозяйство-(299)Социология-(6455)Спорт-(42831)Строительство-(4793)Торговля-(5050)Транспорт-(2929)Туризм-(1568)Физика-(3942)Философия-(17015)Финансы-(26596)Химия-(22929)Экология-(12095)Экономика-(9961)Электроника-(8441)Электротехника-(4623)Энергетика-(12629)Юриспруденция-(1492)Ядерная техника-(1748) |
Причины появления программной инженерии
Основой проектирования программного обеспечения является системный подход. ● Системный подход – это методология исследования объекта любой природы как системы. ● Система – это совокупность взаимосвязанных частей, работающих совместно для достижения некоторого результата. Определяющий признак системы – поведение системы в целом не сводимо к совокупности поведения частей системы. ● Программное обеспечение – это система, включающая в себя: компьютерные программы; документацию; данные, необходимые для корректной работы программ. ● Проектирование ПО – это процесс создания спецификаций ПО на основе исходных требований к нему. ● Проект ПО – совокупность спецификаций ПО (включающих модели и проектную документацию), обеспечивающих создание ПО в конкретной программно-технической среде. ПО можно разбить на два класса: «малое» и «большое». «Малое» (простое) программное обеспечение имеет следующие характеристики: ● решает одну несложную, четко поставленную задачу; ● размер исходного кода не превышает нескольких сотен строк; ● скорость работы программного обеспечения и необходимые ему ресурсы не играют большой роли; ● ущерб от неправильной работы не имеет большого значения; ● модернизация программного обеспечения, дополнение его возможностей требуется редко; ● как правило, разрабатывается одним программистом или небольшой группой (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%. В последние годы процентное соотношение трех перечисленных категорий проектов незначительно изменяется в лучшую сторону.
Причины неудач: ● нечеткая и неполная формулировка требований; ● недостаточное вовлечение пользователей в работу над проектом; ● отсутствие необходимых ресурсов; ● неудовлетворительное планирование и отсутствие грамотного управления проектом; ● частое изменение требований и спецификаций; ● новизна и несовершенство используемой технологии; ● недостаточная поддержка со стороны высшего руководства; ● недостаточно высокая квалификация разработчиков, отсутствие необходимого опыта. При планировании проектов зачастую по тем или иным причинам устанавливаются невыполнимые сроки, закладываются недостаточные ресурсы. Таким образом, возникают безнадежные проекты (death march projects)[1]. Признаки безнадежного проекта: ● план проекта сжат более чем наполовину по сравнению с нормальным расчетным планом; ● количество разработчиков уменьшено более чем наполовину по сравнению с действительно необходимым для проекта данного размера и масштаба; ● бюджет и связанные с ним ресурсы урезаны наполовину; ● требования к функциям, производительности и другим характеристикам вдвое превышают значения, которые они могли бы иметь в нормальных условиях. Другой причиной неверного планирования является заблуждение относительно производительности проектировщиков. В большом проекте общая производительность группы разработчиков не равна сумме производительностей отдельных членов группы (посчитанной как если бы они работали в одиночку). Об этом в книге «Мифический человеко-месяц»[2] пишет Фредерик Брукс. Выводы Брукса: ● самая частая причина провала – нехватка времени; ● иногда работы нельзя ускорить, не испортив результат; ● человеко-месяц – опасное заблуждение, поскольку предполагается, что количество людей и месяцы можно поменять местами; ● разделение задачи между несколькими людьми вызывает накладные затраты; ● если проект не укладывается в срок, то добавление людей задержит его еще больше; ● «серебряной пули» нет! Последнее положение касается технологии разработки. Брукс утверждает, что технологии, позволяющей на порядок повысить производительность разработчиков, не существует. То есть, нельзя полагать, что какая-либо новейшая технология разработки позволит осуществить проект в 10 раз быстрее. Особенности современных проектов ПО: ● сложность – неотъемлемая характеристика создаваемого ПО; ● отсутствие полных аналогов и высокая доля вновь разрабатываемого ПО; ● наличие унаследованного ПО и необходимость его интеграции с разрабатываемым ПО; ● территориально распределенная и неоднородная среда функционирования; ● большое количество участников проектирования, разобщенность и разнородность отдельных групп разработчиков по уровню квалификации и опыту. Разработка ПО имеет следующие специфические особенности: ● неформальный характер требований к ПО и формализованный основной объект разработки – программы; ● творческий характер разработки; ● дуализм ПО, которое, с одной стороны, является статическим объектом – совокупностью текстов, с другой стороны, – динамическим, поскольку при эксплуатации порождаются процессы обработки данных; ● при своем использовании (эксплуатации) ПО не расходуется и не изнашивается; ● «неощутимость», «воздушность» ПО, что подталкивает к безответственному переделыванию, поскольку легко стереть и переписать, чего не сделаешь при проектировании зданий и аппаратуры. Путем выхода из кризиса ПО стало создание программной инженерии (software engineering). Инженерия ПО (software engineering) – совокупность инженерных методов и средств создания ПО. Фундаментальная идея программной инженерии: проектирование ПО является формальным процессом, который можно изучать и совершенствовать. Освоение и правильное применение методов и средств программной инженерии позволяет повысить качество, обеспечить управляемость процесса проектирования. Этапы становления и развития SE: ● 70-е и 80-е годы – систематизация и стандартизация процессов создания ПО (структурный подход) ● 90-е годы – начало перехода к сборочному, индустриальному способу создания ПО (объектно-ориентированный подход) Программная инженерия применяется для удовлетворения требований заказчика ПО. Основные цели программной инженерии: ● Системы должны создаваться в короткие сроки и соответствовать требованиям заказчика на момент внедрения. ● Качество ПО должно быть высоким. ● Разработка ПО должна быть осуществлена в рамках выделенного бюджета. ● Системы должны работать на оборудовании заказчика, а также взаимодействовать с имеющимся ПО. ● Системы должны быть легко сопровождаемыми и масштабируемыми.
Дата добавления: 2014-01-05; Просмотров: 2392; Нарушение авторских прав?; Мы поможем в написании вашей работы! Нам важно ваше мнение! Был ли полезен опубликованный материал? Да | Нет |