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

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

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

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

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

Определения

IEEE определяет программную инженерию как:

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

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

Фриц Бауэр, немецкий ученый-компьютерщик, определяет программную инженерию как:

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

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

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

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

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

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

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

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

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

Lehman дал восемь законов эволюции программного обеспечения E-Type:

• Continuing change - Программная система E-типа должна продолжать адаптироваться к изменениям реального мира, иначе она становится все менее полезной.
• Increasing complexity - По мере развития программной системы E-типа ее сложность имеет тенденцию к увеличению, если не будет проведена работа по ее обслуживанию или уменьшению.
• Conservation of familiarity - Знакомство с программным обеспечением или знания о том, как оно было разработано, почему оно было разработано таким образом, и т. Д. Должны быть сохранены любой ценой для внесения изменений в систему.
• Continuing growth- Для того, чтобы система электронного типа была предназначена для решения некоторых бизнес-задач, ее размер внедрения изменений растет в соответствии с изменениями образа жизни в бизнесе.
• Reducing quality - Качество программной системы электронного типа снижается, если ее не поддерживать и не адаптировать к меняющейся операционной среде.
• Feedback systems- Программные системы E-типа представляют собой многоконтурные, многоуровневые системы обратной связи и должны рассматриваться как таковые для успешной модификации или улучшения.
• Self-regulation - Процессы развития систем E-типа являются саморегулирующимися с распределением продуктов и показателей процесса, близкими к нормальным.
• Organizational stability - Средний эффективный глобальный уровень активности в развивающейся системе E-типа неизменен в течение всего срока службы продукта.

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

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

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

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

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

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

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

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

• Design
• Maintenance
• Programming

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

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

• Coding
• Testing
• Integration

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

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

• Large software - Легче построить стену, чем дом или здание, поскольку размер программного обеспечения становится большим, инженеры должны сделать шаг, чтобы придать ему научный процесс.
• Scalability- Если бы процесс создания программного обеспечения не был основан на научных и инженерных концепциях, было бы легче воссоздать новое программное обеспечение, чем масштабировать существующее.
• Cost- Поскольку аппаратная промышленность показала свои навыки, и огромное производство снизило цены на компьютерное и электронное оборудование. Но стоимость программного обеспечения остается высокой, если не адаптировать соответствующий процесс.
• Dynamic Nature- Постоянно растущий и адаптирующийся характер программного обеспечения во многом зависит от среды, в которой работает пользователь. Если природа программного обеспечения постоянно меняется, необходимо внести новые улучшения в существующее. Именно здесь программная инженерия играет важную роль.
• Quality Management- Более совершенный процесс разработки программного обеспечения обеспечивает лучший и качественный программный продукт.

Характеристики хорошего ПО

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

• Operational
• Transitional
• Maintenance

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

Оперативный

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

• Budget
• Usability
• Efficiency
• Correctness
• Functionality
• Dependability
• Security
• Safety

Переходный

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

• Portability
• Interoperability
• Reusability
• Adaptability

Обслуживание

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

• Modularity
• Maintainability
• Flexibility
• Scalability

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

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

SDLC деятельности

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

Общение

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

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

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

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

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

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

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

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

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

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

Кодирование

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

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

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

Интеграция

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

Реализация

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

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

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

Диспозиция

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

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

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

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

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

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

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

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

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

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

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

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

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

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

V - модель

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Project Planning
• Scope Management
• Project Estimation

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

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

Управление содержанием

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

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

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

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

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

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

• Software size estimation

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

• Effort estimation

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

• Time estimation

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

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

• Cost estimation

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

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

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

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

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

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

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

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

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

Техника эмпирической оценки

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

• Putnam Model

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

• COCOMO

  COCOMO - это сокращение от COnstructive COst MOdel, разработанное Барри В. Боем. Он делит программный продукт на три категории программного обеспечения: обычное, полуотключенное и встроенное.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Эти меры включают:

