Руководство по организации процесса разработки по

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

Введение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Заключение

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

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

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

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

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

У нас есть два основных принципа:

1. Команда делает проекты качественно, в срок и с прибылью для компании;
2. Большинство решений, связанных с реализацией проектов, команда принимает самостоятельно, так как основные процессы в компании автоматизированы и прозрачны.

Проект любого масштаба мы разделяем на семь обязательных этапов.

1. Выбираем методологию

От этого зависит состав команды, порядок и даже график работы. Можно выбрать классическую (waterfall) или гибкую (agile). 

При классической методологии:

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

При гибкой методологии:

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

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

2. Определяем роли и состав команды

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

Классический отдел разработки состоит из следующих сотрудников:

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

• frontend- и backend-разработчик/fullstack-разработчик: первые занимаются визуальной и вычислительной частью проекта, а второй, как универсальный солдат, владеет знаниями разных технологий;

• тестировщик: обеспечивает качество программного продукта с самого начала разработки и до его финальной сдачи;

• тимлид: декомпозирует и делегирует задачи, проводит код-ревью и поддерживает боевой дух команды;

• дизайнер: определяет внешний вид продукта, его интерфейс и юзабилити;

• аналитик: проектирует и оптимизирует процессы, руководит внедрением новых IT-систем и адаптирует систему работы к новым задачам;

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

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

3. Проводим CustDev, собираем требования с клиентов, пишем техническое задание

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

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

• оценить задачу по бюджету, срокам и объему человеко-часов;
• упростить сдачу-приемку проекта;
• объяснить специалисту, как устроена работа проекта и какую документацию нужно готовить «на выходе».

4. Обеспечиваем команду техническими инструментами

За настройку технической инфраструктуры отвечает системный администратор. Строить боевую инфраструктуру сразу не обязательно – выполните минимальную часть, чтобы обеспечить команде место для работы. 

Настройте:

• репозиторий для кодовой базы проекта;
• общие инструменты организации процесса разработки, если они нужны – например, таск-трекер (Jira, Redmine, Trello и другие);
• рабочее окружение: сервисы и приложения, от которых будет зависеть ваш продукт (например, Swagger для документации API).

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

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

---

Читайте также:
Разработка мобильного приложения: как создать прототип и зачем нужен MVP
Кроссплатформенная и нативная разработка мобильных приложений в 2021 году
12 шагов к успешному запуску детского приложения

---

5. Планируем работу команды

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

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

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

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

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

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

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

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

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

Методы структурного анализа для проектирования ПО

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

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

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

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

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

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

Скачать
файл

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

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

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

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

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

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

Выделим несколько самых часто встречаемых моделей из первых трёх категорий:

• функциональная модель SADT (Structured Analysis and Design Technique);
• модель IDEF3;
• DFD (Data Flow Diagrams) — диаграммы потоков данных. Модель «сущность — связь» (ERM — Entity-Relationship Model), которая описывает отношения между данными. Обычно применяется в структурном анализе и проектировании. При этом она является подмножеством объектной модели предметной области.

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

Первая стадия работы над ПО — подготовка

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

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

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

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

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

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

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

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

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

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

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

Следующий этап — опытная эксплуатация

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

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

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

Конечный этап любого проекта — завершение

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

Вспомогательные процессы при разработке ПО

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

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

Факторы, влияющие на разработку ПО

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

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

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

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

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

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

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

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

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

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

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

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

Waterfall (каскадная модель, или «водопад»)

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

Преимущества:

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

Недостатки:

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

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

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

V-образная модель (разработка через тестирование)

Данную модель можно назвать улучшенной версией «водопада». Заказчик совместно с командой разработчиков формирует требования к системе и описывает, каким образом будет выполняться ее тестирование на каждой стадии. V-образную модель начали использовать в 1980-х.

Преимущества:

• Минимальное количество ошибок в архитектуре программного обеспечения.

Недостатки:

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

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

Incremental Model (инкрементная модель)

Английское слово increment можно перевести как «приращение». Данную модель начали использовать ещё в 1930-х. В качестве примера возьмём разработку социальной сети.

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

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

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

Преимущества:

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

Недостатки:

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

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

Iterative Model (итеративная модель)

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

Преимущества:

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

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

Недостатки:

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

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

Spiral Model (спиральная модель)

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

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

Преимущества:

• Сосредоточение внимания на анализе рисков.

Недостатки:

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

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

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

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

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

Преимущества:

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

Недостатки:

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

В рамках данного подхода применяется целый ряд всевозможных техник, методологий и приемов. Выделим некоторые из них:

• Scrum. Участники проекта находятся в постоянном взаимодействии и обсуждают текущий прогресс.
• Kanban. Используется виртуальная доска с задачами. Последовательность выполнения таких задач не определяется.
• RUP. Наличие четких стадий планирования, уточнения и построения новых итерация программного обеспечения.
• Extreme Programming. Частые обновления версии продукта и отыскивание наиболее скоростных решений.

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

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

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

Навыки и умения разработчика ПО

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

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

Такой специалист должен обладать следующими навыками:

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

Фрондендеру необходимо уметь:

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

Бэкендер выполняет следующие задачи:

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

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

• знание нескольких языков программирования, распространенных библиотек и фреймворков;
• навыки работы в системе управления версиями Git, применение для сборки и развертывания приложения Docker или Kubernetes;
• понимание шаблонов проектирования и владение гибкими методологиями (скажем, Agile).

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

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

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

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

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

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

Определения

IEEE определяет разработку программного обеспечения как:

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

(2) Изучение подходов, как в приведенном выше утверждении.

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

(2) Изучение подходов, как в приведенном выше утверждении.

Фриц Бауэр, немецкий программист, определяет разработку программного обеспечения как:

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

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

Эволюция программного обеспечения

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

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

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

Законы об эволюции программного обеспечения

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

• S-тип (статический тип) – это программное обеспечение, которое работает строго в соответствии с определенными спецификациями и решениями. Решение и способ его достижения сразу же понимаются перед кодированием. Программное обеспечение s-типа меньше всего подвержено изменениям, поэтому это самое простое из всех. Например, программа-калькулятор для математических вычислений.
• P-тип (практический тип) – это программное обеспечение с набором процедур. Это определяется именно тем, что могут делать процедуры. В этом программном обеспечении спецификации могут быть описаны, но решение не очевидно сразу. Например, игровое программное обеспечение.
• Электронный тип (встроенный) – это программное обеспечение тесно связано с требованиями реальной среды. Это программное обеспечение имеет высокую степень эволюции, поскольку в реальных ситуациях происходят различные изменения в законах, налогах и т. Д. Например, программное обеспечение для онлайн-торговли.

Эволюция программного обеспечения E-Type

Lehman дал восемь законов развития программного обеспечения E-Type –

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

Программные парадигмы

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

Парадигма программирования – это подмножество парадигмы разработки программного обеспечения, которая является еще одним подмножеством парадигмы разработки программного обеспечения.

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

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

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

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

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

• дизайн
• техническое обслуживание
• программирование

Парадигма программирования

Эта парадигма тесно связана с программным аспектом разработки программного обеспечения. Это включает –

• кодирование
• тестирование
• интеграция

Необходимость разработки программного обеспечения

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

• Большое программное обеспечение. Построить стену легче, чем дом или здание, так же, как размер программного обеспечения становится большим, и инжиниринг должен сделать научный процесс.
• Масштабируемость – если процесс программного обеспечения не основывается на научных и технических концепциях, было бы легче воссоздать новое программное обеспечение, чем масштабировать существующее.
• Затраты. Поскольку индустрия оборудования продемонстрировала свое мастерство, а огромное производство снизило цены на компьютерное и электронное оборудование. Но стоимость программного обеспечения остается высокой, если надлежащий процесс не адаптирован.
• Динамическая природа . Постоянно растущая и адаптирующаяся природа программного обеспечения в значительной степени зависит от среды, в которой работает пользователь. Если природа программного обеспечения постоянно меняется, необходимо внести новые улучшения в существующий. Это где разработка программного обеспечения играет хорошую роль.
• Управление качеством – лучший процесс разработки программного обеспечения обеспечивает лучший и качественный программный продукт.

Характеристики хорошего программного обеспечения

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

• эксплуатационный
• переходный
• техническое обслуживание

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

эксплуатационный

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

• бюджет
• Юзабилити
• КПД
• правильность
• функциональность
• надежность
• Безопасность
• безопасности

переходный

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

• портативность
• Interoperability
• Повторное использование
• адаптируемость

техническое обслуживание

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

• модульность
• Ремонтопригодность
• гибкость
• Масштабируемость

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

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

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

Деятельность SDLC

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

связь

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

Сбор требований

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

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

