Введение

1. Введение.

1.1. Принципы системного подхода при создании сложных систем.

Система – совокупность взаимодействующих компонентов и связей между ними.

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

ИС – совокупность:

            - функциональных и информационных процессов конкретной предметной области;

            - средств и методов сбора хранения анализа обработки и передачи информации зависящих от специфики области применения;

            - методов управления процессами решения функциональных задач, а так же информационными материальными и денежными потоками в предметной области.

ИС как АС – это совокупность следующих составных частей:

Рекомендуемые материалы

            - система БД;

            - прикладное ПО;

            - персонал;

            - организационно методическое (нормативное) обеспечение;

            - технические средства.

Проект – временное предприятие, осуществляемое с целью создания уникального продукта или услуги.

Цель проектирования – создание системы, которая:

            - удовлетворяет заданным (возможно неформальным) функциональным спецификациям;

            - согласовано с ограничением, накладываемым оборудованием;

            - удовлетворяет явным и неявным требованиям по эксплуатационным качествам и потреблению ресурсов;

            - удовлетворяет явным и неявным критериям дизайна продукта;

- удовлетворяет требованиям к самому процессу разработки (например, продолжительность и стоимость), а так же привлечение дополнительных инструментальных средств.

К заинтересованным лицам относятся:

- заказчики, которые финансируют проект или приобретают продукт для решения каких то бизнес-задач;

- пользователи, которые взаимодействуют напрямую или не напрямую с приложением;

- аналитики требований, которые пишут требования и отдают их разработчикам;

- разработчики, которые создают, разворачивают  и поддерживают продукт;

- тестеры, которые определяют соответствие поведения АС желаемым;

- технические писатели, которые отвечают за создание руководство пользователей, тренеровочные материалы, справочную систему и рабочую документацию;

            - руководитель проекта (менеджер проекта), который планирует процесс, координирует работу всех участников процесса и руководит командой разработчиков вплоть до успешного выпуска продукта

            - сотрудники правового отдела;

            - сотрудники отдела продаж и маркейтинга.

1.2. Основные проблемы современных проектов.

В конце 60-х годов прошлого века в США было отмечено явление под названием «software crisis » (кризис ПО). Это выра­жалось в том, что большие проекты стали выполняться с отста­ванием от графика или с превышением сметы расходов, разра­ботанный продукт не обладал требуемыми функциональными возможностями, производительность его была низка, качество получаемого программного обеспечения не устраивало потре­бителей.

Аналитические исследования и обзоры, выполняемые в пос­ледние годы ведущими зарубежными аналитиками, показывали не слишком обнадеживающие результаты. Например, результаты исследований, выполненных в 1995 г. компанией Standish Group, которая проанализировала работу 364 американских корпораций и итоги выполнения более 23 тыс. проектов, связанных с разра­боткой ПО, выглядели следующим образом:

• только 16,2% завершились в срок, не превысили запланиро­ванный бюджет и реализовали все требуемые функции и возможности;

• 52,7% проектов завершились с опозданием, расходы превы­сили запланированный бюджет, требуемые функции не бы­ли реализованы в полном объеме;

• 31,1% проектов были аннулированы до завершения;

Для двух последних категорий проектов бюджет среднего проекта оказался превышенным на 89%, а срок выполнения - на 122%.

В 2007 г. процентное соотношение трех перечисленных кате­горий проектов лишь немного изменилось в лучшую сторону (26%, 46% и 28% соответственно).

В последние годы процентное соотношение трех перечислен­ных категорий проектов также незначительно меняется в лучшую сторону, однако, по оценкам ведущих аналитиков, это происхо­дит в основном за счет снижения масштаба выполняемых проек­тов, а не за счет повышения управляемости и качества проекти­рования.

В числе причин возможных неудач, по мнению разработчи­ков, фигурируют:

• нечеткая и неполная формулировка требований к АС;

• недостаточное вовлечение пользователей в работу над про­ектом;

• отсутствие необходимых ресурсов;

• неудовлетворительное планирование и отсутствие грамот­ного управления проектом;

• частое изменение требований и спецификаций;

• новизна и несовершенство используемой технологии;

• недостаточная поддержка со стороны высшего руководства;

• недостаточно высокая квалификация разработчиков, отсут­ствие необходимого опыта.

В последнее время ведущие зарубежные аналитики отмечают как одну из причин многих неудач тот факт, что множество про­ектов выполняется в экстремальных условиях. В англоязычной литературе с легкой руки Эдварда Иордона, одного из ведущих мировых специалистов в данной области, утвердилось название «death march», буквально — «смертельный марш». Под ним пони­мается такой проект, параметры которого отклоняются от нор­мальных значений, по крайней мере, на 50%. По отношению к проектам создания АС это означает наличие одного или более из следующих ограничений:

•       план проекта сжат более чем наполовину по сравнению с нормальным расчетным планом; таким образом, проект, требующий в нормальных условиях 12 календарных месяцев, приходится выполнять за 6 или менее месяцев. Жесткая конкуренция на мировом рынке делает такую ситуацию на­иболее распространенной;