• Activity Monitoring - Все действия, запланированные в рамках некоторой задачи, можно отслеживать на ежедневной основе. Когда все действия в задаче завершены, она считается завершенной.
• Status Reports - Отчеты содержат статус действий и задач, выполненных в течение заданного периода времени, обычно за неделю. Статус может быть отмечен как завершенный, ожидающий или незавершенный и т. Д.
• Milestones Checklist - Каждый проект разделен на несколько этапов, в которых выполняются основные задачи (этапы) на основе этапов SDLC. Этот контрольный список этапов составляется раз в несколько недель и сообщает о состоянии этапов.

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

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

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

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

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

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

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

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

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

Исходный уровень

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

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

Изменить управление

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

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

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

• Validation - Проверяется действительность запроса на изменение и подтверждается порядок его обработки.

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

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

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

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

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

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

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

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

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

Диаграмма PERT

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

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

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

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

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

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

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

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

Разработка требований

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Процесс предъявления требований

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

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

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

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

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

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

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

Есть разные способы узнать требования

Интервью

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

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

Обзоры

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

Анкеты

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

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

Анализ задачи

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

Анализ домена

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

Мозговой штурм

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

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

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

Наблюдение

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

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

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

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

• Clear
• Correct
• Consistent
• Coherent
• Comprehensible
• Modifiable
• Verifiable
• Prioritized
• Unambiguous
• Traceable
• Достоверный источник

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

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

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

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

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

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

Примеры -

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

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

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

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

• Security
• Logging
• Storage
• Configuration
• Performance
• Cost
• Interoperability
• Flexibility
• Аварийное восстановление
• Accessibility

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

• Must Have : Без них софт нельзя назвать работоспособным.
• Should have : Расширение функциональности программного обеспечения.
• Could have : Программное обеспечение по-прежнему может нормально работать с этими требованиями.
• Wish list : Эти требования не соответствуют каким-либо целям программного обеспечения.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Size Metrics - LOC (строки кода), в основном рассчитываемые в тысячах строк исходного кода, обозначаемые как KLOC.

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

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

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

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

• Process Metrics - На различных этапах SDLC используемые методы и инструменты, стандарты компании и производительность разработки являются метриками процесса программного обеспечения.
• Resource Metrics - Затраченные усилия, время и различные ресурсы представляют собой показатели для измерения ресурсов.

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

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

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

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

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

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

Модуляризация

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

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

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

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

Параллелизм

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

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

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

пример

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

Связь и сплоченность

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

Сплоченность

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

Есть семь типов сплоченности, а именно -

• Co-incidental cohesion -Это незапланированная и случайная сплоченность, которая может быть результатом разбивки программы на более мелкие модули ради модульности. Поскольку это не запланировано, это может сбить с толку программистов и обычно не принимается.
• Logical cohesion - Когда логически категоризированные элементы объединяются в модуль, это называется логической связностью.
• emporal Cohesion - Когда элементы модуля организованы так, что они обрабатываются в один и тот же момент времени, это называется временной связностью.
• Procedural cohesion - Когда элементы модуля сгруппированы вместе, которые выполняются последовательно для выполнения задачи, это называется процедурной связностью.
• Communicational cohesion - Когда элементы модуля сгруппированы вместе, которые выполняются последовательно и работают с одними и теми же данными (информацией), это называется коммуникационной связностью.
• Sequential cohesion - Когда элементы модуля группируются, потому что выход одного элемента служит входом для другого и так далее, это называется последовательной связью.
• Functional cohesion - Это считается высшей степенью сплоченности, и это очень ожидаемо. Элементы модуля в функциональной сплоченности сгруппированы, потому что все они вносят вклад в одну четко определенную функцию. Его также можно использовать повторно.

Связь

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

Есть пять уровней сцепления, а именно -