Технико-экономическое обоснование

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

Системный анализ

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

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

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

кодирование

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

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

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

интеграция

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

Реализация

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

Эксплуатация и техническое обслуживание

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

диспозиция

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

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

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

Модель водопада

Модель «Водопад» – самая простая модель парадигмы разработки программного обеспечения. В нем говорится, что все фазы SDLC будут функционировать один за другим линейно. То есть, когда первая фаза закончена, тогда только вторая фаза начнется и так далее.

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

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

Итерационная модель

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

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

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

Спиральная модель

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

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

V – модель

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

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

Это позволяет и проверке, и проверке идти параллельно. Эта модель также известна как модель верификации и валидации.

Модель большого взрыва

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

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

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

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

Управление проектами программного обеспечения

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

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

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

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

Программный проект

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

Необходимость управления программным проектом

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

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

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

Менеджер программных проектов

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

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

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

Управление людьми

• Выступать в качестве руководителя проекта
• Уход с заинтересованными сторонами
• Управление человеческими ресурсами
• Настройка иерархии отчетов и т. Д.

Управление проектом

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

Деятельность по управлению программным обеспечением

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

• Планирование проекта
• Управление областью
• Оценка проекта

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

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

Управление областью

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

Во время управления содержанием проекта необходимо:

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

Оценка проекта

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

Оценка проекта может включать в себя следующее:

• Оценка размера программного обеспечения

  Размер программного обеспечения может быть оценен либо в единицах KLOC (Kilo Line of Code), либо путем расчета количества функциональных точек в программном обеспечении. Строки кода зависят от практики кодирования, а функциональные точки различаются в зависимости от требований пользователя или программного обеспечения.

• Оценка усилий

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

• Оценка времени

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

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

• Оценка затрат

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

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

Размер программного обеспечения может быть оценен либо в единицах KLOC (Kilo Line of Code), либо путем расчета количества функциональных точек в программном обеспечении. Строки кода зависят от практики кодирования, а функциональные точки различаются в зависимости от требований пользователя или программного обеспечения.

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

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

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

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

Методы оценки проекта

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

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

Техника Разложения

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

Есть две основные модели –

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

Методика эмпирической оценки

Этот метод использует эмпирически полученные формулы для оценки. Эти формулы основаны на LOC или FP.

• Модель Putnam

  Эта модель сделана Лоуренсом Х. Путнэмом, который основан на распределении частот Нордена (кривая Рэлея). Модель Putnam отображает время и усилия, необходимые с размером программного обеспечения.

• COCOMO

  COCOMO расшифровывается как COnstructive COst MOdel, разработанная Barry W. Boehm. Он делит программный продукт на три категории программного обеспечения: органическое, полуотдельное и встроенное.

Эта модель сделана Лоуренсом Х. Путнэмом, который основан на распределении частот Нордена (кривая Рэлея). Модель Putnam отображает время и усилия, необходимые с размером программного обеспечения.

COCOMO расшифровывается как COnstructive COst MOdel, разработанная Barry W. Boehm. Он делит программный продукт на три категории программного обеспечения: органическое, полуотдельное и встроенное.

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

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

Для составления расписания проекта необходимо:

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

Управление ресурсами

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

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

Управление ресурсами включает в себя –

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

Управление рисками проекта

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

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

Процесс управления рисками

В процессе управления рисками участвуют следующие виды деятельности:

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

Выполнение проекта и мониторинг

На этом этапе задачи, описанные в планах проекта, выполняются в соответствии с их графиками.

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

Эти меры включают в себя –

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

Управление коммуникациями проекта

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

Общение может быть устным или письменным. Процесс управления связью может иметь следующие этапы:

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

После закрытия команда переходит к следующему этапу или проекту.

Управление конфигурацией

Управление конфигурацией – это процесс отслеживания и контроля изменений в программном обеспечении с точки зрения требований, дизайна, функций и развития продукта.

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

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

базисный

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

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

Смени управление

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

Изменение конфигурации продукта проходит через следующие шаги –

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

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

• Анализ – Влияние запроса на изменение анализируется с точки зрения графика, стоимости и необходимых усилий. Общее влияние предполагаемого изменения на систему анализируется.

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

• Выполнение – если на предыдущем этапе было решено выполнить запрос на изменение, на этом этапе предпринимаются соответствующие действия для выполнения изменения, при необходимости выполняется тщательный пересмотр.

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

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

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

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

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

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

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

Инструменты управления проектами

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

Доступны инструменты, которые помогают эффективно управлять проектами. Некоторые описаны –

Диаграмма Ганта

Диаграммы Ганта были разработаны Генри Ганттом (1917). Он представляет график проекта относительно периодов времени. Это горизонтальная гистограмма с столбцами, представляющими действия и время, запланированное для действий проекта.

Диаграмма PERT

Диаграмма PERT (Program Evaluation & Review Technique) – это инструмент, который изображает проект в виде сетевой диаграммы. Он способен графически представлять основные события проекта как параллельно, так и последовательно. События, которые происходят одно за другим, показывают зависимость более позднего события от предыдущего.

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

Гистограмма ресурса

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

Анализ критического пути

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

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

Требования к программному обеспечению

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

Требование техники

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

Целью проектирования требований является разработка и сопровождение сложного и описательного документа «Спецификация системных требований».

Требование инженерного процесса

Это четырехэтапный процесс, который включает в себя:

• Технико-экономическое обоснование
• Сбор требований
• Спецификация требований к программному обеспечению
• Проверка требований к программному обеспечению

Давайте посмотрим на процесс вкратце –

Технико-экономическое обоснование

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

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

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

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

Сбор требований

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

Спецификация требований к программному обеспечению

SRS – это документ, созданный системным аналитиком после сбора требований от различных заинтересованных сторон.

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

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

SRS должен придумать следующие функции:

• Требования пользователя выражены на естественном языке.
• Технические требования выражены на структурированном языке, который используется внутри организации.
• Описание дизайна должно быть написано в псевдокоде.
• Формат форм и печать графического интерфейса.
• Условные и математические обозначения для DFD и т. Д.

Проверка требований к программному обеспечению

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

• Если они могут быть практически реализованы
• Если они действительны и согласно функциональности и области программного обеспечения
• Если есть какие-то неясности
• Если они завершены
• Если они могут быть продемонстрированы

Процесс выявления требований

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

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

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

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

• Документация. Все формальные и неформальные, функциональные и нефункциональные требования документируются и предоставляются для последующей обработки.

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

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

Методы выявления требований

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

Существуют различные способы определения требований

Интервью

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

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

Обзоры

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

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

Документ с предварительно определенным набором объективных вопросов и соответствующими вариантами передается всем заинтересованным сторонам для ответа, которые собираются и компилируются.

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

Анализ задач

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

Анализ предметной области

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

мозговая атака

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

макетирования

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

наблюдение

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

Требования к программному обеспечению Характеристики

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

Полные спецификации требований к программному обеспечению должны быть:

• Очистить
• Правильный
• последовательный
• Последовательный
• понятный
• модифицируемый
• проверяемый
• Приоритетное
• недвусмысленный
• прослеживаемый
• Достоверный источник

Требования к программному обеспечению

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

В целом требования к программному обеспечению следует разделить на две категории:

Функциональные требования

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

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

Примеры –

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

Нефункциональные требования

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

Нефункциональные требования включают в себя –

• Безопасность
• логирование
• Место хранения
• конфигурация
• Спектакль
• Стоимость
• Interoperability
• гибкость
• Аварийное восстановление
• доступность

Требования классифицированы логически как

• Должно быть : программное обеспечение не может работать без них.
• Должно иметь : Расширение функциональности программного обеспечения.
• Может иметь : Программное обеспечение все еще может нормально функционировать с этими требованиями.
• Список пожеланий : эти требования не соответствуют каким-либо целям программного обеспечения.

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

Требования к пользовательскому интерфейсу

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

• прост в эксплуатации
• быстрый ответ
• эффективно обрабатывать ошибки в работе
• обеспечение простого, но последовательного пользовательского интерфейса

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

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

Программный системный аналитик

Системный аналитик в ИТ-организации – это человек, который анализирует требования к предлагаемой системе и обеспечивает правильное и правильное оформление и документирование требований. Роль аналитика начинается на этапе анализа программного обеспечения SDLC. Аналитик обязан убедиться, что разработанное программное обеспечение соответствует требованиям клиента.

Системные аналитики имеют следующие обязанности:

• Анализ и понимание требований предполагаемого программного обеспечения
• Понимание того, как проект будет способствовать достижению целей организации
• Определить источники требований
• Проверка требований
• Разработать и внедрить план управления требованиями
• Документация по бизнес, техническим, технологическим и технологическим требованиям
• Координация с клиентами для определения приоритетности требований и устранения и неоднозначности
• Завершение критериев приемки с клиентом и другими заинтересованными сторонами

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

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

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

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

