ПРОЕКТИРОВАНИЕ ПО ИС

применение определенного систематического измеримого подхода при разработке, эксплуатации и поддержке

программного обеспечения .
1958 – всемирно известный статистик Джон Тьюкей (John Tukey) ввел термин software (программное обеспечение, ПО)
1968 – термин software engineering (программная инженерия) впервые появился в названии конференции НАТО, состоявшейся в Германии и посвященной так называемому кризису программного обеспечения
1990 – 1995 – работа над международным стандартом, который должен был дать единое представление о процессах разработки программного обеспечения. В результате был выпущен стандарт ISO/IEC 12207
2004 – создан основополагающий труд «Руководство к своду знаний по программной инженерии» (SWEBOK) , в котором были собраны основные теоретические и практические знания, накопленные в этой отрасли

инженерии
Документ создан ACM (Association for Computing Machinery) и IEEE

Computer Society в 2004 г. (начало работ в 1993 г.)

SWEBOK

Назначение SWEBOK - объединение знаний по инженерии программного обеспечения (разработке программного обеспечения), определение и систематизация тех аспектов деятельности, которые составляют суть профессии инженера-программиста
Кодекс этики и профессиональной практики в области разработки ПО
Консенсус ведущих представителей индустрии и признанных авторитетов в области программной инженерии (SAP, Boeing)

Software design – дизайн (архитектура)
Software construction – конструирование программного

обеспечения
Software testing - тестирование
Software maintenance – эксплуатация (поддержка) программного обеспечения
Software configuration management – конфигурационное управление
Software engineering management – управление в программной инженерии
Software engineering process – процессы программной инженерии
Software engineering tools and methods – инструменты и методы
Software quality – качество программного обеспечения

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

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

цикла системы и жизненного цикла разработки программного обеспечения.

Acquisition
Разработка – Development
Поставка – Supply
Эксплуатация – Operation

Сопровождение – Maintenance
• Вспомогательные (Supporting)
Документирование – Documentation
Управление конфигурацией – Configuration Management
Обеспечение качества – Quality Assurance
Верификация – Verification
Аттестация – Validation
Аудит – Audit
Решение проблем – Problem Resolution
• Организационные (Organizational)
Управление – Management
Создание инфраструктуры – Infrastructure
Усовершенствование – Improvement
Обучение - Training

Cycle Model, SLCM) –
структура, состоящая из процессов, работ и

задач, включающих в себя разработку, эксплуатацию и сопровождение программного продукта, охватывающая жизнь системы от установления требований к ней до прекращения ее использования [ГОСТ 12207, 1999].
Как и всякая другая, модель жизненного цикла является абстракцией реального процесса, в которой опущены детали, несущественные с точки зрения назначения модели.
ИДЕАЛЬНОЙ SLCM-МОДЕЛИ НЕ СУЩЕСТВУЕТ!

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

85 г.г.)

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

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

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

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

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

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

технические нормативные правовые акты

смешанная)» (86 – 90 г.г.) – эффективная альтернатива методу «водопада».
Классическая

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

and Incremental Development, IID), также названная эволюционной моделью, предполагает разбиение

жизненного цикла проекта на последовательность итераций, «мини-проектов» с теми же процессами разработки для меньших фрагментов функциональности по сравнению с проектом в целом.
Цель каждой итерации – получение работающей версии программной системы, включающей функциональность, определенную интегрированным содержанием всех предыдущих и текущей итерации. Результат финальной итерации содержит всю требуемую функциональность.
Таким образом, с завершением каждой итерации продукт получает приращение – инкремент – к его возможностям, которые, следовательно, развиваются эволюционно. Итеративность, инкрементальность и эволюционность в данном случае есть выражение одного и то же смысла разными словами со слегка разных точек зрения.

основе организации итераций особо проявляется в снижении неопределенности с завершением

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

у ее пользователей неприятие и «затормозить» переход на новые технологии.

Они могут «не переварить большой кусок, поэтому его надо измельчить и давать по частям».

рисков на ранних стадиях проекта, пока это еще можно сделать

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

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

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

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

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

90 г.г.) – наиболее известный и распространенный вариант эволюционной модели,

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

разработке новаторских (нетиповых) систем. В начале работы над проектом у

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

лишь на последнем витке спирали по обычной каскадной модели, однако

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

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

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

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

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

перспективах развития проекта
затруднены операции временного и ресурсного планирования всего

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