• Content coupling - Когда модуль может напрямую обращаться к содержимому другого модуля, изменять его или ссылаться на него, это называется связью на уровне содержимого.
• Common coupling- Когда несколько модулей имеют доступ для чтения и записи к некоторым глобальным данным, это называется общей или глобальной связью.
• Control coupling- Два модуля называются связанными по управлению, если один из них определяет функцию другого модуля или изменяет последовательность его выполнения.
• Stamp coupling- Когда несколько модулей имеют общую структуру данных и работают над разными ее частями, это называется связью штампов.
• Data coupling- Связь данных - это когда два модуля взаимодействуют друг с другом посредством передачи данных (в качестве параметра). Если модуль передает структуру данных в качестве параметра, то принимающий модуль должен использовать все свои компоненты.

В идеале лучшим вариантом считается отсутствие сцепления.

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

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

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

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

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

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

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

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

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

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

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

Типы DFD

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

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

Компоненты DFD

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

• Entities- Сущности являются источником и получателем информационных данных. Сущности представлены прямоугольниками с соответствующими именами.
• Process - Действия и действия, предпринятые с данными, представлены прямоугольниками с круглыми или закругленными краями.
• Data Storage - Существует два варианта хранения данных - он может быть представлен либо в виде прямоугольника с отсутствием обеих меньших сторон, либо в виде прямоугольника с открытыми сторонами, у которого отсутствует только одна сторона.
• Data Flow- Движение данных показано заостренными стрелками. Движение данных показано от основания стрелки в качестве источника к головке стрелки в качестве пункта назначения.

Уровни DFD

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

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


• Level 2 - На этом уровне DFD показывает, как данные проходят внутри модулей, упомянутых на уровне 1.

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

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

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

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

Вот символы, используемые при построении структурных диаграмм -

• Module- Он представляет процесс, подпрограмму или задачу. Модуль управления ответвляется на несколько субмодулей. Модули библиотеки можно использовать повторно и вызывать из любого модуля.
  
• Condition- Он представлен маленьким ромбиком в основании модуля. Он показывает, что модуль управления может выбрать любую подпрограмму на основе некоторого условия.
  
• Jump - Стрелка внутри модуля указывает на то, что элемент управления переместится в середину подмодуля.
  
• Loop- Изогнутая стрелка обозначает петлю в модуле. Все подмодули, охваченные циклом, повторяют выполнение модуля.
  
• Data flow - Направленная стрелка с пустым кружком в конце представляет поток данных.
  
• Control flow - Направленная стрелка с закрашенным кружком в конце представляет поток управления.
  

Схема HIPO

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

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

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

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

пример

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

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

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

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

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

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

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

IF-THEN-ELSE,  
DO-WHILE-UNTIL

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

пример

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

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
Действия	Проверить сетевой кабель	Икс
	Проверить интернет-роутер	Икс				Икс	Икс	Икс
	Перезагрузите веб-браузер							Икс
	Связаться с поставщиком услуг		Икс	Икс	Икс	Икс	Икс	Икс
	Не делать никаких действий

Таблица: Таблица решений - Устранение неполадок в Интернете собственными силами

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

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

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

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

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

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

  Отображение мощности:

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

Словарь с данными

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

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

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

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

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

Содержание

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

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

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

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

пример

Адрес = Номер дома + (Улица / Район) + Город + Штат

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

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

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

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

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

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

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

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

Есть два типа обработки данных:

• Logical: Как видит это пользователь
• Physical: Как это видит программное обеспечение

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

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

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

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

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

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

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

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

Coupling - связь между разными модулями.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Command Prompt- Это текстовое уведомление, которое в основном показывает контекст, в котором работает пользователь. Он генерируется программной системой.

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

• Command- Команда - это исполняемая инструкция. Он может иметь один или несколько параметров. Результат выполнения команды отображается на экране в виде строки. При создании вывода командная строка отображается в следующей строке.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  

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

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

  

• Radio-button- Отображает доступные варианты выбора. Из всех предложенных можно выбрать только один.

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

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

  

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

• Sliders
• Combo-box
• Data-grid
• Раскрывающийся список

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

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

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

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

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

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

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

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

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

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

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

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

пример

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

• FLUID
• AppInventor (Android)
• LucidChart
• Wavemaker
• Visual Studio

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

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

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

