Помощничек
Главная | Обратная связь


Археология
Архитектура
Астрономия
Аудит
Биология
Ботаника
Бухгалтерский учёт
Войное дело
Генетика
География
Геология
Дизайн
Искусство
История
Кино
Кулинария
Культура
Литература
Математика
Медицина
Металлургия
Мифология
Музыка
Психология
Религия
Спорт
Строительство
Техника
Транспорт
Туризм
Усадьба
Физика
Фотография
Химия
Экология
Электричество
Электроника
Энергетика

Лекция 1.1 Основные особенности современных проектов программного обеспечения (ПО), характеристики различных классов проектов



Вопросы к экзамену по дисциплине «Объектно-ориентированное программирование информационных систем»

  1. Отличие комплексного программного продукта от программы
  2. Перечень неотъемлемых свойств ПО: Сложность, согласованность, изменяемость, незримость
  3. Характеристики объекта внедрения
  4. Особенность современных крупномасштабных проектов программных систем
  5. Технические характеристики проектов создания ПО
  6. Организационные характеристики проектов создания ПО
  7. Case – технологии анализа и проектирования систем.
  8. Основные функции возможности Case –средств
  9. Сущность и основные методологии структурного анализа и проектирования
  10. Стандарт ISO/IEC 12207 (Information Technology - Software Life Cycle Processes)
  11. Практическое применение стандарта ISO/IEC 12207.
  12. Модели жизненного цикла ПО.
  13. Анализ и проектирование ПО на основе объектно-ориентированного подхода.
  14. Сущность объектно-ориентированного подхода.
  15. Основные средства языкаUML.
  16. Диаграммы взаимодействия. Общие сведения. Назначение и состав диаграммы кооперации
  17. Назначение и состав диаграммы последовательности
  18. Рекомендации по разработке диаграмм взаимодействия.
  19. Примеры построения диаграмм взаимодействия. Пакеты
  20. Назначение и состав диаграммы деятельности
  21. Правила и рекомендации по разработке диаграммы деятельности
  22. Примеры построения диаграмм деятельности
  23. Диаграмма состояний. Способы детализации вариантов использования
  24. Назначение и состав диаграммы состояний
  25. Правила и рекомендации по разработке диаграмм состояний
  26. Примеры построения диаграмм состояний
  27. Сравнительная характеристика CASE-средств.

КОНСПЕКТЫ ЛЕКЦИЙ

РАЗДЕЛ 1. ПРОЕКТИРОВАНИЕ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

Лекция 1.1 Основные особенности современных проектов программного обеспечения (ПО), характеристики различных классов проектов

Вендров

Индустрия ПО начала зарождаться в середине 50-х годов XIX в., однако почти до конца 60-х ей не уделялось серьезного внимания, поскольку ее доля в компьютерном бизнесе была слишком мала. В 1970 г годовой оборот всех фирм-разработчиков ПО вСША не превышал 1/2 млрд долл. — около 3,7% всего оборота компьютерного бизнеса. Серьезный рост начался в 70-х годах XX в., начиная с принятого фирмой IBM в 1969 г. решения о развязывании цен (раздельном назначении цен на аппаратуру, ПО и услуги), и продолжился до конца декады и появления персонального компьютера. К1979 г. годовой объем продаж фирм-разработчиков ПО в США составлял около $2 млрд. В 80-х годах рост составлял 20% в год и более, таким образом, годовые доходы фирм выросли до $10 млрд. к 1982 г. и $25 млрд. к 1985 г Сегодня общий объем продаж ПО превышает $100 млрд. Производство ПО сегодня

— крупнейшая отрасль мировой экономики, в которой занято около трех миллионов специалистов, называющих себя профаммистами, разработчиками ПО и т.п. Еще несколько миллионов человек занимают рабочие места, напрямую зависящие от благополучия корпоративных информационных подразделений либо от производителей ПО, таких, как корпорации Microsoft или IBM.

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

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