По словам Тома ДеМарко (a) (Software Engineer): «Вы не можете контролировать то, что не можете измерить». По его словам, очень ясно, насколько важны меры программного обеспечения.

Давайте посмотрим некоторые метрики программного обеспечения:

• Размер метрики – LOC (Lines of Code), в основном рассчитывается в тысячах доставленных строк исходного кода и обозначается как KLOC.

  Функция Point Count – это мера функциональности, предоставляемой программным обеспечением. Функция Point count определяет размер функционального аспекта программного обеспечения.

• Метрики сложности – цикломатическая сложность McCabe количественно определяет верхнюю границу числа независимых путей в программе, которая воспринимается как сложность программы или ее модулей. Он представлен в терминах понятий теории графов с использованием графа потока управления.

• Метрики качества – Дефекты, их типы и причины, последствия, интенсивность и их значение определяют качество продукта.

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

• Метрики процесса. На различных этапах SDLC используемые методы и инструменты, стандарты компании и эффективность разработки являются метриками процесса программного обеспечения.
• Метрики ресурса – Усилие, время и различные используемые ресурсы, представляют метрики для измерения ресурса.

Размер метрики – LOC (Lines of Code), в основном рассчитывается в тысячах доставленных строк исходного кода и обозначается как KLOC.

Функция Point Count – это мера функциональности, предоставляемой программным обеспечением. Функция Point count определяет размер функционального аспекта программного обеспечения.

Метрики качества – Дефекты, их типы и причины, последствия, интенсивность и их значение определяют качество продукта.

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

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

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

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

Разработка программного обеспечения – это первый шаг в SDLC (жизненный цикл разработки программного обеспечения), который переносит концентрацию с проблемной области на область решения. Он пытается указать, как выполнить требования, указанные в SRS.

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

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

• Архитектурное проектирование – архитектурное проектирование является высшей абстрактной версией системы. Он идентифицирует программное обеспечение как систему со многими компонентами, взаимодействующими друг с другом. На этом уровне дизайнеры получают представление о предлагаемой области решения.
• Проектирование высокого уровня. Проектирование высокого уровня разбивает концепцию архитектурного дизайна «один объект-несколько компонентов» на менее абстрагированное представление подсистем и модулей и отображает их взаимодействие друг с другом. Проектирование высокого уровня фокусируется на том, как система вместе со всеми ее компонентами может быть реализована в виде модулей. Он распознает модульную структуру каждой подсистемы и их взаимосвязь и взаимодействие друг с другом.
• Детальный дизайн – Детальный дизайн имеет дело с частью реализации того, что рассматривается как система и ее подсистемы в предыдущих двух проектах. Более подробно о модулях и их реализациях. Он определяет логическую структуру каждого модуля и их интерфейсы для связи с другими модулями.

Модульность

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

Модульный дизайн непреднамеренно следует правилам стратегии «разделяй и властвуй», потому что есть много других преимуществ, связанных с модульным дизайном программного обеспечения.

Преимущество модульности:

• Меньшие компоненты легче поддерживать
• Программа может быть разделена на основе функциональных аспектов
• Желаемый уровень абстракции можно внести в программу
• Компоненты с высокой когезией могут быть снова использованы повторно
• Возможно одновременное выполнение
• Желаемый с точки зрения безопасности

совпадение

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

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

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

пример

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

Сцепление и сцепление

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

когезия

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

Существует семь типов сплоченности, а именно –

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

Связь

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

Существует пять уровней сцепления, а именно –

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

В идеале ни одна муфта не считается лучшей.

Проверка дизайна

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

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

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

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

Инструменты анализа и проектирования программного обеспечения

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

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

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

Диаграмма потока данных

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

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

Типы ДФД

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

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

DFD Компоненты

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

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

Уровни DFD

• Уровень 0 – DFD самого высокого уровня абстракции известен как DFD уровня 0, который изображает всю информационную систему в виде одной диаграммы, скрывающей все базовые детали. DFD уровня 0 также известны как DFD контекста уровня.



• Уровень 1 – DFD уровня 0 подразделяется на более конкретный DFD уровня 1. Уровень 1 DFD отображает основные модули в системе и поток данных между различными модулями. Уровень 1 DFD также упоминает основные процессы и источники информации.



• Уровень 2 – На этом уровне DFD показывает, как данные передаются внутри модулей, упомянутых на уровне 1.

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

Уровень 2 – На этом уровне DFD показывает, как данные передаются внутри модулей, упомянутых на уровне 1.

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

Структурные диаграммы

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

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

Вот символы, используемые при построении структурных схем –

Диаграмма HIPO

Диаграмма HIPO (иерархический ввод-вывод) представляет собой комбинацию двух организованных методов для анализа системы и предоставления средств документирования. Модель HIPO была разработана IBM в 1970 году.

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

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

В отличие от диаграммы IPO (Input Process Output), которая отображает поток управления и данные в модуле, HIPO не предоставляет никакой информации о потоке данных или потоке управления.

пример

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

Структурированный английский

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

Другие формы методов, которые используют графики или диаграммы, могут иногда по-разному интерпретироваться разными людьми.

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

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

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

IF-THEN-ELSE,  
DO-WHILE-UNTIL

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

пример

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

Enter Customer_Name
SEEK Customer_Name in Customer_Name_DB file
IF Customer_Name found THEN
   Call procedure USER_PASSWORD_AUTHENTICATE()
ELSE
   PRINT error message
   Call procedure NEW_CUSTOMER_REQUEST()
ENDIF

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

Псевдо-код

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

Псевдокод избегает объявления переменных, но они написаны с использованием некоторых реальных конструкций языка программирования, таких как C, Fortran, Pascal и т. Д.

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

пример

Программа для печати Фибоначчи до n чисел.

void function Fibonacci
Get value of n;
Set value of a to 1;
Set value of b to 1;
Initialize I to 0
for (i=0; i< n; i++)
{
   if a greater than b 
   {
      Increase b by a;
      Print b;
   } 
   else if b greater than a
   {
      increase a by b;
      print a;
   }
}

Таблицы решений

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

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

Создание таблицы решений

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

• Определите все возможные условия для решения
• Определить действия для всех выявленных условий
• Создать максимально возможные правила
• Определите действие для каждого правила

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

пример

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

Мы перечисляем все возможные проблемы в условиях столбца и предполагаемые действия в столбце Действия.

	Условия / Действия	правила
условия	Показывает Подключено	N	N	N	N	Y	Y	Y	Y
Пинг работает	N	N	Y	Y	N	N	Y	Y
Открывает сайт	Y	N	Y	N	Y	N	Y	N
действия	Проверьте сетевой кабель	Икс
Проверьте интернет-роутер	Икс				Икс	Икс	Икс
Перезапустите веб-браузер							Икс
Связаться с поставщиком услуг		Икс	Икс	Икс	Икс	Икс	Икс
Не делать никаких действий

Таблица: Таблица решений – внутреннее устранение неисправностей в Интернете

Модель сущности-отношения

Модель Entity-Relationship – это тип модели базы данных, основанный на понятии сущностей реального мира и взаимосвязи между ними. Мы можем отобразить сценарий реального мира на модель базы данных ER. Модель ER создает набор объектов с их атрибутами, набором ограничений и связей между ними.

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

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

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

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

  Картирование кардинальности:

  • один к одному
  • один ко многим
  • много к одному
  • много ко многим

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

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

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

Картирование кардинальности:

Словарь данных

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

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

Требование к словарю данных

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

Словарь данных предоставляет способ документирования для всей системы баз данных в одном месте. Валидация DFD проводится с использованием словаря данных.

содержание

Словарь данных должен содержать информацию о следующем

• Поток данных
• Структура данных
• Элементы данных
• Хранилища данных
• Обработка данных

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

знак равно	Состоит из
{}	Репетиция
()	Необязательный
+	А также
[/]	Или же

пример

Адрес = дом № + (улица / район) + город + штат

Идентификатор курса = номер курса + название курса + уровень курса + оценки курса

Элементы данных

Элементы данных состоят из имени и описания элементов данных и элементов управления, внутренних или внешних хранилищ данных и т. Д. Со следующими подробностями:

• Основное имя
• Вторичное имя (псевдоним)
• Вариант использования (как и где использовать)
• Описание содержимого (нотация и т. Д.)
• Дополнительная информация (предустановленные значения, ограничения и т. Д.)

Хранилище данных

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

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

Обработка данных

Существует два типа обработки данных:

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

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

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

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

Структурированный дизайн

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

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

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

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