• Enable frequent users to use short-cuts- Желание пользователя сократить количество взаимодействий возрастает с частотой использования. Аббревиатуры, функциональные клавиши, скрытые команды и макросы очень полезны для опытного пользователя.

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

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

• Offer simple error handling- По возможности проектируйте систему таким образом, чтобы пользователь не допустил серьезных ошибок. В случае ошибки система должна уметь ее обнаруживать и предлагать простые и понятные механизмы обработки ошибки.

• Permit easy reversal of actions- Эта функция снимает беспокойство, поскольку пользователь знает, что ошибки можно исправить. Легкое изменение действий побуждает исследовать незнакомые варианты. Единицами обратимости могут быть отдельное действие, запись данных или полная группа действий.

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

• Reduce short-term memory load - Ограничение обработки человеческой информации в кратковременной памяти требует, чтобы дисплеи оставались простыми, отображение нескольких страниц было консолидировано, частота движения окон была уменьшена, а для кодов, мнемоники и последовательностей действий выделялось достаточное время.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Если управление может перейти от блока 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.

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

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

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

Посмотрим параметры функциональной точки:

Внешний вход

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

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

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

• Average - промежуточное между простым и сложным.

Внешний выход

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

• Simple - если количество выходов мало

• Complex - если количество выходов велико

• Average - между простым и сложным.

Логические внутренние файлы

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

• Simple - если количество типов записей мало

• Complex - если количество типов записей велико

• Average - между простым и сложным.

Файлы внешнего интерфейса

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

• Simple - если количество типов записей в общем файле мало

• Complex - если количество типов записей в общем файле велико

• Average - между простым и сложным.

Внешний запрос

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

• Simple - если запрос требует низкой обработки и дает небольшой объем выходных данных

• Complex - если запрос требует высокой обработки и дает большой объем выходных данных

• Average - между простым и сложным.

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

Параметр	просто	В среднем	Сложный
Входы	3	4	6
Выходы	4	5	7
Запрос	3	4	6
Файлы	7	10	15
Интерфейсы	5	7	10

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

• Передача данных
• Распределенная обработка
• Цели производительности
• Загрузка конфигурации работы
• Скорость транзакции
• Ввод данных онлайн,
• Эффективность конечного пользователя
• Онлайн-обновление
• Сложная логика обработки
• Re-usability
• Легкость установки
• Простота эксплуатации
• Несколько сайтов
• Желание способствовать изменениям

Затем эти характеристические коэффициенты оцениваются от 0 до 5, как указано ниже:

• Нет влияния
• Incidental
• Moderate
• Average
• Significant
• Essential

Затем все оценки суммируются как N. Значение N находится в диапазоне от 0 до 70 (14 типов характеристик x 5 типов оценок). Он используется для расчета поправочных коэффициентов сложности (CAF) по следующим формулам:

CAF = 0.65 + 0.01N

Потом,

Delivered Function Points (FP)= CAF x Raw FP

Затем этот FP можно использовать в различных показателях, таких как:

Cost = $ / FP

Quality = Ошибки / FP

Productivity = FP / человеко-месяц

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

Структурированное программирование

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

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

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

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

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

Функциональное программирование

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

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

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

Функциональное программирование использует следующие концепции:

• First class and High-order functions - Эти функции могут принимать другую функцию в качестве аргумента или возвращать другие функции в качестве результатов.

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

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

• Strict evaluation- Это метод оценки выражения, переданного функции в качестве аргумента. Функциональное программирование имеет два типа методов оценки: строгий (нетерпеливый) и нестрогий (ленивый). При строгой оценке выражение всегда оценивается перед вызовом функции. При нестрогом вычислении выражение не оценивается, если оно не требуется.

• λ-calculus- Большинство языков функционального программирования используют λ-исчисление в качестве систем типов. λ-выражения выполняются путем их оценки по мере их появления.

Common Lisp, Scala, Haskell, Erlang и F # - некоторые примеры языков функционального программирования.

Стиль программирования

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

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