Чтобы понять принципиальные отличия сложного ПО от обычной программы, рассмотрим рис. В.1.

Рис В.1. Отличие комплексного программного продукта от программы

 

В левом верхнем углу рисунка находится программа. Она является завершенным продуктом, пригодным для запуска только своим автором и только в той системе, где она была разработана.

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

в нее различные изменения. Она может использоваться в различных операционных системах и с различными данными.

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

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

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

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

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

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

может увеличиться, если в системе много компонентов.

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

В 1975 г Фредерик Брукс, проанализировав свой уникальный по тем временам опыт руководства крупнейшим проектом разработки операционной системы OS/360, определил перечень неотъемлемых свойств ПО: сложность, согласованность, изменяемость и незримость.

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

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

на порядки величин превышает количество состояний компьютеров.

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

Сложность ПО является существенным, а не второстепенным свойством. Поэтому попытки описания программных объектов, абстрагируясь от их сложности, приводят к абстрагированию и от их сущности. Математика и физика за три столетия достигли

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

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

надежности. Сложность структуры затрудняет развитие ПО и добавление новых функций.

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

Изменяемость. ПОпостоянно подвержено изменениям. Конечно, это относится и к зданиям, автомобилям, компьютерам. Но произведенные вещи редко подвергаются изменениям после изготовления. Их заменяют новые модели, или существенные изменения

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

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

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

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

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

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

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

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

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

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

Современные крупномасштабные проекты программных систем характеризуются, как правило, особенностями, представленными на рис. В.2.

Рис. В.2 Особенности современных крупномасштабных проектов программных систем

Характеристики объекта внедрения:

• структурная сложность (многоуровневая иерархическая структура организации) и территориальная распределенность;

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

• информационная сложность (большое количество источников и потребителей информации (министерства и ведомства, местные органы власти, организации_партнеры), разнообразные формы и форматы представления информации, сложная информационная модель объекта – большое количество информационных сущностей и сложные взаимосвязи между ними), сложная технология прохождения документов;

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

Технические характеристики проектов создания ПО:

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

• высокая техническая сложность, определяемая наличием совокупности тесно взаимодействующих компонентов (подсистем),имеющих свои локальные задачи и цели

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

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

• большое количество и высокая стоимость унаследованных приложений (существующего прикладного ПО), функционирующих в различной среде (персональные компьютеры, миникомпьютеры, мэйнфреймы), необходимость интеграции унаследованных и вновь разрабатываемых приложений;

• большое количество локальных объектов внедрения, территориально распределенная и неоднородная среда функционирования (СУБД, операционные системы, аппаратные платформы);

• большое количество внешних взаимодействующих систем различных организаций с

различными форматами обмена информацией (налоговая служба, налоговая полиция, Госстандарт, Госкомстат, Министерство финансов, МВД, местная администрация).

Организационные характеристики проектов создания ПО:

• различные формы организации и управления проектом: централизованно управляемая разработка тиражируемого ПО, экспериментальные пилотные проекты, инициативные разработки, проекты с участием как собственных разработчиков, так и сторонних компаний на контрактной основе;

• большое количество участников проекта как со стороны заказчиков (с разнородными

требованиями), так и со стороны разработчиков (более 100 человек), разобщенность и разнородность отдельных групп разработчиков по уровню квалификации, сложившимся традициям и опыту использования тех или иных инструментальных средств;

• значительная длительность жизненного цикла системы, в том числе значительная временная протяженность проекта, обусловленная масштабами организации_заказчика, различной степенью готовности отдельных ее подразделений к внедрению ПО и нестабильностью финансирования проекта;

• высокие требования со стороны заказчика к уровню технологической зрелости организаций_разработчиков (наличие сертификации в соответствии с международными и

отечественными стандартами).

Дополнение с журнала

Накопленный к настоящему времени опыт создания систем ПО показывает, что это сложная и трудоемкая работа, требующая высокой квалификации участвующих в ней специалистов.