Сплоченность – группировка всех функционально связанных элементов.

Сцепление – связь между различными модулями.

Хорошая структурированная конструкция имеет высокую когезию и низкое сцепное устройство.

Функционально-ориентированный дизайн

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

Функционально ориентированный дизайн наследует некоторые свойства структурированного дизайна, где используется методология «разделяй и властвуй».

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

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

Процесс проектирования

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

Объектно-ориентированный дизайн

Объектно-ориентированный дизайн работает вокруг сущностей и их характеристик, а не функций, задействованных в программной системе. Эта стратегия проектирования ориентирована на сущности и ее характеристики. Вся концепция программного решения вращается вокруг заинтересованных лиц.

Давайте посмотрим на важные концепции объектно-ориентированного дизайна:

• Объекты – все объекты, участвующие в разработке решения, называются объектами. Например, человек, банки, компания и клиенты рассматриваются как объекты. У каждой сущности есть некоторые атрибуты, связанные с ней, и есть несколько методов для работы с атрибутами.

• Классы . Класс – это обобщенное описание объекта. Объект является экземпляром класса. Класс определяет все атрибуты, которые может иметь объект, и методы, которые определяют функциональные возможности объекта.

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

• Инкапсуляция. В OOD атрибуты (переменные данных) и методы (операции с данными) объединяются вместе и называются инкапсуляцией. Инкапсуляция не только объединяет важную информацию об объекте, но также ограничивает доступ к данным и методам из внешнего мира. Это называется сокрытием информации.
• Наследование – OOD позволяет подобным классам складываться иерархически, где нижние или подклассы могут импортировать, реализовывать и повторно использовать разрешенные переменные и методы из своих непосредственных суперклассов. Это свойство OOD известно как наследование. Это облегчает определение определенного класса и создание обобщенных классов из определенных.
• Полиморфизм – языки OOD предоставляют механизм, где методам, выполняющим аналогичные задачи, но различающимся по аргументам, можно присвоить одно и то же имя. Это называется полиморфизмом, который позволяет одному интерфейсу выполнять задачи для разных типов. В зависимости от того, как вызывается функция, выполняется соответствующая часть кода.

Классы . Класс – это обобщенное описание объекта. Объект является экземпляром класса. Класс определяет все атрибуты, которые может иметь объект, и методы, которые определяют функциональные возможности объекта.

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

Процесс проектирования

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

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

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

Вот два общих подхода к разработке программного обеспечения:

Дизайн сверху вниз

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

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

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

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

Дизайн снизу вверх

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

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

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

Разработка интерфейса пользователя программного обеспечения

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

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

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

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

• привлекательный
• Прост в использовании
• Отзывчивый в короткие сроки
• Ясно, чтобы понять
• Последовательный на всех интерфейсных экранах

Пользовательский интерфейс широко разделен на две категории:

• Интерфейс командной строки
• Графический пользовательский интерфейс

Интерфейс командной строки (CLI)

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

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

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

CLI использует меньше ресурсов компьютера по сравнению с GUI.

Элементы CLI

Текстовый интерфейс командной строки может иметь следующие элементы:

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

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

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

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

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

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

Графический пользовательский интерфейс

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

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

Элементы графического интерфейса

GUI предоставляет набор компонентов для взаимодействия с программным или аппаратным обеспечением.

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

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

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

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

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

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

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

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

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

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

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

Компоненты графического интерфейса приложения

GUI приложения содержит один или несколько из перечисленных элементов GUI:

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

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

  

• Text-Box – предоставляет пользователю область для ввода и ввода текстовых данных.

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

  

• Радио-кнопка – отображает доступные опции для выбора. Только один может быть выбран среди всех предложенных.

• Флажок – функции, аналогичные списку. Когда опция выбрана, поле помечается как отмеченное. Можно выбрать несколько параметров, представленных флажками.

• Список – Предоставляет список доступных элементов для выбора. Можно выбрать более одного элемента.

  

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

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

Text-Box – предоставляет пользователю область для ввода и ввода текстовых данных.

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

Радио-кнопка – отображает доступные опции для выбора. Только один может быть выбран среди всех предложенных.

Флажок – функции, аналогичные списку. Когда опция выбрана, поле помечается как отмеченное. Можно выбрать несколько параметров, представленных флажками.

Список – Предоставляет список доступных элементов для выбора. Можно выбрать более одного элемента.

Другие впечатляющие компоненты GUI:

• Слайдеры
• Поле со списком
• Данные сетки
• Выпадающий список

Деятельность по разработке пользовательского интерфейса

Существует ряд действий, выполняемых для разработки пользовательского интерфейса. Процесс проектирования и реализации GUI похож на SDLC. Любая модель может быть использована для реализации GUI среди Waterfall, Iterative или Spiral Model.

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

• Сбор требований к графическому интерфейсу – разработчикам может потребоваться список всех функциональных и нефункциональных требований графического интерфейса. Это может быть взято от пользователя и его существующего программного решения.

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

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

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

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

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

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

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

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

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

Инструменты реализации GUI

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

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

Существуют разные сегменты инструментов с графическим интерфейсом в зависимости от их использования и платформы.

пример

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

• ЖИДКОСТИ
• AppInventor (Android)
• Lucidchart
• Wavemaker
• Visual Studio

Пользовательский интерфейс Золотые правила

Следующие правила упоминаются как золотые правила для дизайна GUI, описанные Shneiderman и Plaisant в их книге (Проектирование интерфейса пользователя).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Меры сложности Холстеда

В 1977 году г-н Морис Говард Холстед представил метрики для измерения сложности программного обеспечения. Метрики Холстеда зависят от фактической реализации программы и ее мер, которые вычисляются непосредственно из операторов и операндов из исходного кода статическим образом. Это позволяет оценить время тестирования, словарный запас, размер, сложность, ошибки и усилия для исходного кода C / C ++ / Java.

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

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

параметр	Имея в виду
n1	Количество уникальных операторов
n2	Количество уникальных операндов
N1	Количество общего появления операторов
N2	Количество общего появления операндов

Когда мы выбираем исходный файл для просмотра деталей его сложности в Metric Viewer, в Metric Report появляется следующий результат:

метрический	Имея в виду	Математическое представление
N	Запас слов	n1 + n2
N	Размер	N1 + N2
В	объем	Длина * Log2 Словарь
D	трудность	(n1 / 2) * (N1 / n2)
Е	усилия	Сложность * Объем
В	ошибки	Объем / 3000
T	Время тестирования	Время = усилия / S, где S = 18 секунд.

Цикломатические меры сложности

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

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

Маккейб в 1976 году предложил Cyclomatic Complexity Measure, чтобы количественно оценить сложность данного программного обеспечения. Это модель, основанная на графике, которая основана на принимающих решения конструкциях программы, таких как if-else, do-while, repeat-till, switch-case и goto.

Процесс создания графика управления потоком:

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

• Если управление может перейти от блока i к блоку j

  Нарисуй дугу

• От узла выхода к узлу входа

  Нарисуй дугу.

Если управление может перейти от блока i к блоку j

Нарисуй дугу

От узла выхода к узлу входа

Нарисуй дугу.

Для расчета цикломатической сложности программного модуля мы используем формулу –

V(G) = e – n + 2

Where
e is total number of edges
n is total number of nodes

Цикломатическая сложность вышеуказанного модуля

e = 10
n = 8
Cyclomatic Complexity = 10 - 8 + 2
                      = 4

По мнению П. Йоргенсена, цикломатическая сложность модуля не должна превышать 10.

Функциональная точка

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

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

Давайте посмотрим параметры функции точки:

Внешний вход

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

• Просто – если количество входных данных мало и влияет на меньшее количество внутренних файлов

• Сложный – если количество входных данных велико и влияет на большее количество внутренних файлов

• Средний – между простым и сложным.

Просто – если количество входных данных мало и влияет на меньшее количество внутренних файлов

Сложный – если количество входных данных велико и влияет на большее количество внутренних файлов

Средний – между простым и сложным.

Внешний выход

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

• Простой – если количество выводов мало

• Сложный – если количество выводов велико

• Средний – между простым и сложным.

Простой – если количество выводов мало

Сложный – если количество выводов велико

Средний – между простым и сложным.

Внутренние логические файлы

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

• Просто – если количество типов записей мало

• Сложный – если количество типов записей велико

• Средний – между простым и сложным.

Просто – если количество типов записей мало

Сложный – если количество типов записей велико

Средний – между простым и сложным.

Файлы внешнего интерфейса

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

• Просто – если количество типов записей в общем файле мало

• Сложный – если количество типов записей в общем файле велико

• Средний – между простым и сложным.

Просто – если количество типов записей в общем файле мало

Сложный – если количество типов записей в общем файле велико

