В этой статье не хватает ссылок на источники информации. Информация должна быть проверяема, иначе она может быть поставлена под сомнение и удалена. Вы можете … Википедия

Эта статья предлагается к удалению. Пояснение причин и соответствующее обсуждение вы можете найти на странице Википедия:К удалению/30 июля 2012. Пока процесс обсуждения … Википедия

- (англ. Software project management) особый вид управления проектами, в рамках которого происходит планирование, отслеживание и контроль за проектами по разработке программного обеспечения. Ключевым моментом в управлении проектом по… … Википедия

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

Наиболее распространённый в настоящее время способ нумерации версий Жизненный цикл успешной компьютерной программы может быть очень долгим; изменения в программе бывают разными от исправления ошибки до полного переписывания. В бол … Википедия

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

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

Новый Airbus A 380 использует довольно много ПО, чтобы создать современную кабину в самолете. Метод инженерии программного обеспечения позволил создать программное обеспечение самолёта, описываемое миллионами строк … Википедия

Разработка программного обеспечения Процесс разработки ПО Шаги процесса Анализ Проектирование Программирование Докумен … Википедия

Книги

• Пользовательские истории. Гибкая разработка программного обеспечения , Кон Майк. В книге "Пользовательские истории: гибкая разработка программного обеспечения" Майка Кона, выхода которой с нетерпением ожидало сообщество сторонников гибких методологий разработки…
• Пользовательские истории: гибкая разработка программного обеспечения , Кон Майк. В этой книге, выхода которой с нетерпением ожидало сообщество сторонников гибких методологий разработки программного обеспечения, описывается процесс подготовкитребований к разрабатываемой…

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

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

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

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

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

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

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

Другая сторона наших заказных проектов – высокие требования к функциональности. Это и высокая нагрузка на все системы, и большая географическая распределённость, и высокие требования к точности вычислений при очень ограниченных временных рамках. Часто в наших проектах появляются элементы исследовательской работы и творческого поиска, направленного на решение нетривиальных проектных задач. Иногда нам приходится комбинировать в рамках одного процесса разработки разные методологии, например, вставляя в общий процесс, близкий к RUP, один или несколько этапов почти чистого scrum, порождая что-то вроде проекта в проекте. Это позволяет нам сохранять невысокий уровень вовлеченности пользователей, связанный с природой проекта, с гибкостью разработки в условиях высокой неопределённости требований. В этом плане для меня важен именно подготовительный этап, во время которого можно выбрать необходимую методологию и выстроить оптимальный процесс разработки. Один из примеров применения гибкой методологии я описал в статье «Применение agile при разработке проекта для государственного заказчика» .

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

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

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

Процесс разработки заказного ПО

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

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

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

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

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

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

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

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

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

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

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

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

Процесс разработки инвестиционного ПО

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

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

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

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

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

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

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

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

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

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

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

Процесс разработки встроенного ПО

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

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

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

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

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

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

Процесс разработки встроенного ПО показан на рисунке 3.

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

Процесс разработки игр

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

Указанные факторы сказываются на процессе разработки игрового ПО. Процесс представлен на рисунке 4.

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

Нужно отметить следующие особенности процесса разработки игрового ПО.

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

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

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

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

Заключение

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

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

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

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

В рамках данного этапа стороны должны осуществить:

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

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

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

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

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

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

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

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

Процесс разработки программного обеспечения можно разбить на этапы (фазы), показанные на рис. 15.

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

Работа над программным обеспечением начинается с составления документа, называемого “Задание на разработку программного обеспечения (техническое задание)”.

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

Техническое задание

Техническое задание включает в себя три этапа: 1) обоснование необхо­димости разработки программы; 2) проведение научно-исследовательских работ; 3) разработка и утверждение технического задания.

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

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

Разработка и утверждение технического задания включает в себя:

Определение требований к программе;

Разработку технико-экономического обоснования разработки программы;

Определение стадий, этапов и сроков разработки программы и документации на нее;

Выбор языков программирования;

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

Согласование и утверждение технического задания.

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

Какими должны быть входные данные?

Какие данные являются корректными и какие ошибочными?

Кто будет использовать программное обеспечение, и каким должен быть интерфейс (средство общения с пользователем)?

Какие упрощения, предположения и допущения можно сделать по отношению к программам?

Какими должны быть выходные данные?

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

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

Проектирование

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

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

1) он имеет средства взаимодействия с внешней средой;

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

Частью интерфейса являются потоки данных. При описании их для каждого модуля необходимо дать ответы на следующие вопросы:

Какие данные можно передать в модуль до начала его выполнения?

Какие упрощения, предположения и допущения сделаны по отношению к модулю?

Что будет с данными после того, как модуль завершит свою работу?

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

Рис. 16. Пример спецификации модуля

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

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