• количество разработчиков уменьшено более чем наполови­ну по сравнению с действительно необходимым для проек­та данного размера и масштаба. На сегодняшний день наи­более общей причиной уменьшения количества разработчи­ков является сокращение штатов компании в результате кризиса, реорганизации и т.д.;

• бюджет и связанные с ним ресурсы урезаны наполовину. За­частую это результат сокращения компании и других проти­возатратных мер, хотя это может быть и результатом конку­рентной борьбы за выгодный контракт. Такое ограничение часто непосредственно влияет на количество нанимаемых разработчиков, однако последствия могут быть и менее яв­ными — например, может быть принято решение привлечь относительно недорогих и неопытных молодых разработчи­ков вместо опытных дорогостоящих специалистов;

• требования к функциям, возможностям, производительнос­ти и другим техническим характеристикам вдвое превыша­ют значения, которые они могли бы иметь в нормальных ус­ловиях.        '

Однако основная причина всех проблем заключается в ответе на вопрос: является ли проектирование АС ремеслом, инженер­ной дисциплиной или чем-то средним?

Можно утверждать, что разработка АС на сегодняш­ний день является почти чистым ремеслом. Современным разработчикам не хва­тает системы основных принципов, на основе которых можно было бы строить свои правила и методы. Замечено, что ключе­вым фактором успеха проекта является хорошая архитектура. Именно неспособность регулярно создавать хорошую архитекту­ру не дает права разработке АС называться сложившейся инже­нерной дисциплиной. Для доказательства адекватности проекта до завершения любых строительных работ инженер, в отличие от программиста, использует систему основных принципов. Разра­ботчик ПО, с другой стороны, при оценке качества архитектуры должен полагаться на тестирование. Он должен искать хорошую архитектуру путем проб и ошибок.

Это объясняет, почему двумя наиболее явными проблемами неудачных программных проектов являются переделка программ и обнаружение негодности проекта на его поздних стадиях. Раз­работчик проектирует архитектуру на ранних стадиях разработки ПО, но не имеет возможности сразу же оценить ее качество. У не­го отсутствуют под рукой основные принципы для доказатель­ства адекватности проекта. Тестирование программного обеспе­чения постепенно выявляет все дефекты архитектуры, но только на поздних стадиях разработки, когда исправление ошибок ста­новится дорогим и разрушительным для проекта.

Почему же идеология проб и ошибок так глубоко проникла в разработку ПО? Для ответа на этот вопрос необходимо понять, что разработка ПО изначально является проектированием и не имеет признаков строительства или производства. Это утверж­дение трудно принять, но оно может быть легко обосновано. Все хорошо понимают, что такое проектирование, где оно заканчива­ется и где начинается строительство или производство. Рассмот­рим два следующих аргумента:

1. Граница между проектированием и строительством всегда четко обозначена чертежом. Проектирование включает в себя все операции, необходимые для создания чертежа, а строительство охватывает все операции, необходимые для создания продуктов по этому чертежу. В идеальном случае чертеж должен определять создаваемый продукт во всех подробностях, что, конечно же, бы­вает очень редко. Тем не менее, целью чертежа является настоль­ко подробное описание конструируемого продукта, насколько это возможно. Описывает ли проект архитектуры программной системы создаваемый продукт «во всех подробностях»? - Нет. Проект архитектуры предназначен для описания существенных, но, безусловно, не всех подробностей программной системы. По­этому очевидно, что проект архитектуры не является чертежом. Все подробности программной системы описываются только кодом на языке высокого уровня, который, таким образом, являет­ся чертежом программы. А поскольку все операции, ведущие к созданию чертежа, являются проектированием, то и вся разра­ботка ПО должна считаться проектированием.

2. Объем работ (время, деньги, ресурсы), необходимый для создания продукта, всегда может быть разделен на проектировоч­ную и производственную составляющие. В чем разница? - Объ­ем работ проектирования является общим для всех копий про­дукта и должен быть затрачен только один раз. Объем работ для производства должен затрачиваться при создании каждой копии продукта. Программный продукт обычно представляет собой двоичный исполняемый файл программы, поставляемой на ком­пакт-диске. Ясно, что усилия по созданию исходного кода прог­раммы, включая проект архитектуры, подробный проект и код на языке высокого уровня, должны быть затрачены лишь однажды, независимо от количества выпущенных копий программного обеспечения. Следовательно, усилия по созданию исходного ко­да программы являются целиком проектировочными, а вся раз­работка ПО является проектированием. ,

Разработчики не строят ПО- они его проектируют. Конеч­ный результат проектирования - код на языке высокого уровня - является чертежом ПО. Компилятор и компоновщик механичес­ки строят программный продукт - двоичный исполняемый файл по этому спроектированному коду.

