ПО с большим и малым временем жизни

Лекция 2

Определение ЖЦ ПО

Жизненный цикл ПО (ЖЦ ПО) - ϶ᴛᴏ непрерывный и упорядоченный набор видов деятельности, осуществляемый и управляемый в рамках каждого проекта по разработке и эксплуатации ПО, начинающийся с момента появления идеи(замысла) создания некоторого программного обеспечения и принятия решения о крайне важности его создания и заканчивающийся в момент его полного изъятия из эксплуатации по причинам:

а) морального старения;

б) потери крайне важности решения соответствующих задач.

Технологические подходы - ϶ᴛᴏ механизмы реализации жизненного цикла.

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

Стадии ЖЦ ПО

ЖЦ определяет стадии(фазы, этапы), так что программный продукт переходит с одного этапа на другой, начиная с зарождения концепции продукта и заканчивая этапом его сворачивания.

ЖЦ разработки ПО должна быть представлен с различной степенью детализации этапов.

Простейшее представление жизненного цикла, включаетстадии:

-Анализ

-Проектирование

-Реализация

-Тестирование и отладка

-Внедрение, эксплуатация и сопровождение.

- Завершение эксплуатации

Задачи этапов

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

Этап анализа концентрируется на системных требованиях. Требования определяются и специфицируются (описываются). Осуществляется выработка и интеграция функциональных моделлей и моделей данных для системы. Вместе с тем, фиксируются нефункциональные и другие системные требования.

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

Этап реализации включает написание программы.

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

Распределение затрат по стадиям ЖЦ

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

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

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

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

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

Лекция 3

Модели жизненного цикла

ПО Стандарт ISO/IEC 12207 не предлагает конкретную модель ЖЦ и методы разработки ПО (.Модель ЖЦ зависит от специфики ИС и условий, в которых последняя создается и функционирует). Его регламенты являются общими для любых моделей ЖЦ, методологий и технологий разработки. Стандарт ISO/IEC 12207 описывает структуру процессов ЖЦ ПО, но не конкретизирует в деталях, как реализовать или выполнить действия и задачи, включенные в эти процессы.

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

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

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

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

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

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

Концептуальный проект

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

ПРимер:

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

Концептуальный проект не зависит от архитектуры!

3. Выбор архитектуры - выбор модели доступа к данным (файл-сервер, сервер-БД, сервер-приложение, доступ к данным по Internet/Intarnet)

- выбор комплекса технических средств (выбор «железа»)

- выбор общесистемных пакетов

-выбор способа тиражирования данных

Логическое проектирование

Выполняется отражение концептуального проекта в СУБД-ориентированную среду с помощью выбранных оболочек программирования. Сущности преобразуются в таблицы, а на основе спецификации задач разрабатываются тексты программ

Логический проект зависит от архитектуры (можно считать временные характеристики)

Отладка

Результаты проектирования БД и приложений объединяются. В итоге разрабатывается пилотный проект системы

Сопровождение

Выявление ошибок и их устранение, модернизация.

Достоинства каскадной модели:

- проста, естественна, имеет некоторую привязку к ГОСТу

Недостатки:

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

- доработка системы связана с большим объемом перепрограммирования (из-за слабого использования CASE-средств)

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

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

Спиральная модель

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

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

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

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

План составляется на основе статистических данных, полученных в предыдущих проектах, и личного опыта разработчиков.

Каждый этап реализуется CASE-средствами. Содержание этапов совпадает с аналогичными в каскадной модели, но в отличие от нее, этапы реализуются с помощью CASE-средств (Computer Aided Software System Design) – (автоматизированная технология создания программных информационных систем) – использование этих средств позволяет существенно снизить время реализации витка спирали проектирования

подсистем (в этом состоит основное преимущество спиральной модели), но это профессиональные средства, непредназначенные для конечных пользователей.

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

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

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

Подход rad

Одним из возможных подходов к разработке прикладного ПО в рамках спиральной модели ЖЦ является получивший широкое распространение способ так называемой быстрой разработки приложений, или RAD (Rapid Application Development). RAD предусматривает наличие трех составляющих:

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