Рекомендации по кодированию

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

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

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

• Indenting - Это пробел, оставшийся в начале строки, обычно 2-8 пробелов или одна табуляция.

• Whitespace - Обычно его опускают в конце строки.

• Operators- Определяет правила написания математических, присваивающих и логических операторов. Например, перед оператором присваивания «=» и после него должен быть пробел, как в «x = 2».

• Control Structures - Правила написания if-then-else, case-switch, while-until и для операторов потока управления исключительно и во вложенном режиме.

• Line length and wrapping- Определяет, сколько символов должно быть в одной строке, обычно длина строки 80 символов. Перенос определяет способ переноса строки, если она слишком длинная.

• Functions - Это определяет, как функции должны быть объявлены и вызваны, с параметрами и без них.

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

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

Программная документация

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

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

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

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

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

• Software Design documentation - Эта документация содержит всю необходимую информацию, которая необходима для создания программного обеспечения. Это содержит:(a) Программная архитектура высокого уровня, (b) Детали разработки программного обеспечения, (c) Диаграммы потоков данных, (d) Дизайн базы данных

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

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

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

  Доступны различные автоматизированные инструменты, некоторые из которых поставляются с самим языком программирования. Например, java поставляется с инструментом JavaDoc для создания технической документации кода.

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

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

Проблемы реализации программного обеспечения

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

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

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

• Target-Host- Программа, которая разрабатывается в организации, должна быть разработана для хост-компьютеров на стороне клиентов. Но иногда невозможно разработать программное обеспечение, работающее на целевых машинах.

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

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

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

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

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

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

• Проверка гарантирует, что разрабатываемый продукт соответствует проектным спецификациям.
• Проверка отвечает на вопрос: «Разрабатываем ли мы этот продукт, строго следуя всем проектным спецификациям?»
• Проверки сосредоточены на дизайне и технических характеристиках системы.

Цель теста -

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

• Fault- При наличии ошибки возникает ошибка. Неисправность, также известная как ошибка, является результатом ошибки, которая может вызвать сбой системы.

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

Ручное против автоматизированного тестирования

Тестирование можно проводить вручную или с помощью автоматизированного инструмента тестирования:

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

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

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

Тест должен проверить, можно ли открыть веб-страницу в Internet Explorer. Это легко сделать с помощью ручного тестирования. Но проверить, выдержит ли веб-сервер нагрузку в 1 миллион пользователей, вручную протестировать невозможно.

Есть программные и аппаратные средства, которые помогают тестировщику проводить нагрузочное тестирование, стресс-тестирование, регрессионное тестирование.

Подходы к тестированию

Испытания могут проводиться на основе двух подходов -

• Функциональное тестирование
• Тестирование реализации

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

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

Тестирование черного ящика

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

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

Методы тестирования черного ящика:

• Equivalence class- Вход разделен на похожие классы. Если один элемент класса проходит проверку, предполагается, что пройден весь класс.

• Boundary values- Входные данные делятся на верхнее и нижнее конечные значения. Если эти значения проходят проверку, предполагается, что все значения между ними также могут пройти.

• Cause-effect graphing- В обоих предыдущих методах одновременно проверяется только одно входное значение. Причина (вход) - Эффект (выход) - это метод тестирования, при котором комбинации входных значений проверяются систематическим образом.

• Pair-wise Testing- Поведение программного обеспечения зависит от множества параметров. При попарном тестировании несколько параметров проверяются попарно на предмет их различных значений.

• State-based testing- Система меняет состояние при предоставлении ввода. Эти системы тестируются на основе их состояний и вводимых данных.

Тестирование белого ящика

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

В этом методе тестирования тестировщику известны дизайн и структура кода. Программисты кода проводят этот тест на коде.

Ниже приведены некоторые методы тестирования белого ящика:

• Control-flow testing- Цель тестирования потока управления - установить тестовые примеры, которые охватывают все операторы и условия перехода. Условия ветвления проверяются как на истинность, так и на ложность, чтобы можно было охватить все утверждения.