Средний – между простым и сложным.

Внешний запрос

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

• Просто – если запрос требует низкой обработки и выдает небольшое количество выходных данных

• Сложный – если запрос требует высокой обработки и выдает большое количество выходных данных

• Средний – между простым и сложным.

Просто – если запрос требует низкой обработки и выдает небольшое количество выходных данных

Сложный – если запрос требует высокой обработки и выдает большое количество выходных данных

Средний – между простым и сложным.

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

параметр	просто	Средний	Сложный
входные	3	4	6
Выходы	4	5	7
запрос	3	4	6
файлы	7	10	15
Интерфейсы	5	7	10

Таблица выше дает необработанные функциональные очки. Эти функциональные точки настраиваются в зависимости от сложности среды. Система описана с использованием четырнадцати различных характеристик:

• Передача данных
• Распределенная обработка
• Цели производительности
• Загрузка рабочей конфигурации
• Коэффициент транзакций
• Ввод данных онлайн,
• Эффективность конечного пользователя
• Онлайн обновление
• Сложная логика обработки
• Повторное удобство
• Простота установки
• Операционная простота
• Несколько сайтов
• Желание облегчить изменения

Эти характеристики факторов затем оцениваются от 0 до 5, как указано ниже:

• Нет влияния
• случайный
• умеренный
• Средний
• Значительное
• существенный

Все рейтинги затем суммируются как N. Значение N варьируется от 0 до 70 (14 типов характеристик x 5 типов оценок). Он используется для расчета коэффициентов корректировки сложности (CAF), используя следующие формулы:

 CAF = 0,65 + 0,01N

Затем,

 Поставленные функциональные точки (FP) = CAF x Raw FP

Эта FP может затем использоваться в различных метриках, таких как:

Стоимость = $ / FP

Качество = Ошибки / FP

Производительность = FP / человеко-месяц

Стоимость = $ / FP

Качество = Ошибки / FP

Производительность = FP / человеко-месяц

Программная реализация

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

Структурированное программирование

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

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

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

• Модульное программирование – при программировании код разбивается на меньшую группу инструкций. Эти группы известны как модули, подпрограммы или подпрограммы. Модульное программирование, основанное на понимании нисходящего анализа. Он препятствует переходам, используя в программе операторы ‘goto’, что часто делает поток программы не отслеживаемым. Переходы запрещены и модульный формат приветствуется в структурированном программировании.

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

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

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

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

Функциональное программирование

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

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

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

Функциональное программирование использует следующие понятия:

• Функции первого класса и высшего порядка. Эти функции могут принимать другую функцию в качестве аргумента или возвращать другие функции в качестве результата.

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

• Рекурсия – рекурсия – это метод программирования, при котором функция вызывает себя и повторяет в ней программный код, если не совпадает какое-то предварительно определенное условие. Рекурсия – это способ создания циклов в функциональном программировании.

• Строгая оценка – это метод оценки выражения, переданного функции в качестве аргумента. Функциональное программирование имеет два типа методов оценки: строгий (нетерпеливый) или нестрогий (ленивый). Строгая оценка всегда вычисляет выражение перед вызовом функции. Нестрогая оценка не оценивает выражение, если оно не требуется.

• λ-исчисление – большинство функциональных языков программирования используют λ-исчисление в качестве систем типов. λ-выражения выполняются путем их оценки по мере их появления.

Функции первого класса и высшего порядка. Эти функции могут принимать другую функцию в качестве аргумента или возвращать другие функции в качестве результата.

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

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

Строгая оценка – это метод оценки выражения, переданного функции в качестве аргумента. Функциональное программирование имеет два типа методов оценки: строгий (нетерпеливый) или нестрогий (ленивый). Строгая оценка всегда вычисляет выражение перед вызовом функции. Нестрогая оценка не оценивает выражение, если оно не требуется.

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

Common Lisp, Scala, Haskell, Erlang и F # являются примерами функциональных языков программирования.

Стиль программирования

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

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

Руководство по кодированию

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

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

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

• Отступ – это пробел, оставленный в начале строки, обычно 2-8 пробелов или одна вкладка.

• Пробелы – обычно не указываются в конце строки.

• Операторы – Определяет правила написания математических, присваивающих и логических операторов. Например, оператор присваивания ‘=’ должен иметь пробел до и после него, как в «x = 2».

• Управляющие структуры – правила написания if-then-else, case-switch, while-before и для операторов потока управления исключительно и во вложенном виде.

• Длина строки и перенос – определяет, сколько символов должно быть в одной строке, в основном длина строки составляет 80 символов. Обтекание определяет способ переноса строки, если она слишком длинная.

• Функции – это определяет, как функции должны быть объявлены и вызваны, с параметрами и без параметров.

• Переменные. Здесь указывается, как переменные различных типов данных объявляются и определяются.

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

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

Отступ – это пробел, оставленный в начале строки, обычно 2-8 пробелов или одна вкладка.

Пробелы – обычно не указываются в конце строки.

Операторы – Определяет правила написания математических, присваивающих и логических операторов. Например, оператор присваивания ‘=’ должен иметь пробел до и после него, как в «x = 2».

Управляющие структуры – правила написания if-then-else, case-switch, while-before и для операторов потока управления исключительно и во вложенном виде.

Длина строки и перенос – определяет, сколько символов должно быть в одной строке, в основном длина строки составляет 80 символов. Обтекание определяет способ переноса строки, если она слишком длинная.

Функции – это определяет, как функции должны быть объявлены и вызваны, с параметрами и без параметров.

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

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

Документация по программному обеспечению

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

Ухоженная документация должна включать следующие документы:

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

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

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

• Документация по разработке программного обеспечения – эта документация содержит всю необходимую информацию, необходимую для создания программного обеспечения. Он содержит: (a) архитектуру программного обеспечения высокого уровня, (b) детали разработки программного обеспечения, (c) диаграммы потоков данных, (d) проектирование базы данных

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

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

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

  Доступны различные автоматизированные инструменты, а некоторые поставляются с самим языком программирования. Например, Java поставляется с инструментом JavaDoc для создания технической документации кода.

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

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

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

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

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

Документация по разработке программного обеспечения – эта документация содержит всю необходимую информацию, необходимую для создания программного обеспечения. Он содержит: (a) архитектуру программного обеспечения высокого уровня, (b) детали разработки программного обеспечения, (c) диаграммы потоков данных, (d) проектирование базы данных

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

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

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

Доступны различные автоматизированные инструменты, а некоторые поставляются с самим языком программирования. Например, Java поставляется с инструментом JavaDoc для создания технической документации кода.

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

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

Проблемы реализации программного обеспечения

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

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

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

• Target-Host – Программное обеспечение, которое разрабатывается в организации, должно быть разработано для хост-компьютеров на стороне клиента. Но иногда невозможно разработать программное обеспечение, которое работает на целевых машинах.

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

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

Target-Host – Программное обеспечение, которое разрабатывается в организации, должно быть разработано для хост-компьютеров на стороне клиента. Но иногда невозможно разработать программное обеспечение, которое работает на целевых машинах.

Обзор тестирования программного обеспечения

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

Проверка программного обеспечения

Валидация – это процесс проверки соответствия программного обеспечения требованиям пользователя. Это выполняется в конце SDLC. Если программное обеспечение соответствует требованиям, для которых оно было сделано, оно проверяется.

• Валидация гарантирует, что разрабатываемый продукт соответствует требованиям пользователя.
• Валидация отвечает на вопрос – «Разрабатываем ли мы продукт, который использует все программное обеспечение, необходимое для этого пользователя?».
• Валидация делает упор на требования пользователя.

Проверка программного обеспечения

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

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

Целью теста являются –

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

• Неисправность – при наличии ошибки возникает неисправность. Ошибка, также известная как ошибка, является результатом ошибки, которая может привести к сбою системы.

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

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

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

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

Ручное и автоматическое тестирование

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

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

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

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

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

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

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

Тест должен проверить, можно ли открыть веб-страницу в Internet Explorer. Это легко сделать с помощью ручного тестирования. Но проверить, может ли веб-сервер выдержать нагрузку в 1 миллион пользователей, проверить вручную невозможно.

Существуют программные и аппаратные средства, которые помогают тестировщику проводить нагрузочное тестирование, стресс-тестирование, регрессионное тестирование.

Подходы к тестированию

Тесты могут проводиться на основе двух подходов –

• Функциональное тестирование
• Тестирование реализации

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

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

Тестирование черного ящика

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

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

Методы тестирования черного ящика:

• Класс эквивалентности – вход делится на аналогичные классы. Если один элемент класса проходит тест, предполагается, что весь класс пройден.