Однако до настоящего времени создание таких систем нередко выполняется на интуитивном уровне с применением неформализованных методов, основанных на искусстве, практическом опыте, экспертных оценках и дорогостоящих экспериментальных проверках качества функционирования ПО. По данным Института программной инженерии (Software Engineering Institute, SEI) в последние годы до 80% всего эксплуатируемого ПО разрабатывалось вообще без использования какой_либо дисциплины проектирования, методом «code and fix» (кодирования и исправления ошибок).

Проблемы создания ПО следуют из его свойств. Еще в 1975 г. Фредерик Брукс, проана

лизировав свой уникальный по тем временам опыт руководства крупнейшим проектом разра_

ботки операционной системы OS/360, определил перечень неотъемлемых свойств ПО: слож_

ность, согласованность, изменяемость и незримость [Брукс_99]. Что же касается современных крупномасштабных проектов ПО, то они характеризуются, как правило, следующими особенностями:

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

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

Так, например, результаты исследований, выполненных в 1995 году компанией Standish

Group, которая проанализировала работу 364 американских корпораций и итоги выполнения

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

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

• 52,7% проектов завершились с опозданием,

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

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

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

В 1998 году процентное соотношение трех перечисленных категорий проектов лишь не_

много изменилось в лучшую сторону (26%, 46% и 28% соответственно).

В последние годы процентное соотношение трех перечисленных категорий проектов

также незначительно изменяется в лучшую сторону, однако, по оценкам ведущих аналитиков,

это происходит в основном за счет снижения масштаба выполняемых проектов, а не за счет

повышения управляемости и качества проектирования.

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

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

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

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

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

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

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

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

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

Объективная потребность контролировать процесс разработки сложных систем ПО,

прогнозировать и гарантировать стоимость разработки, сроки и качество результатов привела

в конце 60_х годов прошлого века к необходимости перехода от кустарных к индустриальным способам создания ПО и появлению совокупности инженерных методов и средств создания ПО, объединенных общим названием «программная инженерия» (software engineering). В основе программной инженерии лежит одна фундаментальная идея: проектирование ПО явлется формальным процессом, который можно изучать и совершенствовать. Освоение и правильное применение методов и средств создания ПО позволяет повысить его качество, обеспечить управляемость процесса проектирования ПО и увеличить срок его жизни.

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

специалисты в индустрии ПО пришли к пониманию, что фундаментальная проблема в этой области – неспособность эффективного управления проектами создания ПО. Невозможно до_

стичь удовлетворительных результатов от применения даже самых совершенных технологий

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

необходимой квалификацией для работы с ними, и сам проект выполняется и управляется ха_

отически, в режиме «тушения пожара». Бессистемное применение технологий создания ПО

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

вии с моделью SEI СММ (Capability Maturity Model), в хорошо подготовленной (зрелой) орга

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

Одна из причин распространенности «хаотического» процесса создания ПО – стремление сэкономить на стадии разработки, не затрачивая времени и средств на обучение разработчиков и внедрение технологического процессасоздания ПО. Эти затраты до недавнего времени были довольно значительными и составляли, по различным оценкам (в частности, Gartner Group), более $100 тыс. и около трех лет на вне дрение развитой ТС ПО, охватывающей большинство процессов жизненного цикла ПО, в многочисленной команде разработчиков (до 100 чел.). Причина – в «тяжести» технологических процессов. «Тяжелый» процесс обладает следующими особенностями:

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

• множество рабочих продуктов (в первую очередь – документов), создаваемых в бюрократической атмосфере;

• отсутствие гибкости;

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

Альтернативой «тяжелому» процессу является адаптивный (гибкий) процесс, основанный на принципах «быстрой разработки ПО»,итенсивно развиваемых в последнее десятилетие.

 




Поиск по сайту:

©2015-2020 studopedya.ru Все права принадлежат авторам размещенных материалов.