Организационные процессы жизненного цикла ПО (ISO 12207 и ISO 15504)

Размещено на http://www.allbest.ru/

Министерство образования и науки Украины

ГВУЗ «Криворожский национальный университет»

Кафедра моделирования и програмного обеспечения

Реферат

на тему: «Организационные процессы жизненного цикла ПО (ISO 12207 и ISO 15504)»

дисциплина: «Групповая динамика и коммуникация»

Выполнила:

студентка группы ЗПЗАС 13 ПП

Павлюк Ольга Борисовна

Преподаватель:

Трачук Анна Альбертовна

Кривой Рог 2014

Содержание

Введение

1. Понятие жизненного цикла ПО

2. Модели жизненного цикла ПО

3. Основные процессы жизненного цикла ПО

4. Стандартизация программного обеспечения

5. Стандарты ISO/IEC 12207 и ISO/IEC 15504

Заключение

Список использованной литературы

Введение программный жизненный технический

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

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

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

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

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

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

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

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

Основным нормативным документом, регламентирующим жизненный цикл, является международный стандарт ISO/IEC 12207 (ISO - International Organization of Standardization - Международная организация по стандартизации, IEC - International Electrotechnical Commission - Международная комиссия по электротехнике). Он определяет структуру жизненного цикла, содержащую процессы, действия и задачи, которые должны быть выполнены во время создания программных средств.

Жизненный цикл программного обеспечения (ПО) - это непрерывный процесс, который начинается с момента принятия решения о необходимости создания ПО и заканчивается в момент его полного изъятия из эксплуатации

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

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

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

- определение потребностей;

- исследование и описание основных концепций;

- проектирование и разработка;

- испытания системы;

- создание и производство;

- распространение и продажа;

- эксплуатация;

- сопровождение и мониторинг;

- снятие с эксплуатации (утилизация).

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

Первый класс составляют относительно небольшие программы, создаваемые одиночками или небольшими коллективами (3 -5) специалистов, которые:

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

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

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

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

- не подлежат независимому тестированию, гарантированию качества и/или сертификации.

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

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

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

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

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

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

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

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

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

2. Модели жизненного цикла ПО

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

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

Рис. 2 Каскадная модель жизненного цикла ПО

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

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

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

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

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

Итерационная модель или поэтапная модель с промежуточным контролем (рис. 3) - разработка ПО ведется итерациями с циклами обратной связи между этапами. Межэтапные корректировки позволяют учитывать реально существующее взаимовлияние результатов разработки на различных этапах; время жизни каждого из этапов растягивается на весь период разработки.

Рис. 3. Итерационная модель жизненного цикла ПО

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

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

Рис. 4. Спиральная модель жизненного цикла ПО

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

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

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

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

На практике наибольшее распространение получили две основные модели жизненного цикла:

· каскадная модель (характерна для периода 1970-1985 гг.);

· спиральная модель (характерна для периода после 1986.г.).

3. Основные процессы жизненного цикла ПО

Структура жизненного цикла по стандарту ISO/IEC 12207 базируется на трех группах процессов: основные, вспомогательные, организационные.

Основные процессы жизненного цикла.

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

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

Процесс приобретения охватывает действия заказчика по приобретению ПП. К этим действиям относятся:

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

2) Подготовка заявочных предложений подразумевает разработку и составление предложений, которые должны содержать: требования к разрабатываемой или покупаемой системе; перечень необходимых ПП; условия и соглашения; технические ограничения.

3) Подготовка и корректировка договора включает в себя следующие задачи: выбор поставщиком критерия оценки предложений; выбор конкретного поставщика на основе анализа предложений; подготовка и заключение договора с поставщиком; внесение изменений (при необходимости) в договор в процессе его выполнения.

4) Надзор за деятельностью поставщика осуществляется в соответствии с действиями, предусмотренными в процессе совместной оценки аудита.

5) Приемка и завершение работ.

В процессе приемки подготавливаются и выполняются необходимые тесты. Завершение работ по договору осуществляется в случае удовлетворения всем условиям приемки.

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

К этим действиям относятся:

1) Инициирование поставки заключается в рассмотрении поставщиком заявочных предложений и принятия решения.

2) Подготовка ответа на заявочные предложения выполняются в соответствии с принятыми решениями.

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

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

5) Выполнение и контроль.

6) Проверка и оценка.

7) Поставка и завершение работ выполняется в соответствии с оговоренными в процессе инициирования действиями по приемки и завершении работ.

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

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

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

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

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

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

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

Вспомогательные процессы жизненного цикла

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

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

Этот процесс включает в себя:

1) Подготовительную работу, которая требуется для определения и согласования необходимого перечня документов и документируемых процедур.

2) Проектирование и разработку документации, которые выполняются в процессе работы над ПП и завершается одновременно с завершением его ЖЦ.

3) Выпуск документации, который осуществляется по мере ее готовности.

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

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

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

Этот процесс включает в себя:

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

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

3) Контроль конфигурации - предназначен для систематической оценки предполагаемых модификаций ПП и координированной их реализации с учетом эффективности каждой модификации и затрат на ее выполнение.

4) Учет состояния конфигурации - представляет собой регистрацию состояния компонентов ПП, подготовку отчетов обо всех реализованных и отвергнутых модификациях версий компонентов ПП.

5) Оценку конфигурации - заключается в оценки функциональной полноты компонентов ПП.

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

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

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

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

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

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

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

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

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

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

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

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

Организационные процессы жизненного цикла

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

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

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

