Особенности управления разработкой программного обеспечения

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

28

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

Курсовая работа

по дисциплине «Информационные технологии управления»

тема: «Особенности управления разработкой программного обеспечения»

Содержание

Введение

1. Понятие программного обеспечения

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

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

Заключение

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

Введение

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

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

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

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

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

1. Понятие программного обеспечения

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

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

Общее определение содержания понятия «программное обеспечение» включает в себя совокупность программ системы обработки данных и программных документов, необходимых для эксплуатации этих программ [8, с. 221]. Данная трактовка в общем случае может быть использована, особенно если речь идет о проблемах собственно разработки и эксплуатации программных комплексов как таковых. Но с точки зрения пользователей в рамках соответствующих технологий следует выделить из состава их программного обеспечения эксплуатационные документы, поскольку в соответствии со структурой средств и методов информационных технологий они относятся к организационно-методическому обеспечению.

В учебной и справочной литературе по-разному описывается структура программного обеспечения. Используются в различных сочетаниях такие понятия, как «общее программное обеспечение», «системное программное обеспечение», «базовое программное обеспечение», «прикладное программное обеспечение», «специальное программное обеспечение». При этом содержание этих понятий зачастую пересекается, что не дает возможности четко структурировать собственно программное обеспечение. Структуризация программного обеспечения офисных технологий основывается на четко выделенных и не пересекающихся по содержанию выполняемых соответствующими программами функциях, при этом в совокупности обеспечивается необходимая полнота всего состава программного обеспечения [6, с. 91].

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

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

В составе программного обеспечения выделяются [6,^.,с. 92]:

— системное программное обеспечение;

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

— прикладное программное обеспечение.

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

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

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

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

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

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

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

- системы управления базами данных (СУБД), позволяющие превратить компьютер в справочник по любой теме;

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

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

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

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

Главной частью системного программного обеспечения является операционная система (ОС).

Операционная система - это набор программ, управляющих оперативной памятью, процессором, внешними устройствами и файлами, ведущих диалог с пользователем [10].

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

Вот названия некоторых распространенных операционных систем для персональных компьютеров: MS-DOS, Windows, Linux.

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

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

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

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

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

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

С системами программирования работают программисты. Всякая система программирования ориентирована на определенный язык программирования. Существует много разных языков, например Паскаль, Бейсик, ФОРТРАН, С, Ассемблер, ЛИСП и другие. На этих языках программист пишет программы, а с помощью систем программирования заносит их в компьютер, отлаживает, тестирует, исполняет.

Программисты создают все виды программ: системные, прикладные и новые системы программирования.

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

программное обеспечение управление

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

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

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

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

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

Рисунок 1- Модифицированная каскадная модель разработки программного обеспечения

Модифицированная каскадная модель предусматривала возможность возвращения к предыдущим этапам.

Спустя непродолжительное время после своего появления на свет каскадная модель была доработана Уинстом Ройсом с учетом взаимозависимости этапов и необходимости возврата на предыдущие ступени, что может быть вызвано, например, неполнотой требований или ошибками в формировании задания [5]. В таком «обратимом» виде каскадная модель просуществовала долгое время и явилась основой для многих проектов (рисунок 1).

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

Для того, чтобы устранить недостатки каскадной модели была предложена V-образная, или шарнирная модель разработки программного обеспечения (рисунок 2).

Рисунок 2- V-образная модель разработки программного обеспечения

V-образная модель позволяет гораздо лучше контролировать результат на предмет его соответствия ожиданиям, поскольку сфокусирована на тестировании [5].

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

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

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

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

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

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

Рис. 3. Спиральная модель Боэма

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

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

Впервые предложенная Филиппом Крачтеном в 1995 году, итеративная модель объединяет главные преимущества спиральной, инкрементной, каскадной моделей, а также методов разработки на основе создания прототипов и объектно-ориентированного подхода (рисунок 4). Она завоевала большую популярность и в том или ином виде используется во многих современных проектах [9].

Рисунок 4- Итеративная модель разработки программного обеспечения

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

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

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