• Data-flow testing- Этот метод тестирования направлен на охват всех переменных данных, включенных в программу. Он проверяет, где переменные были объявлены и определены и где они были использованы или изменены.

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

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

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

Модульное тестирование

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

Интеграционное тестирование

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

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

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

• Functionality testing - Проверяет все функции программного обеспечения на соответствие требованиям.

• Performance testing- Этот тест доказывает, насколько эффективно программное обеспечение. Он проверяет эффективность и среднее время, затрачиваемое программным обеспечением на выполнение желаемой задачи. Тестирование производительности выполняется посредством нагрузочного тестирования и стресс-тестирования, при котором программное обеспечение подвергается высокой пользовательской нагрузке и нагрузке на данные в различных условиях среды.

• Security & Portability - Эти тесты проводятся, когда программное обеспечение предназначено для работы на различных платформах и доступно определенному количеству людей.

Приемочное тестирование

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

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

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

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

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

Документация по тестированию

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

Перед тестированием

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

• SRS document - Документ функциональных требований

• Test Policy document - Здесь описывается, как далеко должно пройти тестирование перед выпуском продукта.

• Test Strategy document - Здесь подробно описаны аспекты группы тестирования, матрица ответственности и права / ответственность менеджера по тестированию и инженера по тестированию.

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

Во время тестирования

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

• Test Case document- В этом документе содержится список тестов, которые необходимо провести. Он включает план модульного тестирования, план тестирования интеграции, план тестирования системы и план приемочного тестирования.

• Test description - Этот документ представляет собой подробное описание всех тестовых примеров и процедур их выполнения.

• Test case report - Этот документ содержит отчет о тестовом примере в результате тестирования.

• Test logs - Этот документ содержит журналы тестирования для каждого отчета о тестировании.

После тестирования

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

• Test summary- Эта сводка испытаний представляет собой коллективный анализ всех отчетов и журналов испытаний. Он подводит итоги и делает вывод о том, готово ли программное обеспечение к запуску. Программное обеспечение выпускается под системой контроля версий, если оно готово к запуску.

Тестирование против контроля качества, обеспечения качества и аудита

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

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

• Software quality control- Это система для поддержания качества программного продукта. Он может включать в себя функциональные и нефункциональные аспекты программного продукта, которые повышают репутацию организации. Эта система гарантирует, что заказчик получает качественный продукт, соответствующий его требованиям, и продукт, сертифицированный как «пригодный для использования».

• Software audit- Это обзор процедуры, используемой организацией для разработки программного обеспечения. Группа аудиторов, независимая от группы разработчиков, изучает программный процесс, процедуру, требования и другие аспекты SDLC. Целью аудита программного обеспечения является проверка того, что программное обеспечение и процесс его разработки соответствуют стандартам, правилам и нормам.

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

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

• Client Requirements - Со временем покупатель может запросить новые функции или возможности в программном обеспечении.

• Host Modifications - Если какое-либо оборудование и / или платформа (например, операционная система) целевого хоста изменяются, необходимо внести изменения в программное обеспечение, чтобы сохранить адаптируемость.

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

Виды обслуживания

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

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

• Adaptive Maintenance - Сюда входят модификации и обновления, применяемые для поддержания актуальности программного продукта и его адаптации к постоянно меняющимся технологиям и бизнес-среде.

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

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

Стоимость обслуживания

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

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

Факторы реального мира, влияющие на стоимость обслуживания

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

Программные факторы, влияющие на стоимость обслуживания

• Структура программного обеспечения
• Язык программирования
• Зависимость от внешней среды
• Надежность и доступность персонала

Мероприятия по техническому обслуживанию

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

Эти действия идут рука об руку с каждым из следующих этапов:

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

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

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

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

• System Testing- Интеграционное тестирование выполняется среди вновь созданных модулей. Также проводится интеграционное тестирование между новыми модулями и системой. Наконец, система тестируется в целом после процедур регрессионного тестирования.

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

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

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

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

Реинжиниринг программного обеспечения

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

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

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

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