• Граничные значения – вход делится на верхний и нижний конечные значения. Если эти значения проходят тест, предполагается, что все значения между ними также могут пройти.

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

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

• Основанное на состоянии тестирование – система изменяет состояние при предоставлении ввода. Эти системы тестируются на основе их состояний и входных данных.

Класс эквивалентности – вход делится на аналогичные классы. Если один элемент класса проходит тест, предполагается, что весь класс пройден.

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

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

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

Основанное на состоянии тестирование – система изменяет состояние при предоставлении ввода. Эти системы тестируются на основе их состояний и входных данных.

Тестирование белого ящика

Он проводится для тестирования программы и ее реализации с целью повышения эффективности или структуры кода. Это также известно как «Структурное» тестирование.

В этом методе тестирования дизайн и структура кода известны тестировщику. Программисты кода проводят этот тест на коде.

Ниже приведены некоторые методы тестирования Белого ящика:

• Тестирование потока управления . Цель тестирования потока управления для настройки тестовых случаев, охватывающих все операторы и условия ветвления. Условия ветвления проверяются как на истинность, так и на ложность, чтобы можно было охватить все операторы.

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

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

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

Уровни тестирования

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

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

Модульное тестирование

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

Интеграционное тестирование

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

Тестирование системы

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

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

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

• Безопасность и переносимость – эти тесты проводятся, когда программное обеспечение предназначено для работы на различных платформах и доступно для нескольких человек.

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

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

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

Приемочное тестирование

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

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

• Бета-тестирование – после внутреннего тестирования программного обеспечения оно передается пользователям для использования в производственной среде только для целей тестирования. Это еще не доставленный продукт. Разработчики ожидают, что пользователи на этом этапе принесут мелкие проблемы, которые были пропущены для участия.

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

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

Регрессионное тестирование

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

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

Тестовые документы готовятся на разных этапах –

Перед тестированием

Тестирование начинается с генерации тестовых случаев. Следующие документы необходимы для справки –

• Документ СГД – Документ о функциональных требованиях

• Документ о политике тестирования – описывает, как далеко должно пройти тестирование перед выпуском продукта.

• Документ по стратегии тестирования. Здесь подробно описываются аспекты команды тестирования, матрица ответственности и права / ответственность менеджера по тестированию и инженера по тестированию.

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

Документ СГД – Документ о функциональных требованиях

Документ о политике тестирования – описывает, как далеко должно пройти тестирование перед выпуском продукта.

Документ по стратегии тестирования. Здесь подробно описываются аспекты команды тестирования, матрица ответственности и права / ответственность менеджера по тестированию и инженера по тестированию.

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

Во время тестирования

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

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

• Описание теста – Этот документ представляет собой подробное описание всех тестовых случаев и процедур для их выполнения.

• Отчет о тестовом наборе – этот документ содержит отчет о тестовом наборе в результате теста.

• Журналы тестов – этот документ содержит журналы тестов для каждого отчета о тестовом примере.

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

Описание теста – Этот документ представляет собой подробное описание всех тестовых случаев и процедур для их выполнения.

Отчет о тестовом наборе – этот документ содержит отчет о тестовом наборе в результате теста.

Журналы тестов – этот документ содержит журналы тестов для каждого отчета о тестовом примере.

После тестирования

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

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

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

Тестирование и контроль качества, обеспечение качества и аудит

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

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

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

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

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

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

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

Обзор обслуживания программного обеспечения

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

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

• Требования к клиенту. Со временем клиент может запросить новые функции или функции в программном обеспечении.

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

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

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

Требования к клиенту. Со временем клиент может запросить новые функции или функции в программном обеспечении.

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

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

Типы обслуживания

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

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

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

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

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

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

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

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

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

Стоимость обслуживания

Отчеты показывают, что стоимость обслуживания высока. Исследование по оценке обслуживания программного обеспечения показало, что стоимость обслуживания составляет 67% от стоимости всего цикла обработки программного обеспечения.

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

Фактические факторы, влияющие на стоимость обслуживания

• Стандартный возраст любого программного обеспечения считается от 10 до 15 лет.
• Старые программные продукты, которые должны были работать на медленных компьютерах с меньшим объемом памяти и емкостью хранения, не могут противостоять новым улучшенным программным средствам на современном оборудовании.
• По мере развития технологий обслуживание старого программного обеспечения становится дорогостоящим.
• Большинство инженеров по техническому обслуживанию являются новичками и используют метод проб и ошибок, чтобы исправить проблему.
• Часто внесенные изменения могут легко повредить исходную структуру программного обеспечения, затрудняя любые последующие изменения.
• Изменения часто остаются недокументированными, что может вызвать больше конфликтов в будущем.

Конечные факторы, влияющие на стоимость обслуживания

• Структура программного обеспечения
• Язык программирования
• Зависимость от внешней среды
• Надежность и доступность персонала

Деятельность по обслуживанию

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

Эти действия идут рука об руку с каждым из следующих этапов:

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

• Анализ – Модификация анализируется на предмет ее воздействия на систему, включая последствия для безопасности. Если вероятное воздействие серьезное, ищется альтернативное решение. Набор необходимых модификаций затем материализуется в спецификации требований. Стоимость модификации / обслуживания анализируется и оценка завершается.

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

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

• Системное тестирование – Интеграционное тестирование проводится среди вновь созданных модулей. Интеграционное тестирование также проводится между новыми модулями и системой. Наконец, система тестируется в целом, следуя процедурам регрессивного тестирования.

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

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

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

• Управление техническим обслуживанием. Управление конфигурацией является неотъемлемой частью технического обслуживания системы. Это помогает инструментам контроля версий управлять версиями, полу-версиями или исправлениями.

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

Анализ – Модификация анализируется на предмет ее воздействия на систему, включая последствия для безопасности. Если вероятное воздействие серьезное, ищется альтернативное решение. Набор необходимых модификаций затем материализуется в спецификации требований. Стоимость модификации / обслуживания анализируется и оценка завершается.

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

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

Системное тестирование – Интеграционное тестирование проводится среди вновь созданных модулей. Интеграционное тестирование также проводится между новыми модулями и системой. Наконец, система тестируется в целом, следуя процедурам регрессивного тестирования.

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

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

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

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

Реинжиниринг программного обеспечения

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

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

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

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

Процесс реинжиниринга

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

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

Обратный инжиниринг

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

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

Реструктуризация программы

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

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

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

Форвард Инжиниринг

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

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

Повторное использование компонентов

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

пример

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

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

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

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

Существует совершенно новая вертикаль, которая основана на повторном использовании программного компонента и известна как компонентная разработка программного обеспечения (CBSE).

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

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

• Уровень компонента – где используется подсистема приложения.

• Уровень модулей – где функциональные модули используются повторно.

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

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

Уровень компонента – где используется подсистема приложения.

Уровень модулей – где функциональные модули используются повторно.

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

Процесс повторного использования

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

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

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

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

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

• Включите компоненты – Все соответствующие компоненты упакованы вместе, чтобы сформировать их как законченное программное обеспечение.

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

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

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

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

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

Обзор программных инструментов

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

CASE Инструменты

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

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

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

Компоненты CASE Tools

Инструменты CASE можно широко разделить на следующие части в зависимости от их использования на определенной стадии SDLC:

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

  

• Инструменты верхнего регистра. Инструменты верхнего регистра используются на этапах планирования, анализа и проектирования SDLC.

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

• Интегрированные инструменты Case – Интегрированные инструменты CASE полезны на всех этапах SDLC, от сбора требований до тестирования и документации.

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

Инструменты верхнего регистра. Инструменты верхнего регистра используются на этапах планирования, анализа и проектирования SDLC.

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

Интегрированные инструменты Case – Интегрированные инструменты CASE полезны на всех этапах SDLC, от сбора требований до тестирования и документации.

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

Область применения инструментов Case

Сфера применения инструментов CASE распространяется на весь SDLC.

Типы инструментов

Теперь мы кратко рассмотрим различные инструменты CASE

Инструменты диаграммы

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

Инструменты моделирования процессов

Моделирование процесса – это метод для создания модели процесса программного обеспечения, которая используется для разработки программного обеспечения. Инструменты моделирования процессов помогают менеджерам выбрать модель процесса или изменить ее в соответствии с требованиями программного продукта. Например, EPF Composer

Инструменты управления проектами

Эти инструменты используются для планирования проекта, оценки затрат и усилий, планирования проекта и планирования ресурсов. Менеджеры должны строго соблюдать выполнение проекта с каждым упомянутым этапом в управлении программным проектом. Инструменты управления проектами помогают хранить и обмениваться информацией о проектах в реальном времени по всей организации. Например, Creative Pro Office, Trac Project, Basecamp.

Инструменты документации

