Разработка программ


Обзор процесса разработки программного обеспечения / Хабрахабр

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

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

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

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

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

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

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

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

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

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

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

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

Процесс разработки заказного ПО
Обзор процесса разработки начнём с наиболее общего случая – разработки заказного программного обеспечения. Схема процесса приведена на рисунке 1.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

habrahabr.ru

Разработка программного обеспечения - это... Что такое Разработка программного обеспечения?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

См. также

Ссылки

Литература

  • Иан Соммервилл Инженерия программного обеспечения = 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

dic.academic.ru

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

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

Введение в разработку приложений.

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

Этапы разработки приложений.

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

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

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

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

Поставка. На данном этапе требуется записать программу на магнитный носитель и распространить ее среди пользователей.

Рис. 13.1. Этапы разработки приложений

Заметим, что разработка программного обеспечения (ПО) - итерационный процесс, некоторые этапы которого могут перекрываться.

Рабочие группы и функции участников проекта.

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

 Скорость - быстрое получение промежуточных результатов;  Использование опыта членов группы - разрешение вопросов с использованием опыта всех членов группы.

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

 Эффективность организационной структуры;  Степень важности проекта;  Уровень профессионализма членов группы.

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

Функции участников проекта.

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

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

Промежуточные результаты и их контроль.

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

 Выявить требования.  Разработать проект в общих чертах.  Определить план разработки.  Разработать альфа-версию.  Разработать бета-версию.  Разработать окончательную версию.

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

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

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

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

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

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

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

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

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

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

 Выявлены ли потенциальные пользователи опытной версии? Если нет, то как их определить?  Сколько требуется пользователей для тестирования опытной версии? Кто будет отвечать на их вопросы и обрабатывать отзывы?  Как распространять программный продукт пользователям опытной версии?  sКак пользователи будут инсталлировать опытную версию? Если программа установки не готова, требуется написать файл README с инструкциями по инсталляции.

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

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

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

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

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

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

 Зачем нужен продукт или средство?  При решении какой задачи планируется использовать продукт или средство?  Как решается эта задача в настоящее время? Что заказчику нравится или не нравится в способе решения задачи?  Как часто требуется использовать новый продукт или средство?  Как новый продукт или средство будет упрощать (или усложнять) решение задачи?  Должен ли программный продукт обеспечивать вывод на печать? Как будет использоваться напечатанная информация?  В каких операционных средствах должна работать программа? Какие операционные системы и аппаратные средства имеют пользователи?  Работают ли пользователи в локальной вычислительной сети? Соединены ли они с Internet или intranet?  Какими мониторами располагают пользователи? Какова минимальная разрешающая способность используемых ими дисплеев?  Если система - многопользовательская, какая требуется защита, какие накладываются ограничения и почему?

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

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

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

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

Для создания модели данных:

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

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

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

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

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

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

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

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

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

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

 Является ли разбивка на объекты оправданной и интуитивной?  Облегчают ли действия пользователей объекты и связанные с ними задачи?

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

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

 Облегчает ли интерфейс действия пользователя?  Являются ли поведение и внешний вид прототипа интуитивными для пользователей?  Имеются ли средства повышения скорости работы с приложением?

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

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

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

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

Технический проект определяет главные технологические компоненты и их взаимосвязь. В объектно-ориентированном приложении наименьшими составляющими технического проекта являются интерфейс и связанный с ним код, источники информации, а также другие компоненты, с помощью которых обеспечивается взаимодействие между интерфейсом и данными. Интерфейс можно разработать в Visual Basic, HTML, или Visual C++. Источниками данных могут служить Microsoft Access, источники данных ODBC, например, база данных SQL Server, текстовые файлы или документы других приложений, например, рабочий лист Microsoft Excel или документ Microsoft Word. Компонентами управления данными могут быть объекты OLE Automation, библиотеки ODBC, объекты доступа к данным, либо ядро Visual Basic Jet.

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

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

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

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

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

Документирование программного продукта. Составление документации по программному продукту необходимо начинать на этапе разработки.

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

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

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

Для недавнего времени документация выходила в напечатанном виде. Однако сейчас описание программ распространяется, используя электронные средства, что позволяет намного проще и дешевле обновлять документацию. С программным продуктом можно связать справочные файлы, обеспечивая при выполнении задач конспектную подсказку. Кроме того, имеется возможность встроить в продукт мастера и обучающие программы. При написании руководств можно использовать несколько приложений. Например, если требуется создать справочные файлы, используйте Microsoft Word или Microsoft Help Compiler. Чтобы создать файлы HTML, применяется редактор HTML. Microsoft Help Compiler поставляется вместе с профессиональной версией Visual Basic.

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

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

Запись на магнитный носитель и поставка программного продукта.

С самого начала работы над программным продуктом необходимо принять решение о том, как распространять систему: на дискетах или CD-ROM, либо переслать ее через Internet или intranet, либо просто установить ее на совместно используемом диске.

