1. Модели жизненного цикла программных систем.

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

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

• каскадная модель;

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

•  спиральная модель .

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

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

2. Методы усовершенствования процесса разработки ПО (CMM, ISO 9000, ISO 20000).

CMM (Capability Maturity Model) описывает модель зрелости процессов разработки программного обеспечения на предприятиях. В рамках этой модели для каждой компании может быть сопоставлен некоторый уровень (один из пяти возможных), свидетельствующих о достигнутом качестве процесса разработки ПО. Так как эти стандарты разрабатывались, прежде всего, в целях упорядочивания процесса выбора подрядчиков для Министерства обороны США, особое внимание в них уделяется процессам управления ПО проектам, в то время как технические аспекты разработки освещены меньше.

В версии SW-CMM v.1.1 (Capability Maturity Model for Software) имеется 316 Key Practices. Key Practices - это то, что должно быть внедрено на предприятии и то, на что будет обращать внимание команда, проводящая оценку процессов. Они объединяются в области - Key Practices Areas (KPA) - это уже совокупности взаимосвязанных процессов, которые при совместном выполнении и приводят к достижению определенного набора целей.

CMMI (Capability Maturity Model Integration) - дальнейшее развитие модели CMM. В CMMI-SE/SW Version 1.02 (CMMI for Systems Engineering/Software Engineering), пожалуй, наиболее приемлемой для разработчиков программных систем, - количество Key Practices достигает уже 417.

Увеличение Key Practices связано с самой целью разработки CMMI - модель должна помочь избежать проблем, связанных с использованием различных отраслевых моделей CMM.

ISO 9001. Наиболее популярным, и особенно,  в Европе, является ISO 9001.

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

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

Многие организации -разработчики ПО успешно используют именно эту широко известную серию стандартов ISO 9000. Новая версия стандартов этой серии вышла в 2000 году и уже содержит в себе такие понятия, как процессный подход, анализ и измерения,  совершенствование процессов, заимствованные из модели СММ и ранее отсутствовавшие в предыдущих версиях ISO 9000. Правда, следует заметить, что стандарты этой серии универсальны - они не ориентированы на какую либо конкретную отрасль, не учитывает специфики IT-сферы и, в этом смысле, конечно по степени конкретизации, заметно уступают СММ. Кроме того, ISO 9000 не предполагает никаких градаций (уровней) соответствия и, тем самым, затрудняет определение "истинных" возможностей той или иной организации и, соответственно, - путей их дальнейшего развития.

ISO 20000 – первый международный стандарт по управлению качеством ИТ-услуг, он состоит из двух частей: «Information technology – Service management. Part 1: Specification» и «Information technology – Service management. Part 2: Code of Practice».

ISO 20000-1:2005 «Information technology – Service management. Part 1: Specification» содержит полное и подробное описание требований к системе управления ИТ-сервисами, а также ответственность за их в организациях. Первая часть состоит из 10 разделов, которые содержат 13 процессов в пяти ключевых группах:

• Процессы предоставления сервисов (Service delivery process). В группу входит управление уровнем сервисов, управление непрерывностью и доступностью, управление мощностями, отчетность по предоставлению сервисов, управление информационной безопасностью, бюджетирование и учет затрат.

• Процессы управления взаимодействием (Relationship processes). Эта область включает в себя управление взаимодействием с бизнесом, управление поставщиками.

• Процессы разрешения (Resolution processes). Разработчики стандарта фокусируются на инцидентах, которые удалось предотвратить или успешно разрешить, – управление проблемами, управление инцидентами.

• Процессы контроля (Control processes). В данном разделе рассматриваются процессы управления изменениями и конфигурациями.

• Процессы управления релизами (Release process). Речь идет о выработке новых и коррекции уже имеющихся решений.

ISO 20000-2:2005 «Information technology – Service management. Part 2: Code of Practice» – это практическая часть, в которой содержатся рекомендации по процессам и требованиям, описанным в первой части. Состоит из 10 разделов и предназначена для аудиторов и компаний, намеренных пройти сертификацию.

Оценка ИТ-сервисов согласно требованиям ISO 20000-1:2005 дает возможность увидеть объем нереализованности управления, что позволяет запланировать его выполнение по рекомендациям ISO 20000-2:2005, библиотеки ITIL® или любой другой методологии. Использование данных методологий не является обязательным, но в значительной мере упрощает процесс перехода к сервисной модели и делает его более понятным.

Кроме того, стандарт выдвигает требования к мере ответственности руководства компании, предоставляющей ИТ-сервисы, а также к управлению документацией, компетенции, осведомленности и подготовке персонала.

3. Унифицированный процесс. Основные принципы УП.(Денис)

Унифицированный процесс (Unified Process, UP) – это методология моделирования программных систем.  

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

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

принципы:

1. Оценка рисков и ключевых моментов проекта на ранних итерациях.

2. Постоянный отклик пользователей. Обратная связь и модификация требований.

3. Построение общей базовой архитектуры на ранних итерациях.

4. Постоянный контроль качества, раннее и качественное тестирование в реальных условиях.

5. Применение прецедентов.

6. Визуализация программной модели с помощью uml.

7. Итеративность и инкрементальность.

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

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

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

3. Применение языка UML вместе с приемами гибкого моделирования.

4. Детальное планирование выполняется итеративно от итерации к итерации.