Самым известным и авторитетным стандартом качества следует считать Capability Maturity Model (CMM) - модель оценки уровня зрелости процессов разработки вместе с его производными. Он был создан SEI (Software Engineering Institute), который финансируется за счет Министерства обороны США и является структурной единицей Университета Карнеги-Меллона. Первая официальная версия стандарта вышла в 1993 году, хотя работы над ним начались гораздо раньше - основные его положения были опубликованы еще в 1986 голу. Успех CMM предопределило несколько факторов. Этот стандарт был одним из первых, изначально учитывающих специфику создания программного обеспечения. Он оказался достаточно прост и прозрачен как для понимания, так и для использования, и регламентировал, «что», а не «как» делать, а потому подходил для различных моделей жизненного цикла, методологий разработки и не накладывал каких-либо ограничений на стандарты документирования, инструментарий, среду и языки, применяемые в проектах. И, пожалуй, основным фактором, предопределившим популярность CMM, явилось сотрудничество SEI с Министерством обороны США, что де-факто означало использование стандарта при реализации проектов по заказу этого ведомства.

Модель CMM (таблица 1) предусматривает пять уровней зрелости, каждому из которых соответствуют определенные ключевые области процессов (Key Process Areas, KPA) [9].

Таблица 1-Модель СММ

Название уровня	Ключевые области процесса
1 - Начальный	Если организация находится на этом уровне, то ключевых областей процессов для нее не предусмотрено
2 - Повторяющийся	Управление программными конфигурациями. Обеспечение качества программных продуктов. Управление контрактами подрядчиков. Контроль за ходом проектов. Планирование программных проектов. Управление требованиями
3 - Определенный	Экспертные оценки. Координация взаимодействий проектных групп. Инженерия программного продукта. Комплексный менеджмент ПО. Программа обучения персонала. Определение организационного процесса. Область действия организационного процесса
4 - Управляемый	Менеджмент качества ПО. Управление процессом на основе количественных методов
5 - Оптимизируемый	Управление изменением процесса. Управление технологическими изменениями. Предотвращение дефектов

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

Стандарт CMM оказался весьма успешным, и впоследствии на его основе была создана целая серия стандартов, а он получил новое имя - SW-CMM (Capability Maturity Model for Software), точнее отражающее его положение в достаточно многочисленном семействе стандартов.

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

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

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

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

Разрешить большинство проблем CMM призван новый стандарт SEI - Capability Maturity Model Integrated (CMMI) - интегрированная модель оценки уровня зрелости процессов разработки. Стандарт CMMI изначально создавался таким образом, чтобы объединить существующие варианты CMM и исключить какие-либо противоречия при его практическом применении в различных сферах деятельности высокотехнологичных компаний.

Для того чтобы устранить необходимость «выравнивания» процессов организации и быть более приспособленным к ее бизнес-потребностям, а не наоборот, стандарт CMMI имеет две формы представления - классическую, многоуровневую, соответствующую CMM, и новую, непрерывную. Непрерывная форма представления рассматривает не уровни зрелости (Maturity Levels), а уровни возможностей (Capability Levels), которые оцениваются для отдельных областей процессов (Process Areas, PA).

В таблице 2 дано соответствие уровней зрелости стандарта CMM, а также уровней зрелости многоуровневого представления CMMI и уровней возможностей непрерывного представления CMMI.

Таблица 2- Соответствие уровней зрелости стандартов CMM, CMMI

Уровень зрелости CMM	Уровень зрелости многоуровневого представления CMMI	Уровень возможностей непрерывного представления CMMI
0 - Незавершенный	-	-
1 - Начальный	Начальный	Выполнимый
2 - Повторяющийся	Управляемый	Управляемый
3 - Определенный	Определенный	Определенный
4 - Управляемый	Управляемый количественно	Управляемый количественно
5- Оптимизируемый	Оптимизируемый	Оптимизируемый

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

В современных условиях наличие сертификата определенного уровня CMM/CMMI не является таким значимым фактором, как несколько лет назад, и принимается без дополнительных вопросов разве что в проектах, выполняемых по государственному заказу.

Стандарт ISO/IEC 15504 предназначен для оценки процесса разработки информационных систем, в частности, программного обеспечения. Он изначально был спроектирован таким образом, чтобы в значительной степени соответствовать существующим в отрасли стандартам оценки процесса создания программного обеспечения. Именно это требование определило схожесть стандарта с основными принципами CMM/CMMI [9].