Процесс реинжиниринга

• Decideчто перепроектировать. Это все программное обеспечение или его часть?
• Perform Обратный инжиниринг, чтобы получить спецификации существующего программного обеспечения.
• Restructure Programесли необходимо. Например, преобразование функционально-ориентированных программ в объектно-ориентированные программы.
• Re-structure data как требуется.
• Apply Forward engineering концепции, чтобы получить переработанное программное обеспечение.

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

Разобрать механизм с целью понять, как это работает

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

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

Реструктуризация программы

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

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

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

Форвард Инжиниринг

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

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

Возможность многократного использования компонентов

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

пример

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

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

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

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

Возникла совершенно новая вертикаль, основанная на повторном использовании программных компонентов и известная как Component Based Software Engineering (CBSE).

Повторное использование может быть выполнено на разных уровнях

• Application level - Когда все приложение используется как подсистема нового программного обеспечения.

• Component level - Где используется подсистема приложения.

• Modules level - Где повторно используются функциональные модули.

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

Процесс повторного использования

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

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

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

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

• Search Suitable Components - Репозиторий программных компонентов направляется разработчиками для поиска подходящего компонента на основе функциональности и предполагаемых требований к программному обеспечению.

• Incorporate Components - Все согласованные компоненты упакованы вместе, чтобы сформировать их как законченное программное обеспечение.

CASE означает Cкомпьютер Aидея Sпрограммное обеспечение Eинжиниринг. Это разработка и сопровождение программных проектов с помощью различных автоматизированных программных средств.

CASE Инструменты

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

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

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

Компоненты CASE Tools

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

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

  

• Upper Case Tools - Инструменты Upper CASE используются на этапах планирования, анализа и проектирования SDLC.

• Lower Case Tools - Инструменты нижнего CASE используются при внедрении, тестировании и обслуживании.

• Integrated Case Tools - Интегрированные инструменты CASE полезны на всех этапах SDLC, от сбора требований до тестирования и документации.

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

Объем инструментов кейса

Набор инструментов CASE распространяется на весь SDLC.

Типы инструментов кейса

Теперь мы кратко рассмотрим различные инструменты CASE.

Инструменты диаграмм

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

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

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

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

Эти инструменты используются для планирования проекта, оценки затрат и усилий, планирования проекта и планирования ресурсов. Менеджеры должны строго соблюдать каждый упомянутый шаг в управлении проектами программного обеспечения при выполнении проекта. Инструменты управления проектами помогают хранить и обмениваться информацией о проекте в реальном времени в рамках всей организации. Например, Creative Pro Office, Trac Project, Basecamp.

Инструменты документации

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

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

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

Эти инструменты помогают собирать требования, автоматически проверять любые несоответствия, неточности в диаграммах, избыточность данных или ошибочные пропуски. Например, Accept 360, Accompa, CaseComplete для анализа требований, Visible Analyst для общего анализа.

Инструменты дизайна

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

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

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

• Управление версиями и редакциями
• Управление базовой конфигурацией
• Управление изменениями

Инструменты CASE помогают в этом путем автоматического отслеживания, управления версиями и выпусками. Например, Fossil, Git, Accu REV.

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

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

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

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

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

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

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

Инструменты веб-разработки

Эти инструменты помогают создавать веб-страницы со всеми сопутствующими элементами, такими как формы, текст, сценарий, графика и т. Д. Веб-инструменты также обеспечивают предварительный просмотр того, что разрабатывается, и того, как это будет выглядеть после завершения. Например, Fontello, Adobe Edge Inspect, Foundation 3, Brackets.

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

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

Инструменты для обслуживания

Обслуживание программного обеспечения включает в себя модификации программного продукта после его доставки. Методы автоматического ведения журналов и отчетов об ошибках, автоматическое создание билетов об ошибках и анализ первопричин - это лишь несколько инструментов CASE, которые помогают организации программного обеспечения на этапе обслуживания SDLC. Например, Bugzilla для отслеживания дефектов, HP Quality Center.