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

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

Рубрика Программирование, компьютеры и кибернетика
Вид статья
Язык русский
Дата добавления 16.02.2019
Размер файла 22,9 K

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

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

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

УДК 004.75

ПРОБЛЕМЫ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

ISSUES OF SOFTWARE DEVELOPMENT

Искакова Г.М. - к.п.н. ст.преподаватель

Бельгибаева А.М. - магистр техники и технологий

Пиягин Евгений Николаевич студент группы Ис-42

Аннотация

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

This article presents the main issues and principal points of software development. The main policy issues arising from the development of software.

Ма?алада ба?дарламалы? ?амтамасыз етуімен байланыс?ан м?селелер талдал?ан. Негізгі ымырасыз с?ра?тар, ба?дарламалы? ?амтасасыз жасал?анда ?арал?ан.

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

Как видно из симптомов недомогания ПО, при его разработке возникает пять принципиальных вопросов:

- Недостаток прозрачности;

- Недостаток контроля;

- Недостаток трассировки;

- Недостаток мониторинга;

- Неконтролируемые изменения.

Рассмотрим ответы на эти вопросы.

Недостаток прозрачности

По своей природе ПО является концептуальным. В отличие от моста, здания или любого другого физического объекта, сложно посмотреть на программный продукт и оценить степень его завершенности. Без жесткого руководства проектом разработка ПО будет завершена на 90% при использовании 90% отведенного времени. Политика Управления Конфигурациями (УК)и Управления Изменениями (УИ) и определение модели менеджмента конфигурации ПО при разработке продукта, все элементы конфигурации, компоненты и подкомпоненты мгновенно становятся видимыми для версий, релизов и семейств продуктов [1].

Недостаток контроля

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

Недостаток трассировки

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

Недостаток мониторинга

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

Неконтролируемые изменения

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

Множественность версий

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

Семейство программных продуктов

Поскольку программные продукты созданы для того, чтобы предлагать аналогичные функции с помощью неоднородных платформ аппаратного обеспечения, необходимо управлять как программным продуктом вообще, так и ПО на базе определенной аппаратной платформы. Если программный продукт работает с четырьмя версиями Windows, тремя версиями Unix, RedHatLinux и Free BSD, то руководство для пользователя должно быть аналогичным. Но для этих девяти платформ необходимы разные процессы установки ПО. Без применения о написать девять отдельных руководств пользователя по данному программному продукту. При наличии УК И УИ достаточно будет одного комплекта документации, куда будут входить все девять версий, которые будут отличаться лишь процедурой инсталляции программного продукта.

Изменение требований

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

Борьба с такими изменениями представляет собой сложную управленческую проблему. Наличие УК И УИ облегчает управление такими изменениями требований к продукту. УК И УИ позволяет легко идентифицировать наборы функциональных возможностей, которые объединяют требования, которым отвечает версия продукта. Этот набор функциональных возможностей отслеживается от разработки до поставки продукта [4].

Изменение графика работ

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

Изменения ПО

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

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

Изменения штата

Во всех организациях сотрудники продвигаются по служебной лестнице, переходят на другую работу или увольняются. Если это происходит в разгар работы по разработке ПО, то с уходом специалиста теряются не только технологические знания. Теряются также практические знания по разработке продуктов, на овладение которыми ушло много времени. Новые сотрудники, даже зная технологию, не смогут заниматься разработкой продукта без документированного процесса УК И УИ. Таким образом, УК И УИ является точкой отсчета и базой данных об истории разработки проекта. Благодаря УК И УИ новый сотрудник может узнать, как идет процесс разработки в организации и что нового в проекте на конкретную дату [5].

Изменения документации система/пользователь

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

Литература

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

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

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

4. Кознов Д.В., Бугайченко Д.Ю. Введение в программную инженерию/ [Электронный ресурс].

5. Корнеев И.К. Информационные технологии: Учебник для вузов. - М.: Проспект.-2007.- 224 с.

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

...

Подобные документы

Работы в архивах красиво оформлены согласно требованиям ВУЗов и содержат рисунки, диаграммы, формулы и т.д.
PPT, PPTX и PDF-файлы представлены только в архивах.
Рекомендуем скачать работу.