Документация в программном проекте начинается до процесса разработки программного обеспечения, проходит через все фазы SDLC и после завершения проекта.

Инструменты документирования генерируют документы для технических пользователей и конечных пользователей. Технические пользователи – это, в основном, собственные специалисты команды разработчиков, которые ссылаются на системное руководство, справочное руководство, учебное руководство, руководства по установке и т. Д. Документы конечного пользователя описывают функционирование и инструкции системы, такие как руководство пользователя. Например, Doxygen, DrExplain, Adobe RoboHelp для документации.

Инструменты анализа

Эти инструменты помогают собирать требования, автоматически проверять любые несоответствия, неточности в схемах, избыточность данных или ошибочные пропуски. Например, Accept 360, Accommodationpa, CaseComplete для анализа потребностей, Visible Analyst для общего анализа.

Инструменты дизайна

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

Инструменты управления конфигурацией

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

• Управление версиями и ревизиями
• Управление базовой конфигурацией
• Управление изменениями

Инструменты CASE помогают в этом благодаря автоматическому отслеживанию, управлению версиями и управлению выпусками. Например, Fossil, Git, Accu REV.

Инструменты управления изменениями

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

Инструменты программирования

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

Инструменты для прототипирования

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

Инструменты для создания прототипов CASE в основном поставляются с графическими библиотеками. Они могут создавать аппаратно-независимые пользовательские интерфейсы и дизайн. Эти инструменты помогают нам создавать быстрые прототипы на основе существующей информации. Кроме того, они обеспечивают симуляцию программного прототипа. Например, композитор-прототип Серены, конструктор макетов.

Инструменты веб-разработки

Эти инструменты помогают в разработке веб-страниц со всеми смежными элементами, такими как формы, текст, сценарий, графика и так далее. Веб-инструменты также предоставляют предварительный просмотр того, что разрабатывается и как оно будет выглядеть после завершения. Например, Fontello, Adobe Edge Inspect, Foundation 3, Brackets.

Инструменты обеспечения качества

Обеспечение качества в организации программного обеспечения – это мониторинг процесса разработки и методов, принятых для разработки программного продукта, с целью обеспечения соответствия качества в соответствии со стандартами организации. Инструменты QA состоят из инструментов контроля конфигурации и изменений и инструментов тестирования программного обеспечения. Например, SoapTest, AppsWatch, JMeter.

Инструменты обслуживания

Обслуживание программного обеспечения включает в себя модификации программного продукта после его доставки. Методы автоматической регистрации и сообщения об ошибках, автоматическая генерация квитанции об ошибках и анализ первопричин – это лишь немногие инструменты CASE, которые помогают в организации программного обеспечения на этапе обслуживания SDLC. Например, Bugzilla для отслеживания дефектов, HP Quality Center.

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

Джун на аутсорсе

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

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

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

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

Скорее всего ваше первое ревью будет долгим, т.к вам потребуется не только исправить не только архитектурные и логические ошибки в вашем коде, но также и соблюсти code style (свод правил написания кода, специфичный для конкретной компании). Здесь самое главное чтобы ваш ревьювер не сильно увлёкся. У ревью можно выделить 2 главных назначения:

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

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

При этом очень важно сильно НЕ ударяться в перфекционизм. НЕ нужно по несколько дней вылизывать ваш код. Здесь нужно помнить о правиле “Лучшее враг хорошего”.

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

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

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

Про автоматические тесты

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

Автоматические тесты – это в первую очередь защита от регрессии (поломки вашего кода) в будущем, т.к в момент написание тестов они точно будут работать (а тесты имеют смысл, только когда они перестают это делать).

Разработка, ревью, тестирование

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

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

От разработчика к менеджеру

Как правило, начинающие и разработчики среднего уровня не взаимодействуют напрямую с заказчиком, (но могут с командой разработки со стороны заказчика). Менеджерские функции выполняют Team-лиды, Product и Project менеджеры. Давайте рассмотрим чем отличаются эти 3 категории и чем они занимаются.

Team Lead, Product и Project менеджер

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

Отличие этих руководящих должностей в том, кто находится у них в подчинении. Схема следующая:

Product Manager -> Project manager -> Team Lead -> Разработчик

Естественно нужно понимать, что чем более “менеджерская” твоя должность тем более высокоуровневые задачи ты ставишь перед своими подчиненными.

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

Какие задачи решают менеджеры

В качестве примера рассмотрим Team-лида, т.к почти каждая IT компания имеет в своем арсенале таких людей. Product и Project менеджеры все таки более редкие персонажи.

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

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

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

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

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

Также в рамках оценки проекта составляется команда, которая будет его реализовывать. При чем необязательно определится с конкретными людьми. Нужно лишь составить список из ролей. К примеру, 2 мидл разработчика, 1 старший, Тестировщик, Дизайнер и Team Lead. Естественно обговаривается сколько рабочих часов будет тратить каждый из специалистов и сколько стоит этот час. К примеру дизайнеры и тестировщики могут одновременно работать над несколькими проектами, а значит их вклад в текущий может быть только частичным (4 часа в день вместо 8).

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

В ходе распределения задач оценивается сложность каждой задачи, после чего эта задача попадает в Backlog (это список всех задач текущего проекта). Нужен он потому что нельзя сразу распределить задачи по разработчикам. Как правило, все IT компании работают по методологии Scrum или Agile.

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

В случае с Agile, нет дробления на спринты. Разработчики берут задачи по мере выполнения. При этом нужно сказать, что почти во всех командах, есть некоторые промежуточные этапы в ходе которых анализируется сколько уже было сделано и сколько осталось.

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

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

А что же в Продуктовых компаниях

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

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

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

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

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

Взгляд с позиции заказчика

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

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

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

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

Второй этап – это правильно объяснить что вы хотите. Здесь самое важное изначально учесть максимально все детали, которые вам будут необходимы в будущем приложении. Любое дополнение, которое вы захотите сделать в середине разработки будет в среднем сложнее(дольше) реализовать, чем если об этом требовании было бы известно заранее.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• программа работает,
  но не выдает всех запланированных
  результатов и не выходит на останов
  (происходит ее «зацикливание»);

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

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

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

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

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

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

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

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

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

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

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

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

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

Метод нисходящего
проектирования
(метод пошаговой детализации, метод
иерархического проектирования,
top-down-подход) .

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

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

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

Модульное
проектирование

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

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

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

• по завершении
  работы модуль должен возвращать
  управление тому модулю, который его
  вызывал;

• модуль должен
  иметь один вход и выход;

• модуль должен
  иметь небольшой размер, обеспечивающий
  его обозримость.

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

Модульный принцип
разработки программ обладает следующими
преимуществами:

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

• появляется
  возможность создавать и многократно
  использовать в дальнейшем библиотеки
  наиболее употребимых программ;

• упрощается
  процедура загрузки больших программ
  в оперативную память, когда требуется
  ее сегментация;

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

• обеспечивается
  более эффективное тестирование программ,
  проще осуществляются проектирование
  и последующая отладка.

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

Структурное
программирование

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

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

CASE-технологии

За последнее
десятилетие в области средств автоматизации
программирования сформировалось новое
направление под общим названием
CASE-технологии (Computer Aided Software Engineering).

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

Технологии RAD

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

Это дало пользователю
возможность, получая уже с первых шагов
конкретное представление о характере
реализации задачи, уточнять ее постановку.
Тем самым облегчался процесс
экспериментального поиска нужного
решения автоматизации задачи. Благодаря
тесному взаимодействию разработчика
с заказчиком (пользователем) на самом
ответственном этапе создания прикладных
программ между ними достигалось быстрое
взаимопонимание цели поставленной
задачи и возможности ее автоматизации
в данных конкретных условиях. Это
повышало скорость разработки программ
и послужило основанием для названия
такой технологии RAD
(Rapid Application Development
— быстрая разработка программ), которая
получила широкое распространение.

Data Warehouse

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

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

• во-вторых, в том,
  что наряду с информацией, непосредственно
  отражающей состояние системы управления,
  в Data Warehouse аккумулируются и метаданные.

Метаданные
(данные о
данных) облегчают возможность визуального
представления содержимого Data Warehouse,
позволяют, «перемещаясь» по
хранилищу, быстро отбирать необходимые
данные для последующей обработки.

Основные типы
метаданных Data Warehouse отражают:

• структуру и
  содержимое хранилища;

• соответствие
  между исходными и выходными данными;

• объемные
  характеристики данных;

• критерии
  архивирования;

• отношения между
  данными;

• информацию по
  кодированию;

• интервал жизни
  данных и т.п.

Концепция Data
Warehouse
поддерживается RAD средствами разработки
прикладного ПО.

