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

Когда Грейс Хоппер работала с компьютером Гарвард Марк II в Гарвардском университете, её коллеги обнаружили эту моль, застрявшую в реле и таким образом помешавшую работе устройства, после чего она отметила, что они «отлаживали»(debug) систему. Таким образом начал обретать популярность термин Баг — ошибка программного обеспечения.

Не следует путать с Инженерия программного обеспечения.

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

Сложность разработки ПО

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

См. также: Бережливая разработка программного обеспечения

Разделы дисциплины

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

1. Требования к программному обеспечению: извлечение, анализ, спецификация и ратификация требований для программного обеспечения.
2. Проектирование программного обеспечения: проектирование программного обеспечения средствами Автоматизированной Разработки Программного Обеспечения (CASE) и стандарты формата описаний, такие как Унифицированный Язык Моделирования (UML), использую различные подходы: проблемно-ориентированное проектирование и т.д..
3. Инженерия программного обеспечения: создание программного обеспечения с помощью языков программирования.
4. Тестирование программного обеспечения: поиск и исправление ошибок в программе.
5. Обслуживание программного обеспечения: программные системы часто имеют проблемы совместимости и переносимости, а также нуждаются в последующих модификациях в течение долгого времени после того, как закончена их первая версия. Подобласть имеет дело с этими проблемами.
6. Управление конфигурацией программного обеспечения: так как системы программного обеспечения очень сложны и модифицируются в процессе эксплуатации, их конфигурации должны управляться стандартизированным и структурированным методом.
7. Управление разработкой программного обеспечения: управление системами программного обеспечения имеет заимствования из управления проектами, но есть нюансы, не встречающиеся в других дисциплинах управления.
8. Процесс разработки программного обеспечения: процесс построения программного обеспечения горячо обсуждается среди практиков, основными парадигмами считаются agile или waterfall.
9. Инструменты разработки программного обеспечения, см. CASE: методика оценки сложности системы, выбора средств разработки и применения программной системы.
10. Качество программного обеспечения: методика оценки критериев качества программного продукта и требований к надёжности.
11. Локализация программного обеспечения, ветвь языковой промышленности.

Процесс и методология

Основная статья: Процесс разработки программного обеспечения

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

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

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

Данная методология направлена на решение задач на ЭВМ, аналогичной технологии разработки алгоритмов и программ, используемой на олимпиадах по программированию отечественными студентами и программистами с использованием тестирования и структурного псевдокода для документирования программ в корпорации IBM с 70-х годов.

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

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

Участники процесса разработки ПО

• Пользователь
• Заказчик
• Разработчик
• Руководитель проекта
• Аналитик
• Тестировщик
• Поставщик

Проблемы разработки ПО

Наиболее распространёнными проблемами, возникающими в процессе разработки ПО, считают:

• Недостаток прозрачности. В любой момент времени сложно сказать, в каком состоянии находится проект и каков процент его завершения.
  Данная проблема возникает при недостаточном планировании структуры (или архитектуры) будущего программного продукта, что чаще всего является следствием отсутствия достаточного финансирования проекта: программа нужна, сколько времени займёт разработка, каковы этапы, можно ли какие-то этапы исключить или сэкономить — следствием этого процесса является то, что этап проектирования сокращается.
• Недостаток контроля. Без точной оценки процесса разработки срываются графики выполнения работ и превышаются установленные бюджеты. Сложно оценить объём выполненной и оставшейся работы.
  Данная проблема возникает на этапе, когда проект, завершённый более чем наполовину, продолжает разрабатываться после дополнительного финансирования без оценки степени завершённости проекта.
• Недостаток трассировки.
• Недостаток мониторинга. Невозможность наблюдать ход развития проекта не позволяет контролировать ход разработки в реальном времени. С помощью инструментальных средств менеджеры проектов принимают решения на основе данных, поступающих в реальном времени.
  Данная проблема возникает в условиях, когда стоимость обучения менеджмента владению инструментальными средствами сравнима со стоимостью разработки самой программы.
• Неконтролируемые изменения. У потребителей постоянно возникают новые идеи относительно разрабатываемого программного обеспечения. Влияние изменений может быть существенным для успеха проекта, поэтому важно оценивать предлагаемые изменения и реализовывать только одобренные, контролируя этот процесс с помощью программных средств.
  Данная проблема возникает вследствие нежелания конечного потребителя использовать те или иные программные среды. Например, когда при создании клиент-серверной системы потребитель предъявляет требования не только к операционной системе на компьютерах-клиентах, но и на компьютере-сервере.
• Недостаточная надёжность. Самый сложный процесс — поиск и исправление ошибок в программах на ЭВМ. Поскольку число ошибок в программах заранее неизвестно, то заранее неизвестна и продолжительность отладки программ и отсутствие гарантий отсутствия ошибок в программах. Следует отметить, что привлечение доказательного подхода к проектированию ПО позволяет обнаружить ошибки в программе до её выполнения. В этом направлении много работали Кнут, Дейкстра и Вирт. Профессор Вирт при разработке Паскаля и Оберона за счет строгости их синтаксиса добился математической доказуемости завершаемости и правильности программ, написанной на этих языках.
  Данная проблема возникает при неправильном выборе средств разработки. Например, при попытке создать программу, требующую средств высокого уровня, с помощью средств низкого уровня. Например, при попытке создать средства автоматизации с СУБД на ассемблере. В результате исходный код программы получается слишком сложным и плохо поддающимся структурированию.
• Отсутствие гарантий качества и надежности программ из-за отсутствия гарантий отсутствия ошибок в программах вплоть до формальной сдачи программ заказчикам.
  Данная проблема не является проблемой, относящейся исключительно к разработке ПО. Гарантия качества — это проблема выбора поставщика товара (не продукта).

См. также

• Алгоритм
• Информатика
• Программирование
• Парадигма программирования
• Структурное программирование
• Тестирование программного обеспечения
• Логика в информатике
• Проблемно-ориентированное проектирование
• Логическое программирование

Ссылки

• IEEE Standards Association:Software Engineering — Descriptions (англ.)
• Институт программной инженерии Университета Карнеги-Меллон  (англ.)

Литература

• Иан Соммервилл Инженерия программного обеспечения = Software Engineering. — 6-е изд. — М.: «Вильямс», 2002. — С. 642. — ISBN 5-8459-0330-0

• Джек Гринфилд, Кит Шорт, Стив Кук, Стюарт Кент, Джон Крупи Фабрики разработки программ (Software Factories): потоковая сборка типовых приложений, моделирование, структуры и инструменты = Software Factories: Assembling Applications with Patterns, Models, Frameworks, and Tools. — М.: «Диалектика», 2006. — С. 592. — ISBN 978-5-8459-1181-0

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