Под сопровождением в общем случае понимается внесение из­менений в эксплуатируемую АС в целях исп­равления обнаруженных ошибок (корректирующее сопровожде­ние), повышения производительности и улучшения эксплуатаци­онных характеристик системы (совершенствующее сопровожде­ние), а такжеадаптации к изменившейся или изменяющейся сре­де (адаптирующее сопровождение).

При этом более 50% общего объема работ по сопровождению приходится на совершенствую­щее сопровождение. В общих затратах различных организаций и предприятий на ПО доля затрат на сопровождение составляет от 60% до 80% (эта доля является максимальной для крупных госу­дарственных учреждений и частных компаний), и величина этих затрат продолжает расти. Негативными последствиями такого роста являются:  1) неудовлетворенность пользователей из-за большого времени, затрачиваемого на внесение изменений в ПО; 2) снижение качества ПО и 3) сокращение объема новых разрабо­ток в будущем, поскольку все большее количество разработчиков вынуждено переключаться на сопровождение. Так, по оценкам компании Hewlett-Packard, в 1994 г. от 60% до 80% ее разработчи­ков были заняты сопровождением ПО, а в отчетах федеральных служб США ранее отмечалось, что на сопровождение уходит от 50% до 80% рабочего времени программистов. Перечисленные тенденции отражены на рис. В.1.

Первоначально, в 1960 - 1970 гг., в понятие сопровождения ПО входило только исправление ошибок и устранение мелких замечаний пользователей.

1955                1970            1970             2000

                         

  Аппаратура                      Разработка                        Сопровождение

Рис. В.1. Тенденции изменения соотношения стоимости аппаратуры и ПО

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

По мере развития новых технологий стало ясно, что суммар­ные затраты на сопровождение и создание новых версий могут значительно превосходить затраты на разработку первой версии ПО. Действительно, если разработка первой версии сложного ПО продолжается 3 года, а последующая его эксплуатация и соз­дание версий происходит в течение 10 лет, то можно ожидать, что суммарные затраты на этих интервалах времени соизмери­мы. Даже при предположении, что сопровождением и разработ­кой новых версий будет занята половина специалистов, осуще­ствивших создание первых версий, суммарные затраты на эти работы превысят первичные. Опыт последних лет показво многих случаях для развития версий необходимо практически такое же число специалистов, которое разработало первую вер­сию ПО.

1.3. Современные тенденции в программной инженерии.

В начале 2001 г. ряд ведущих специалистов в области програм­мной инженерии (Алистер Коберн, Мартин Фаулер, Джим Хайс-мит, Кент Бек и др.) сформировали группу под назва­нием Agile Alliance. Слово agile (быстрый, ловкий, стремитель­ный) отражало в целом их подход к разработке ПО, основанный на богатом опыте участия в разнообразных проектах в течение многих лет. Этот подход под названием «Быстрая разработка ПО» (Agile software development) базируется на четырех идеях, сфор­мулированных ими в документе «Манифест быстрой разра­ботки ПО» (Agile Alliance's Manifesto) и заключающихся в следу­ющем:

• индивидуумы и взаимодействия между ними ценятся выше процессов и инструментов;

• работающее ПО ценится выше всеобъемлющей документа­ции;

• сотрудничество с заказчиками ценится выше формальных договоров;

• реагирование на изменения ценится выше строгого следо­вания плану.

Центральными для быстрой разработки ПО являются прос­тые, но достаточные правила выполнения проекта, а также ори­ентация на людей и коммуникацию.

При этом следует четко понимать: при всех достоинствах быстрой разработки ПО этот подход не является универсальным и применим только в проектах определенного класса.

Для характе­ристики таких проектов Алистер Коберн ввел два параметра - критичность и масштаб.

Критичность определяется последстви­ями, вызываемыми дефектами в АС, и может иметь один из че­тырех уровней:

• С - дефекты вызывают потерю удобства;

• D - дефекты вызывают потерю возместимых средств (мате­риальных или финансовых);

• Е - дефекты вызывают потерю невозместимых средств;

• L - дефекты создают угрозу человеческой жизни.
Масштаб определяется количеством разработчиков, участву­
ющих в проекте:

• от 1 до 6 человек - малый масштаб;

• от 6 до 20 человек — средний масштаб;

• свыше 20 человек — большой масштаб.

По оценке Коберна, быстрая разработка ПО применима только в проектах малого и среднего масштаба с низкой критич­ностью (С или D). Общие принципы оценки технологий в таких проектах заключаются в следующем:

• интерактивное общение лицом к лицу— это самый дешевый и быстрый способ обмена информацией;

Если Вам понравилась эта лекция, то понравится и эта - 10. Общение по телефону.

• избыточная «тяжесть» технологии стоит дорого;

• более многочисленные команды требуют более «тяжелых» и формальных технологий;

• большая формальность подходит для проектов с большей критичностью;

• возрастание обратной связи и коммуникации сокращает потребность в промежуточных и конечных продуктах;

• дисциплина, умение и понимание противостоят процессу, формальности и документированию;

• потеря эффективности в некритических видах деятельности вполне допустима.