Кроме того, необходимо обеспечить пользователя информацией о том, как инсталлировать программный продукт. Пользователь составляет свое мнение о системе, начиная с ее установки, поэтому следует сделать инсталляцию максимально простой. Лучше всего создать программу установки (обычно SETUP.EXE) и дать к ней некоторые пояснения (файл README). Не следует дожидаться полного завершения проекта: необходимо время на разработку программы установки и ее создание. Если же время истекло, а программа установки не готова, то следует написать четкие инструкции по инсталляции, а затем поручить одному из членов группы проверить их.

www.mini-soft.ru

Этапы разработки программы

Этапы разработки программы

1.3.3. Этапы разработки

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

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

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

3. Разработка или выбор алгоритма решения задачи — выполняется на осно­ве ее математического описания. Многие задачи можно решить различными способами. Программист должен выбрать оптимальное решение. Неточности в постановке, анализе задачи или разработке алгоритма могут привести к скрытой ошибке — программист получит неверный результат, считая его правильным.

4. Проектирование общей структуры программы — формируется модель решения с последующей детализацией и разбивкой на подпрограммы, определяется "архитектура" программы, способ хранения информации (набор переменных, массивов и т. п.).

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

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

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

8. Публикация результатов работы, передача заказчику для эксплуатации.

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

&nbspпредыдущая &nbsp &nbsp &nbsp &nbsp&nbspменю &nbsp &nbsp &nbsp &nbspвверх &nbsp &nbsp &nbsp &nbsp&nbspследующая

tat67183862.narod.ru

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

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

Наш опыт разработки ПО с 1997 года гарантирует высокое качество результатов создания программ различного назначения.

Наша компетенция

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

  • Внедрение информационных систем на базе 1С:Предприятия.
  • Разработка или модификация корпоративных информационных систем.
  • Создание Интернет сайтов.
  • Разработка систем консолидированной управленческой отчётности.
  • Интеграция Интернет сайтов с информационными системами уровня предприятия.
  • Разработка программного обеспечения для серверного оборудования.
  • Разработка прикладного программного обеспечения для настольных компьютеров.
  • Разработка программ для мобильных платформ Android, iOS, Windows.
  • Разработка отраслевых решений: транспортные и логистические информационные системы.
  • Разработка специфичного софта для защиты информации и информационных потоков от несанкционированного доступа.

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

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

В рамках разработки информационных систем чаще всего мы решаем задачи:

  • Управление складской логистикой.
  • Управление транспортной логистикой.
  • Финансовый и налоговый учет.
  • Консолидированная управленческая отчётность.
  • Управление строительными объектами от жилищного до промышленного.
  • Распределенная обработка и анализ данных.

Клиенты, доверившие нам разработку ПО

 

Группа Компаний «СТРОЙНЕФТЕГАЗ АЛЬЯНС»

 

ТД «Регионы»

 

Мир Инструмента

 

ЭРМА СОФТ Менеджмент

 

Глобал Тревел

 

Максиома-Строй

Сколько стоит разработка программного обеспечения на заказ?

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

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

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

Нижняя граница стоимости разработки ПО на заказ начинается от 100 тысяч рублей.

Могут быть исключения, если программа небольшая.

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

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

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

  1. Сбор и определение требований к конечному продукту.
  2. Коммерческое предложение с предварительной оценкой стоимости выполнения работ.
  3. Разработка и согласование технического задания.
  4. Составление календарного плана выполнения работ.
  5. Определение окончательной стоимости выполнения работ.
  6. Согласование и подписание договора на разработку программного обеспечения.
  7. Приёмо-сдаточные работы тестовой версии.
  8. Тестирование программного обеспечения.
  9. Опытная эксплуатация в рабочем режиме.
  10. Окончательная приёмка программного продукта.
  11. Передача в промышленную эксплуатацию.

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

Вы можете получить предварительную консультацию по телефону или в Skype или сразу отправить техническое задание на электронную почту:

  • Телефон в Москве: +7 (926) 083-80-84
  • Skype: #
  • E-Mail: #

Наши специалисты Бесплатно окажут предварительные консультации и дадут оценку возможной стоимости проекта.

www.msav.ru

Разработка программ, разработка ПО на заказ, торговые роботы

www.informicus.ru

ГЛАВНАЯ

Разработка на заказ

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

подробнее

Разработка и внедрение ЭТП

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

подробнее

Разработка торговых роботов

Наша компания занимается разработкой приложений для торговли на бирже начиная с 2006 года. Мы создаем торговых роботов для работы с различными терминалами (Quik, NetInvestor и др.) и под шлюзы бирж (ММВБ, РТС, PlazaII, Fix). Нашими специалистами накоплен богатый опыт реализации всевозможных торговых стратегий, создания типовых решений, прохождения сертификаций реализованных приложений и формализации пожеланий заказчика с их строгим алгоритмическим описанием.

