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

Аннотация: Понятие процесса разработки ПО. Универсальный процесс. Текущий процесс. Конкретный процесс. Стандартный процесс. Совершенствование процесса. Pull/Push стратегии. Классические модели процесса: водопадная модель, спиральная модель. Фазы и виды деятельности.

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

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

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

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

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

Каждый виток имеет следующую структуру (секторы):

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Заключение

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

Последовательность этапов

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

Модель ЖЦ разработки ПО схематически объясняет, каким образом будут выполняться действия по разработке ПО, посредством описания «последовательности» этих действий. Такая последовательность может быть или не быть линейной, поскольку этапы могут следовать друг за другом, повторяться или происходить одновременно.

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

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

Каскадная модель

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

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

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

Время для обсуждения в группе – 3 минуты.

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

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

Дается 2 минуты разработчикам для определения модели и причин выбора этой модели.

Третья микрогруппа читает записанные термины и дает им пояснение.

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

Спецификация (определение требований к программе):

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

Разработка алгоритма:

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

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

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

Кодирование:

После проведения спецификации и составления алгоритма решения, используемый алгоритм в итоге будет записан на необходимом языке программирования (Pascal, Delphi, C++ и др.). Результатом этапа кодирования является готовая программа.

Этапы разработки программы. Отладка:

На данном этапе программист занимается отладкой программы, то есть поиском и устранением ошибок. Последние делятся на две группы: алгоритмические и синтаксические (ошибки в тексте исходной программы). Из этих двух групп ошибок наиболее легко устранить синтаксические ошибки, тогда как алгоритмические ошибки определить достаточно трудно.

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

Тестирование:

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

Создание справочной системы:

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

Кроме справочной информации справочная система содержит необходимые инструкции по инсталляции программы. Обычно их представляют в виде файла Readme разных форматов: *.doc, *.txt, *.htm. Более подробно рассматриваемый этап разработки программы будет описан позже.

Создание установочного диска (CD-ROM):

Инсталяционный диск (CD-ROM) разработчики создают для того, чтобы пользователи могли самостоятельно, без помощи программиста, проинсталировать данную программу на свой ПК.

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

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

Как осуществляется программирование, какие процес­сы происходят при этом?

Решение любой сложной задачи состоит из четырех этапов :

1) Осознание и формулирование задачи, когда решающий задачу определяет, что дано и какова цель (что требуется получить в итоге);

2) Разработка плана, в котором раскрывается стра­тегия решения (стратегия достижения цели);

3) Выполнение (реализация) плана. При этом любой сложный план преобразует­ся в определенную последовательность достаточно простых (по сравнению с исходной задачей) действий;

4) Проверка правильности решения;

5) Документирование;

6) Сдача решения потребителю.

Эти этапы применительно к программированию называ­ют соответственно так:

1) определение требований к ПО и целей проектирования ПО (постановка задачи, ее формализация и разработка ТЗ);

2) проектирование ПО (разработка метода решения, структуры программы и алгоритмов);

3) кодирование (написанием собственно программы на выбранном языке программирования) и отладка программы;

4) тестирование программы, в том числе и на стороне Заказчика (по ПМИ);

5) выпуск документации (руководство программиста, руководство системного программиста и т.п.);

6) выпуск программного продукта для передачи потребителю (Заказчику).

По ГОСТ 19.102-77 «Стадии разработки» определены следующие этапы разработки ПО:

1) разработка ТЗ (ему соответствует названный выше этап «Постановка задачи и ее формализация»)

2) разработка ЭП (им соответствует названный выше этап «разработка метода решения,

3) разработка ТП структуры программы и алгоритмов»)

4) разработка РП (он включает названные выше этапы «Кодирование и отладка», «Тестирование» и «Документирование».

5) внедрение (ему соответствует названный выше этап «Выпуск программного продукта для передачи потребителю (Заказчику)»).

Более подробно о некоторых этапах (или подэтапах) разработки ПО.

Постановка задачи

Выполняется на языке предметной области, т.е. с использованием используемой в предметной области технической терминологии (антенна, телевизор, резистор...). На этом этапе:

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

Формулируется цель (разработки), состоящая или в получении нового объекта, или в обработке характеристик исходных объектов (с целью нахождения какой-то статистики, например);

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

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

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

Теория графов;

Теория вероятностей;

Теория массового обслуживания;

Теория множеств

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

Хорошая математическая постановка задачи часто позволяет сразу увидеть способ решения .

Поиск метода решения задачи (на этапе проектирования)

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

Те, которые уже ранее встречались, и решение их уже известно;

Те, для которых известна постановка, и решение их не представляет (для программиста) труда.

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

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

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

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

Объектно-ориентированная (по сути тоже восходящий подход, но не процедурный);

Логическая (логико-ориентированная);

Функциональная.

Мы об этих парадигмах поговорим чуть позже.

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

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

2).Подготовка программы для ПЭВМ , т.е. перенос рукописного текста программы с бумаги на машинный носитель информации. Для этого используется текстовый редактор.

3).Компиляция текста программы в машинный код с помощью программы, называемой компилятором.

Машинный код

(понятен ЭВМ)

Замечание : фраза, что программа – это алгоритм, составленный на языке, понятном ЭВМ , означает, что при наличии посредника-компилятора текст, написанный на ЯВУ, уже считается понятным ЭВМ. Этот посредник-компилятор занимается переводом текста программы с ЯВУ на машинный язык.

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

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

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

4).Компоновка (линковка) программы : т.е. объединение отдельных частей программы, добавление стандартных подпрограмм и установление необходимых связей между частями программы. Эти действия выполняются программой, называемой линкером (компоновщиком).

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

Замечание: компилятор Турбо-Паскаля (и Free Pascal) производит компиляцию сразу в исполняемый код (отдельный этап линковки не требуется).

Все адресные ссылки в загрузочном модуле - относительны (относительно начала загрузочного модуля). Перед передачей программе управления надо настроить все адресные ссылки на начальный адрес размещения программы в оперативной памяти. Эту функцию выполняет Загрузчик .

Отладка и Тестирование: После получения готового к выполнению кода программы начинается этап ее отладки и тестирования - поиск ошибок в программе (debugging), например, ошибок при работе с данными, логических ошибок и т.п.

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

Различают методы тестирования : а) белого ящика (структурное тестирование) и б) черного ящика (функциональное тестирование - может начинаться сразу после получения ТЗ).

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

По завершении (успешном) тестирования программа готова к передаче ее заказчику.

Замечание:

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

4. Средства записи и классификация алгоритмов .