- короткого, но тщательного проработанного производственного графика (до 3 месяцев);

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

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

ЖЦ ПО в соответствии с подходом RAD включает 4 стадии:

1. Анализ и планирование требований предусматривает действия:

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

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

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

Кроме того, на данной стадии реализуются следующие задачи:

- ограничивается масштаб времени;

- устанавливаются временные рамки для каждой из последующих стадий.

Определяется сама возможность реализации проекта в заданных рамках финансирования, на имеющихся аппаратных средствах.

Результатом стадии должны быть список расставленных по приоритету функций будущего ПО ЭИС и предварительные модели ПО.

Проектирование.

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

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

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

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

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

- определяется состав необходимой документации.

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

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

- входной элемент приложения (входной документ или экранная форма);

- выходной элемент приложения (отчет, документ, экранная форма)

- запрос (пара «вопрос/ответ»);

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

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

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

Результатом данной стадии должно быть:

- общая информационная модель системы;

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

- точно определенные интерфейсы между автономно разрабатываемыми подсистемами;

- построенные прототипы экранных форм, отчетов, диалогов.

Реализация.

На этой стадии выполняется непосредственно сама быстрая разработка приложения.

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

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

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

Реализация системы завершается выполнением следующих работ:

- осуществляется анализ использования данных и определяется необходимость их распределения;

- Производится физическое проектирование базы данных;

- формируются требования к аппаратным ресурсам;

- устанавливаются способы увеличения производительности;

- завершается разработка документации проекта.

Результатом стадии является готовая система, удовлетворяющая всем согласованным требованиям.

Внедрение.

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

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

- разрабатывается совершенно новая система;

- уже было проведено обследование организации и существует модель ее деятельности;

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

Следует отметить, что подход RAD, как и любой другой подход, не может претендовать на универсальность. Он хорош в первую очередь для относительно небольших проектов, разрабатываемых для конкретного заказчика. Если же разрабатывается крупномасштабная система (например, масштаба отрасли), которая не является законченным продуктом, а представляет собой комплекс программных компонентов, адаптируемых к программно-аппаратным платформам, системам управления базами данных (СУБД), средствам телекоммуникаций, то на первый план выступают такие показатели проекта как управляемость и качество, которые могут войти в противоречие с простотой и скоростью разработки. Для таких проектов необходимы высокий уровень планирования и жесткая дисциплина проектирования, строгое следование заранее разработанным протоколам и интерфейсам, что снижает скорость разработки.

Подход RAD не применим для построения сложных расчетных программ, операционных систем.

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

Лекция 2

Определение ЖЦ ПО

Жизненный цикл ПО (ЖЦ ПО) - ϶ᴛᴏ непрерывный и упорядоченный набор видов деятельности, осуществляемый и управляемый в рамках каждого проекта по разработке и эксплуатации ПО, начинающийся с момента появления идеи(замысла) создания некоторого программного обеспечения и принятия решения о крайне важности его создания и заканчивающийся в момент его полного изъятия из эксплуатации по причинам:

а) морального старения;

б) потери крайне важности решения соответствующих задач.

Технологические подходы - ϶ᴛᴏ механизмы реализации жизненного цикла.

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

Стадии ЖЦ ПО

ЖЦ определяет стадии(фазы, этапы), так что программный продукт переходит с одного этапа на другой, начиная с зарождения концепции продукта и заканчивая этапом его сворачивания.

ЖЦ разработки ПО должна быть представлен с различной степенью детализации этапов.

Простейшее представление жизненного цикла, включаетстадии:

-Анализ

-Проектирование

-Реализация

-Тестирование и отладка

-Внедрение, эксплуатация и сопровождение.

- Завершение эксплуатации

Задачи этапов

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

Этап анализа концентрируется на системных требованиях. Требования определяются и специфицируются (описываются). Осуществляется выработка и интеграция функциональных моделлей и моделей данных для системы. Вместе с тем, фиксируются нефункциональные и другие системные требования.

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

Этап реализации включает написание программы.

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

ПО с большим и малым временем жизни

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

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

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

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

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