подробнее

Арбитражный робот

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

подробнее

FORSage

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

подробнее

FOR Manager

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

подробнее

Компания Informicus является партнером Microsoft со статусом Certified Partner.

Среди наших клиентов:

Разработка заказного программного обеспечения обычно происходит следующим образом (подробнее о других возможных технологиях разработки и управления проектами можете прочитать в разделе Статьи):

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

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

Среди реализованных проектов в области разработки заказных решений:

  • Система электронного документооборота, предназначенная для автоматизации процесса получения государственной аккредитации медицинскими учреждениями в США.
  • Автоматизированная система обработки вызовов Call-центра в крупной страховой компании.
  • Электронная торговая площадка для проведения аукционов с использованием механизма электронной цифровой подписи (ЭЦП).
  • Информационная система управления лояльностью клиентов интернет холдинга, предназначенная для повышения лояльности клиентов и эффективности контактов с ними.
  • Информационная система ценообразования предназначена для автоматизации процедуры ценообразования на товары компании, формирования прайс-листов, учета цен и тарифов, хранения информации о конкурентах, формирования различных отчетов.
  • Система электронного документооборота в сфере ипотечного страхования, предназначенная для повышения эффективности работы страховых агентов и повышения качества страховых услуг компании.
  • Автоматизированная система, предназначенная для отслеживания и анализа ситуации на фондовом рынке со встроенной подпрограммой торговых операций.
  • Автоматизированная система взаимодействия с системой Российского союза автостраховщиков (РСА).
  • Система учета документов производственной программы Управления Капитального Строительства (УКС), предназначенная для автоматизации документооборота по объектам строительства.

телефон/факс: +7 (495) 646-0612/687-9964

105120, г. Москва, ул. Нижняя Сыромятническая,д. 5/7

[email protected]

разработка программ - это... Что такое разработка программ?

разработка программ

 

разработка программ —[Л.Г.Суменко. Англо-русский словарь по информационным технологиям. М.: ГП ЦНИИС, 2003.]

Тематики

  • информационные технологии в целом

Справочник технического переводчика. – Интент. 2009-2013.

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

Смотреть что такое "разработка программ" в других словарях:

  • Быстрая разработка программ — технология программирования, обеспечивающая ускоренную разработку и модификацию приложений за счет использования объектно ориентированного и визуального программирования. По английски: Rapid Application Development Синонимы английские: RAD См.… …   Финансовый словарь

  • планирование и разработка программ — — [http://www.iks media.ru/glossary/index.html?glossid=2400324] Тематики электросвязь, основные понятия EN planning and programming …   Справочник технического переводчика

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

  • разработка плана (проекта программ) — Выработка стратегического замыла, формулировка целей, анализ ресурсных возможностей, путей и способов достижения целей, обоснование избранного варианта действий, состояние, обсуждение, принятие плановых, проектных, программных документов.… …   Справочник технического переводчика

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

  • РАЗРАБОТКА — ПЛАНА, проекта, программ выработка стратегического замысла, формулировка целей, анализ ресурсных возможностей, путей и способов достижения целей, обоснование избранного варианта действий, составление, обсуждение, принятие плановых, Проектных,… …   Экономический словарь

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

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

  • разработка — 3.6.6. разработка : Стадия конструкторской ПП, выполняемая при помощи CAD системы, в ходе которой разрабатывается подробная 3D мoдeль изделия, а также 3D мoдeли узлов, агрегатов и основных (базовых) деталей, на базе которых формируются 2D… …   Словарь-справочник терминов нормативно-технической документации

  • Разработка учебно-тренировочных систем (instructional systems development, ISD) — P. у. т. с. это методический, систематический подход к проектированию, реализации и оценке программ обучения. Методология ISD представляет собой апробированный набор процедур, используемый в вооруженных силах США для разраб. программ подготовки… …   Психологическая энциклопедия

Книги

  • Разработка программ по формированию экологической культуры, здорового и безоп. образа жизни. Мет. (ФГОС), Гун. … Подробнее  Купить за 240 руб
  • Разработка программ по формированию экологической культуры, здорового и безопасного образа жизни. Методическое пособие, Г. Е. Гун. В методическом пособии изложены основные рекомендации по разработке программы формирования экологической культуры, здорового и безопасного образа жизни в начальной школе, работающей по… Подробнее  Купить за 184 руб
  • Разработка программ по формированию экологической культуры, здорового и безопасного образа жизни. Методическое пособие. ФГОС, Гун Г.Е.. Издание адресовано руководителям школ, учителям начальных классов, а также педагогическим коллективам образовательных учреждений… Подробнее  Купить за 153 руб
Другие книги по запросу «разработка программ» >>

technical_translator_dictionary.academic.ru


Смотрите также