Модель зрелости процесса разработки программного обеспечения (CMM), разработанная Институтом программной инженерии в университете Carnegie Mellon, предлагает пять уровней зрелости (таблица 3). Она помогает организациям повысить зрелость своих процессов разработки программного обеспечения, и организации могут быть оценены и аккредитованы в соответствии с этими уровнями.

Таблица 3-Уровни зрелости разработки программного обеспечения

Уровень 1 - начальный уровень	Процесс разработки ПО спонтанен, и регламентированы лишь немногие процессы. Успех разработки может зависеть от отдельных сотрудников.
Уровень 2 - уровень повторяемости	Созданы основные процессы управления проектами для отслеживания затрат, календарного плана и функциональных возможностей.
Уровень 3 - уровень регламентируемости	Процесс разработки ПО документирован, стандартизирован и интегрирован со стандартным процессом разработки ПО организации как для операций управления , так и для операций разработки . Во всех проектах используется стандартизированный процесс.
Уровень 4 - уровень управляемости	Проводится сбор подробных показателей процесса разработки ПО и качества продукта, что позволяет понять процесс и продукты и управлять ими.
Уровень 5 - уровень оптимизируемости	Непрерывная оптимизация процесса обеспечивается количественной обратной связью от процесса и от пилотных инновационных идей и технологий.

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

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

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

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

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

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

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

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

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

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

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

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

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

При управлении разработкой программного обеспечения нужно учитывать некоторые ее особенности [7]:

1) Создаваемые программы нематериальны. Это порождает проблемы двух видов:

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

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

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

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

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

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

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

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

3) Существует много аргументов в пользу того, что программный код является проектом, а не конечным продуктом.

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

Выделяют несколько проблем управления разработкой программного обеспечения, приведем их классификацию, а также используемые для их решения инструментальные средства в таблице 4 [5, с. 24].

Таблица 4-Специфика управления процессом разработки программного обеспечения и инструментальные средства

Основные проблемы управления	Подходы и инструментальные средства для их решения
Высокая неопределенность в отношении сроков выполнения работ и необходимых ресурсов	Сравнительные/экспертные оценки Итеративный процесс разработки Прототипирование
Сложность оценки объема и качества выполненных работ до полного завершения проекта	Использование подходов ISO 9000/СMM/CMMI-зрелый процесс как гарантия качества разработки
Сложность формализации требований к результатам проекта	ГОСТ 19,34-разработка ТЗ, ТП, РП Использование case средств/UML/RUP Использование референтных моделей, шаблонов Прототипирование/экстремальное программирование ХР
Технологическая гибкость процесса разработки- наличие нескольких принципиально разных планов разработки	Различные типовые модели жизненного цикла программного обеспечения

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

Заключение

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

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

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

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

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

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

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

1. Бажин И.И. Информационные системы менеджмента: Учебник для вузов. - М.: ГУ-ВШЭ, 2000. - 688 с.

2. Вайнштейн В. Управление качеством в процессах разработки программного обеспечения// Компьютера.-2003.- №4.

3. Избачков Ю.С., Петров В.Н. Информационные системы: Учебник для вузов.-2-е изд.-СПб: Питер, 2006.-656 с.: ил.

4. Кознов Д.В., Бугайченко Д.Ю. Введение в программную инженерию/ [Электронный ресурс]. Точка доступа: http://www.intuit.ru/department/se/inprogeng/2/

5. Колтунова Е.В. Выбор методов, моделей и стандартов управления разработкой программного обеспечения// Диссертационное исследование.- СПб.: Питер, 2007.- 184 с.

6. Корнеев И.К. Информационные технологии: Учебник для вузов/ И.К. Корнеев, Г.Н. Ксандопуло, В.А. Машурцев.- М.: ТК Велби, Проспект.-2007.- 224 с.

7. Кулямин В.В. Технологии программирования. Компонентный подход: Учебник для вузов/[Электронный ресурс]. Точка доступа: http://panda.ispras.ru/~kuliamin/

8. Першиков В.М., Савинков В.М. Толковый словарь по информатике. М.: Финансы и статистика, 1991-543 с.

9. Сорока Т. Обзор процессов разработки программного обеспечения/[Электронный ресурс]. Точка доступа: http://cppbuilder.ru

10. Шауцукова Л.З. Информатика 10-11: Учебное пособие.- М.: Просвещение, 2004.-240 с.

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