Концепция Data
Warehouse
обеспечивает возможность разработки
программных приложений для поддержки
процессов принятия решений с использованием
OLAP-систем.

Система OLAP
(On-Line Analytical
Process)
предоставляет возможность разработки
информационных систем, ориентированных
на yна
организацию многомерных баз данных и
создание корпоративных сетей, а также
обеспечивает поддержку Web-технологий
в сетях Internet/Intranet

Успешное применение
инструментальных средств OLAP-систем
объясняется быстротой разработки
приложений, гибкостью и широкими
возможностями в области доступа к данным
и их преобразования. В настоящее время
на рынке ПО предлагается большое число
OLAP-стем, разработчиками которых являются
различные фирмы, например IBM, Informix,
Microsoft, Oracle, Sybase и др.

Инструментарий
технологии программирования

Инструментарий
технологии программирования
— программные продукты поддержки
(обеспечения) технологии программирования.

В рамках этого
направления сформировались следующие
группы программных продуктов (рис. 2):

1. средства для
   создания приложений, включающие:

• локальные средства,
  обеспечивающие выполнение отдельных
  работ по созданию программ;

• интегрированные
  среды разработчиков программ,
  обеспечивающие выполнение комплекса
  взаимосвязанных работ по созданию
  программ;

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

Рис. 2 — Классификация
инструментария технологии программирования

Средства
для создания приложений

Локальные средства
разработки программ

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

Язык программирования
— формализованный
язык для описания алгоритма решения
задачи на компьютере.

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

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

• машинные языки
  (computer language) — языки программирования,
  воспринимаемые аппаратной частью
  компьютера (машинные коды);

• машинно-ориентированные
  языки (computer-oriented language) — языки
  программирования, которые отражают
  структуру конкретного типа компьютера
  (ассемблеры);

• алгоритмические
  языки (algorithmic language) — языки программирования,
  не зависящие от архитектуры компьютера
  (Паскаль, Си, Фортран, Бейсик и др.);

• процедурно-ориентированные
  языки (procedure-oriented
  language)
  — языки программирования, где имеется
  возможность написания программы как
  совокупности процедур (подпрограмм);

• проблемно-ориентированные
  языки (universal programming language)
  — языки программирования, предназначенные
  для решения задач определенного класса
  (Лисп, Пролог, Симула и др.);

• интегрированные
  системы программирования.

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

Программа,
подготовленная на языке программирования,
проходит этап трансляции, когда происходит
преобразование исходного кода программы
(source code) в объектный код (object code), который
далее пригоден к обработке редактором
связей. Редактор связей специальная
программа, обеспечивающая построение
загрузочного модуля (load module), пригодного
к выполнению (рис. 3).

Рис. 3 — Схема
процесса создания загрузочного модуля
программы

Трансляция может
выполняться с использованием средств
компиляторов (compiler) или интерпретаторов
(interpreter).
Компиляторы транслируют всю программу,
но без ее выполнения. Интерпретаторы,
в отличие от компиляторов, выполняют
пооператорную обработку и выполнение
программы.

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

Более мощным
средством разработки программ являются
системы
программирования.

Системы
программирования (programming system) включают:

• компилятор;

• интегрированную
  среду разработчика программ;

• отладчик;

• средства оптимизации
  кода программ;

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

• редактор связей;

• сервисные средства
  (утилиты) для работы с библиотеками
  текстовыми и двоичными файлами;

• справочные системы;

• документатор
  исходного кода программы;

• систему поддержки
  и управления проектом программного
  комплекса.

Средства поддержки
проектов — новый класс средств разработки
программного обеспечения, предназначенный
для:

• отслеживания
  изменений, выполненных разработчиками
  программ;

• поддержки версий
  программы с автоматической разноской
  изменений;

• получения статистики
  о ходе работ проекта.

Инструментальная
среда пользователя представлена

специальными
средствами, встроенными в пакеты
прикладных программ, такими, как:

• библиотека функций,
  процедур, объектов и методов обработки;

• макрокоманды;

• клавишные макросы;
  языковые макросы;

• программные
  модули-вставки; конструкторы экранных
  форм и отчетов;

• генераторы
  приложений; языки запросов высокого
  уровня;

• языки манипулирования
  данными; конструкторы меню и многое
  другое.

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

Интегрированные
среды разработки программ

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

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

CASE-технологии

CASE-технологии —
относительно новое направление,
формировавшееся на рубеже 80-х годов.

CASE-технологии
делятся на две группы:

• встроенные в
  систему реализации, в которых все
  решения по проектированию и реализации
  привязаны к выбранной системе явления
  базами данных (СУБД);

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

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

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

• диаграмм потоков
  данных (DFD — data flow diagrams) совместно со
  словарями данных и спецификациями
  процессов;

• диаграмм
  «сущность-связь» (ERD — entity relationship
  diagrams), являющихся информационной моделью
  предметной области;

• диаграмм переходов
  состояний (STD — state transition diagrams), учитывающих
  события и реакцию на них системы
  обработки данных.

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

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

Этими CASE-технологиями
выполняются автоматизированное
проектирование спецификаций программ
(задание основных характеристик для
разработки программ) и ведение словаря
данных.

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

• автоматическую
  генерацию кодов программ на основании
  их спецификаций;

• проверку корректности
  описания моделей данных и схем потоков
  данных;

• документирование
  программ согласно принятым стандартам
  и актуальному состоянию проекта;

• тестирование и
  отладку программ.

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

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

Языки
и системы программирования

Поколения языков
программирования

Языки программирования
принято делить на пять поколений.

В первое поколение
входят языки, созданные в начале 50-х
годов, когда только появились первые
компьютеры. Это был первый язык ассемблера,
созданный по принципу «одна инструкция
— одна строка».

Расцвет второго
поколения языков
программирования пришелся на конец
50-х — начало 60-х годов. Тогда был разработан
символический ассемблер, в котором
появилось понятие переменной. Он стал
первым полноценным языком программирования.
Благодаря его возникновению заметно
возросли скорость разработки и надежность
программ.

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

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

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

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

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

Обзор языков
программирования высокого уровня

Fortran (Фортран)

Это первый
компилируемый язык, созданный в 50-е
годы.

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

Cobol (Кобол).

Это компилируемый
язык для применения в экономической
области и решения бизнес — задач,
разработанный в начале 60-х годов. Он
отличается большой «многословностью»
– его операторы иногда выглядят как
обычные английские фразы. В Коболе были
реализованы очень мощные средства
работы с большими объемами данных,
хранящимися на различных внешних
носителях. На этом языке создано очень
много приложений, которые эксплуатируются
и сегодня.

Algol (Алгол).
Компилируемый язык, созданный в 1960г. Он
был призван заменить Фортран, но из-за
более сложной структуры не получил
широкого распространения. В 1968г. была
создана версия Алгол 68, по своим
возможностям и сегодня опережающая
многие языки программирования, однако
из-за отсутствия достаточно эффективных
компьютеров для нее не удалось своевременно
создать хорошие компиляторы.

Pascal (Паскаль)

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

Basic (Бейсик)

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

С (Си)

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

C++ (Си++)

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

Java (Ява)

Этот язык был
создан компанией Sun в начале 90-х годов
на основе Си++. Он призван упростить
разработку приложений на основе Си++
путем исключения из него всех низкоуровневых
возможностей. Но главная особенность
этого языка — компиляция не в машинный
код, а в платформно-независимый байт-код
(каждая команда занимает один байт).
Этот байт-код может выполняться с помощью
интерпретатора — виртуальной Java-машины
JVM (Java Virtual Machine), версии которой созданы
сегодня для любых платформ.

Особое внимание
в развитии этого языка уделяется двум
направлениям:

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

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

Пока недостаток
этого языка — невысокое быстродействие.

Языки программирования
баз данных

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

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

Для управления
большими базами данных и их эффективной
обработки разработаны СУБД (Системы
Управления Базами Данных).

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

Сегодня в мире
насчитывается пять ведущих производителей
СУБД:

Microsoft
(SQL Server), IBM (DB2), Oracle, Software AG (Adabas), Informix и
Sybase. Их
продукты нацелены на поддержку
одновременной работы тысяч пользователей
в сети, а базы данных могут храниться в
распределенном виде на нескольких
серверах.

С появлением
персональных компьютеров были созданы
так называемые настольные СУБД.
Родоначальником современных языков
программирования баз данных для ПК
принято считать СУБД dBase II, язык которой
был интерпретируемым. Затем для него
были созданы компиляторы, появились
СУБД FoxPro и Clipper, поддерживающие диалекты
этого языка. Сегодня похожие, но
несовместимые версии языков семейства
dBase реализованы в продуктах Visual FoxPro
фирмы Microsoft и Visual dBase фирмы Inprise.