Рабочий проект

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

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

Кодирование должно быть простым. Должен соблюдаться так называемый KISS–принцип: Keep It Simple, Stupid (делай проще, глупец!). Изощренное программирование может обойтись слишком дорого при отладке и модификации программы. Необычное кодирование (например, использование скрытых возможностей машины) часто препятствует отладке программы и, конечно, затрудняет ее использование другими программистами.

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

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

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

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

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

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

Можно привести примеры ошибок в программных комплексах, допущенных при разработке и не обнаруженных при тестировании.

В “Справочнике Microsoft Works” в интерактивной помощи пакета интегрированной обработки информации Works 2.0 функция ЕСЛИ описана как

ЕСЛИ (Условие, ЗначениеЛожь, ЗначениеИстина).

Однако, в действительности, работа данной функции должна иметь следующий вид: ЕСЛИ (Условие, ЗначениеИстина, ЗначениеЛожь). В “Руководстве пользователя Microsoft Works для Windows” пакета Works 3.0 эта ошибка исправлена.

Неудача при запуске первого американского спутника к Венере случилась, вероятнее всего, из–за ошибки в программе – вместо требуемой в операторе точки программист поставил запятую. Оператор на языке Фортран был записан

Do 50 i = 12,525

На самом же деле он должен был выглядеть следующим образом:

Do 50 i = 12.525

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

В 1983 году произошло наводнение в юго–западной части США. Причина заключалась в том, что в компьютер были введены неверные данные о погоде, в результате чего он дал ошибочный сигнал шлюзам, перекрывающим реку Колорадо.

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

Таблица 2

Виды и причины ошибок

В процессе выполнения всех вышеописанных этапов накапливается опреде­ленный опыт, который даст основание для усовершенствования программы.

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

Внедрение

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

Примером добавления новых функций в программный комплекс является текстовый редактор Лексикон 1.3. Данная версия получена из текстового процессора 1.2 путем включения в него функций – импортирование графических файлов в формате PCX в текстовые файлы.

Документация

На рис. 15 прямоугольник, отражающий каждый этап разработки програм­мы, соединен с прямоугольником “Документ”. При этом стрелки направлены в обе стороны. Идеи и решения, используемые на каждом этапе, влияют на документацию, сопровождающую этап, так же, как и документация влияет на идеи и решения.

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

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

Техническое задание должно содержать следующие разделы:

Введение;

Основания для разработки;

Назначение разработки;

Требования к программе и программному изделию;

Требования к программной документации;

Технико-экономические показатели;

Стадии и этапы разработки;

Порядок контроля и приемки.

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

Спецификация является основным программным документом и составляется в соответствии с ГОСТ. Спецификация представляет собой таблицу, состоящую из граф: “Обозначение”, “Наименование”, “Примечание”. В графе “Обозначение” записывают обозначения перечисляемых документов и программ. В графе “Документация” указывают наименования и вид документа или программы. В графе “Примечание” – дополнительные сведения, относящиеся к записанным в спецификации программам.

Описание программы содержит:

– прокомментированные исходные тексты (листинги) модулей программы и управляющего модуля;

– схему разбиения программного комплекса на программные модули;

– схему потоков данных программного комплекса;

– схему взаимодействия программных модулей;

– планы и данные для тестирования программного комплекса;

– другие материалы, иллюстрирующие проект, например, схемы алгоритмов.

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

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

Версия 6.0 Турбо Паскаля, выпущенная в 1990 году, наглядно продемонстрировала преимущества объектно–ориентированной технологии программирования. В комплект поставки новой версии вошла библиотека Turbo Vision, на которой многие тысячи программистов осваивали принципы ООП. За короткий срок появилось множество коммерческих программ, построенных на базе Turbo Vision. Эта библиотека поистине революционизирует процесс разработки интерактивных программ, сокращая до минимума сроки и обеспечивая высочайшее качество программ.

Эволюция технических средств персональных компьютеров привела к повсеместному вытеснению старой “доброй” ОС MS–DOS значительно более мощными системами Windows, программирование для которых существенно сложнее, чем программирование для MS–DOS. С выпуском системы Borland Pascal with Objects корпорация Borland предоставила в распоряжение программистов весьма эффективные средства разработки и отладки программ, рассчитанные на работу под управлением операционной оболочки Windows. Но все же несколько лет назад о создании своих собственных программ под Windows рядовому программисту оставалось только мечтать.

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

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

Анализ требований к проекту

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

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

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

Проектирование

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

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

Реализация

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

Тестирование продукта

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

Результатом тестирования является устранение всех недостатков системы и заключение о ее качестве.

Внедрение и поддержка

Внедрения системы обычно предусматривает следующие шаги:

• установка системы,
• обучение пользователей,
• эксплуатация.

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

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

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