Просмотр отдельных изменений

'[[Файл:H96566k.jpg|thumb|260px|Когда [[Грейс Хоппер]] работала с компьютером [[Гарвард Марк II]] в [[Гарвардский университет|Гарвардском университете]], ее коллеги обнаружили эту [[Моли|моль]], застрявшую в [[реле]] и таким образом помешавшую работе устройства, после чего она отметила, что они «отлаживали»(debug) систему. Таким образом начал обретать популярность термин [[Баг]] — ошибка программного обеспечения.]] {{не путать|Инженерия программного обеспечения}} '''Разрабо́тка програ́ммного обеспе́чения''' ({{lang-en|software engineering}}, ''software development'') — это род деятельности ([[профессия]]) и процесс, направленный на создание и поддержание работоспособности, качества и надежности [[программное обеспечение|программного обеспечения]], используя технологии, методологию и практики из [[информатика|информатики]], [[управление проектами|управления проектами]], [[математика|математики]], [[инженерия|инженерии]] и других областей знания. == Сложность разработки ПО == Как и другие, традиционные инженерные дисциплины, разработка программного обеспечения имеет дело с проблемами качества, стоимости и надёжности. Некоторые программы содержат миллионы [[количество строк кода|строк]] [[исходный код|исходного кода]], которые, как ожидается, должны правильно исполняться в изменяющихся условиях. Сложность ПО сравнима со сложностью наиболее сложных из современных машин, таких как [[самолет]]ы. == Разделы дисциплины == Разработка программного обеспечения может быть разделена на несколько разделов. Это: # [[Требования к программному обеспечению]]: извлечение, анализ, спецификация и ратификация требований для программного обеспечения. # [[Проектирование программного обеспечения]]: проектирование программного обеспечения средствами [[Автоматизированная Разработка Программного Обеспечения|Автоматизированной Разработки Программного Обеспечения (CASE)]] и стандарты формата описаний, такие как Унифицированный Язык Моделирования ([[UML]]). # [[Инженерия программного обеспечения]]: создание программного обеспечения с помощью языков программирования. # [[Тестирование программного обеспечения]]: поиск и исправление ошибок в программе. # [[Обслуживание программного обеспечения]]: программные системы часто имеют проблемы совместимости и переносимости, а также нуждаются в последующих модификациях в течение долгого времени после того, как закончена их первая версия. Подобласть имеет дело с этими проблемами. # [[Управление конфигурацией программного обеспечения]]: так как системы программного обеспечения очень сложны и модифицируются в процессе эксплуатации, их конфигурации должны управляться стандартизированным и структурированным методом. # [[Управление разработкой программного обеспечения]]: управление системами программного обеспечения имеет заимствования из [[управление проектами|управления проектами]], но есть нюансы, не встречающиеся в других дисциплинах управления. # [[Процесс разработки программного обеспечения]]: процесс построения программного обеспечения горячо обсуждается среди практиков, основными парадигмами считаются [[Гибкая методология разработки|agile]] или [[Модель водопада|waterfall]]. # Инструменты разработки программного обеспечения, см. [[CASE]]: методика оценки сложности системы, выбора средств разработки и применения программной системы. # [[Качество программного обеспечения]]: методика оценки критериев качества программного продукта и требований к надёжности. # [[Локализация программного обеспечения]], ветвь [[языковая промышленность|языковой промышленности]]. == Процесс и методология == : ''Основная статья: '''[[Процесс разработки программного обеспечения]]''' На протяжении нескольких десятилетий стоит задача поиска повторяемого, предсказуемого процесса или методологии, которая бы улучшила продуктивность, качество и надежность разработки. Одни пытались систематизировать и формализовать этот, по-видимому, непредсказуемый процесс. Другие применяли к нему методы управления проектами и методы [[Программная инженерия|программной инженерии]]. Третьи считали, что без постоянного контроля со стороны заказчика разработка ПО выходит из-под контроля, съедая лишнее время и средства. Опыт управления разработкой программ отражается в соответствующих стандартах. Если при разработке используется несколько стандартов и нормативных документов, то имеет смысл составить [[Профиль (стандарты)|профиль]]. [[Информатика]] как научная дисциплина предлагает и использует на базе методов структурного программирования технологию надежной разработки программного обеспечения, используя [[тестирование]] программ и их верификацию на основе методов доказательного программирования для систематического анализа правильности [[алгоритм]]ов и разработки программ без алгоритмических ошибок. Данная [[методология]] направлена на [[решение задач]] на ЭВМ, аналогичной технологии разработки алгоритмов и программ, используемой на олимпиадах по программированию отечественными студентами и программистами с использованием тестирования и структурного псевдокода для документирования программ в корпорации IBM с 70-х годов. Методология структурного проектирования программного обеспечения может использоваться с применением самых различных языков и средств программирования для разработки надежных программ самого различного назначения. Одним из таких проектов была разработка бортового программного обеспечения для космического корабля «Буран», в котором впервые использовался бортовой компьютер для автоматического управления аппарата, совершившего успешный старт и посадку космического корабля. При выборе методологии разработки программного обеспечения следует руководствоваться тем, что сложность методологии сравнима со сложностью структуры программного продукта, и неоправданная для продукта данной сложности сложность методологии только неоправданно увеличит стоимость разработки. == Участники процесса разработки ПО == * [[Конечный пользователь|Пользователь]] * [[заказчик|Заказчик]] * [[программист|Исполнитель]] == Проблемы разработки ПО == Наиболее распространёнными проблемами, возникающим в процессе разработки ПО, считают: * Недостаток прозрачности. В любой момент времени сложно сказать, в каком состоянии находится проект и каков процент его завершения.<br />Данная проблема возникает при недостаточном планировании структуры (или [[Архитектура программного обеспечения|архитектуры]]) будущего программного продукта, что чаще всего является следствием отсутствия достаточного финансирования проекта: программа нужна, сколько времени займёт разработка, каковы этапы, можно ли какие-то этапы исключить или сэкономить — следствием этого процесса является то, что этап [[Проектирование|проектирования]] сокращается. * Недостаток контроля. Без точной оценки процесса разработки срываются графики выполнения работ и превышаются установленные бюджеты. Сложно оценить объем выполненной и оставшейся работы.<br />Данная проблема возникает на этапе, когда проект, завершённый более чем наполовину, продолжает разрабатываться после дополнительного финансирования без оценки степени завершённости проекта. * Недостаток [[Трассировка_(программирование)|трассировки]]. * Недостаток [[мониторинг]]а. Невозможность наблюдать ход развития проекта не позволяет контролировать ход разработки в реальном времени. С помощью инструментальных средств менеджеры проектов принимают решения на основе данных, поступающих в реальном времени.<br />Данная проблема возникает в условиях, когда стоимость обучения менеджмента владению инструментальными средствами сравнима со стоимостью разработки самой программы. * Неконтролируемые изменения. У потребителей постоянно возникают новые идеи относительно разрабатываемого программного обеспечения. Влияние изменений может быть существенным для успеха проекта, поэтому важно оценивать предлагаемые изменения и реализовывать только одобренные, контролируя этот процесс с помощью программных средств.<br />Данная проблема возникает вследствие нежелания конечного потребителя использовать те или иные программные среды. Например, когда при создании клиент-серверной системы [[Конечный пользователь|потребитель]] предъявляет требования не только к [[Операционная система|операционной системе]] на компьютерах-клиентах, но и на компьютере-сервере. * Недостаточная [[надежность]]. Самый сложный [[процесс]] — поиск и исправление ошибок в программах на [[ЭВМ]]. Поскольку число [[баг|ошибок]] в программах заранее неизвестно, то заранее неизвестна и продолжительность отладки программ и отсутствие гарантий отсутствия ошибок в программах. Следует отметить, что привлечение доказательного подхода к проектированию ПО позволяет обнаружить ошибки в программе до её выполнения. В этом направлении много работали [[Кнут, Дональд|Кнут]], [[Дейкстра, Эдсгер|Дейкстра]] и [[Вирт, Никлаус|Вирт]]. Профессор Вирт при разработке [[Паскаль|Паскаля]] и [[Оберон]]а за счет строгости их синтаксиса добился математической доказуемости завершаемости и правильности программ, написанной на этих языках. Особенно крупный вклад в дисциплину программирования внёс [[Кнут, Дональд|Дональд Кнут]]. Его четырёхтомник «[[Искусство программирования]]» является необходимой для каждого серьезного программиста книгой.<br />Данная проблема возникает при неправильном выборе средств разработки. Например, при попытке создать программу, требующую средств [[Высокоуровневый язык программирования|высокого уровня]], с помощью средств низкого уровня. Например, при попытке создать средства [[Автоматизация|автоматизации]] с [[Система управления базами данных|СУБД]] на [[язык ассемблера|ассемблере]]. В результате [[исходный код]] программы получается слишком сложным и плохо поддающимся [[Рефакторинг|структурированию]]. * Отсутствие гарантий качества и надежности программ из-за отсутствия гарантий отсутствия ошибок в программах вплоть до формальной сдачи программ заказчикам.<br />Данная проблема не является проблемой, относящейся исключительно к разработке ПО. Гарантия качества — это проблема выбора поставщика [[товар]]а (не [[продукт]]а). == См. также == * [[Алгоритм]] * [[Информатика]] * [[Программирование]] * [[Парадигма программирования]] * [[Структурное программирование]] * [[Тестирование программного обеспечения ]] * [[Логика в информатике]] * [[Логическое программирование]] == Ссылки == * [http://standards.ieee.org/reading/ieee/std_public/description/se/index.html IEEE Standards Association:Software Engineering — Descriptions]{{ref-en}} * [http://www.sei.cmu.edu Институт программной инженерии Университета Карнеги-Меллон ]{{ref-en}} * [http://www.osoportal.com - все о программном обеспечении и компьютерных технологиях} {{ref-ru}} == Литература == * {{книга |заглавие = Инженерия программного обеспечения |оригинал = Software Engineering |автор = Иан Соммервилл |ссылка = |isbn = 5-8459-0330-0 |страницы = 642 |год = 2002 |издание = 6-е изд |место = М. |издательство = [[Вильямс (издательство)|«Вильямс»]] }} * {{книга |заглавие = Фабрики разработки программ (Software Factories): потоковая сборка типовых приложений, моделирование, структуры и инструменты |оригинал = Software Factories: Assembling Applications with Patterns, Models, Frameworks, and Tools |автор = Джек Гринфилд, Кит Шорт, Стив Кук, Стюарт Кент, Джон Крупи |ссылка = |isbn = 978-5-8459-1181-0 |страницы = 592 |год = 2006 |место = М. |издательство = [[Диалектика (издательство)|«Диалектика»]] }} {{rq|refless|topic=IT}} {{compu-stub}} {{Software Engineering}} [[en:Software development]] [[Категория:Разработка программного обеспечения|*]]'