Процесс усовершенствования предусматривает оценку, измерение, контроль, усовершенствование процессов ЖЦ ПП.

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

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

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

4. Стандартизация программного обеспечения

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

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

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

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

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

5. Стандарты ISO/IEC 12207 и ISO/IEC 15504

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

Стандарт ISO 12207:1995 «Процессы жизненного цикла программных средств» наиболее полно на уровне международных стандартов отражает жизненный цикл, технологию разработки и обеспечения качества сложных программных средств. Этот стандарт стал первым опытом создания единого общего взгляда на программную инженерию.

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

· основные процессы жизненного цикла ПС и определяющие работы;

· вспомогательные процессы и работы, поддерживающие жизненный цикл ПС;

· организационные процессы и управление жизненным циклом ПС.

ISO/IEC 12207-95 определяет модель жизненного цикла процессов разработки программного обеспечения. Данная модель жизненного цикла ПО определяет на верхнем уровне фундаментальные цели, которые являются существенными для разработки высокоэффективного и надежного программного обеспечения. Цели верхнего уровня описывают то, что должно быть достигнуто, а не как их достигнуть. Жизненный цикл, определенный данным стандартом, применим в любой software-организации, желающей утвердить, а впоследствии и улучшить возможности по поставке, разработке, эксплуатации, развитии и поддержке программного обеспечения. Модель не предполагает использование специфических организационных структур, философии управления, технологии или методологии разработки ПО.

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

Этот стандарт был необходим для представление терминов, понятий и составных элементов жизненного цикла ПО. Этот стандарт был принят ISO в 1995 году. Следует отметить, что работы по нему были начаты в 1987 году и стандарт формировался взаимными усилиями 125 стран - участниц ISO.

Стандарт ISO/IЕС 15504:1-9 «Оценка процессов жизненного цикла программных средств» предоставляет базу для реализации на предприятиях и в проектах процессов жизненного цикла ПС, регламентированных стандартом ISO 12207. Рубрикации основных процессов в этих двух стандартах подобны. В стандарте ISO 15504 модернизирован и несколько расширен состав организационных процессов, и более подробно детализированы работы во всех стандартизированных процессах жизненного цикла ПС. Поэтому оба стандарта целесообразно применять совместно при конкретизации жизненного цикла реальных проектов сложных комплексов программ.

Аттестация реализации ЖЦ ПС направлена на обеспечение адекватности управления процессами и должна учитывать внешнюю среду, в которой выполняются аттестуемые процессы. Чтобы предприятие могло улучшить качество своей продукции, оно должно иметь проверенный, последовательный и надежный метод для аттестации состояния своих технологических процессов, а также иметь инструментальные средства использования ее результатов как часть Программы усовершенствования процессов ЖЦ ПС. Использование аттестации процессов внутри предприятия должно способствовать выработке культуры постоянного совершенствования и повышения характеристик качества в ЖЦ ПС, а также соответствующих механизмов поддержания этой культуры и оптимизации использования ресурсов. Это должно приводить к появлению зрелых организаций, обеспечивающих минимальную стоимость полного жизненного цикла своей продукции и, как результат, максимально удовлетворяющих требования конечного пользователя к характеристикам качества и безопасности ПС.

Покупателям и заказчикам ПС выгодно использование аттестации процессов ЖЦ при определении зрелости поставщика, что:

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

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

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

· приведет к общему пониманию необходимости использования результатов аттестации для усовершенствования процессов и оценки зрелости поставщика при прогнозировании характеристик ЖЦ ПС.

Для достижения устойчивых результатов в процессе развития технологии и организации управления жизненным циклом ПС в стандарте ISO 15504 рекомендуется методология обеспечения качества сложных программных средств СММ (Capability Maturity Model) -- система и модель оценки зрелости комплекса применяемых технологических процессов.

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

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

Девять частей стандарта ISO 15504, посвящены различным базовым задачам, относящимся к оцениванию, аттестации и совершенствованию зрелости процессов ЖЦ ПС на предприятии.

Эти принципы рекомендуется применять при:

формулировке политики и стратегии обеспечения всего ЖЦ ПС;

выборе целей проекта, требований и характеристик качества ПС, непосредственно связанных с потребностями и ожиданиями заказчиков и потребителей;

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

управлении людскими ресурсами предприятия для обеспечения ЖЦ ПС и его качества.

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

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

Заключение

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

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

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

Список использованной литературы

1. Гагарина Л.Г., Кокорева Е.В., Виснадул Б.Д. Технология разработки программного обеспечения: учебное пособие. - М., ИД «ФОРУМ» - ИНФРА - М. 2008. - 400 с.

2. Соммервилл И. Инженерия программного обеспечения. - М.: Издательский дом «Вильямс», 2002. - 624 с.

3. Орлов С.А. Технологии разработки программного обеспечения: Учебник/. -- СПб.: Питер, 2002. -- 464 с.: ил.

4. Константайн Л., Локвуд Л. Разработка программного обеспечения, СПб.: 2004, 592 с.

5. Практические аспекты информатизации. Стандартизация, сертификация и лицензирование. Справочная книга руководителя. Под редакцией Л.Д. Реймана. М.: 2000. - 259 с.

6. Стандарт ISO/IEC 12207-95 «Информационная технология. Процессы жизненного цикла программных средств».

7. Стандарт ISO/IEC 15504-1:2004 «Информационные технологии. Оценка процессов. Часть 1. Концепция и словарь».

8. Липаев В.В. Информационный бюллетень "Jet Info 03(130)/2004".

Размещено на Allbest.ru

...