Что предпологает руководство по

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

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

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

Основная цель документа «Руководство пользователя» заключается в обеспечении пользователя необходимой информацией для самостоятельной работы с программой или автоматизированной системой. Документ должен отвечать на следующие вопросы: назначение программы, её возможности; что необходимо для обеспечения ее корректного функционирования и, что делать в случае отказа системы [1].

В статье приводится пример структуры «Руководства пользователя» для программного  обеспечения «Зарплата и кадры», используемого в Инновационном Евразийском университете (ИнЕУ).

«Руководство пользователя» должно состоять из двух частей:

• руководство пользователя;
• руководство оператора.

Структура руководства пользователя содержит:

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

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

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

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

• Виды деятельности и функции. В этом подразделе описываются функции, для автоматизации которых предназначена программа.
• Условия применения. В подразделе описываются условия, при которых обеспечивается полноценное применение программного обеспечения. В качестве таких условий могут выступать требования к аппаратному  обеспечению,  на  котором  будет  использоваться  программное  обеспечение, и квалификация сотрудников, которые будут работать с описываемым программным  продуктом. Например,  для  корректной  работы   программного   обеспечения   «Зарплата   и   кадры» рекомендовано не выполнять на компьютере параллельно других ресурсоемких задач [2]. 

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

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

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

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

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

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

Структура руководства оператора содержит:

1. Установка а сервер. Программное обеспечение «Зарплата и кадры» является многопользовательским, следовательно, оно имеет централизованную базу данных. В разделе описывается процесс установки программного обеспечения на сервер. Пошаговая инструкция дает точные указания, каким образом необходимо выполнить установку, в зависимости от технического состояния сервера. Настройка сервера для обеспечения работоспособности программного приложения «Зарплата и кадры» является основным моментом администрирования, так как сервер хранит большие объемы различной информации.
2. Установка локальная. В разделе описывается процесс настройки компьютеров, использующих программное приложение, также даются рекомендации по оптимизации настройки рабочих станций, чтобы улучшить процесс взаимодействия сервера и компьютеров пользователей.
3. Администрирование пользователей. В разделе подробно описывается процесс администрирования учетных записей пользователей программного обеспечения «Зарплата и кадры». Подробная инструкция описывает все   ситуации,   которые   могут   возникнуть   при   управлении   пользователями.   Например, с помощью   данной    подсистемы    можно    централизованно    завершать    все    активные    соединения с информационной базой и устанавливать блокировку новых соединений на определенный  период времени.   Такая    возможность    полезна    при    выполнении    различных    административных действий с информационной базой.
4. Информационная база. В разделе рассматриваются вопросы администрирования, сохранения, переноса базы данных. Описаны рекомендации по настройке базы данных. Например, рассматривается ситуация резервного копирования. Программное обеспечение «Зарплата и кадры» позволяет создавать резервные копии информационной базы. Резервное копирование может выполняться как в автоматическом режиме, так и в ручном. Для автоматического режима предварительно необходимо выполнить настройки. В любой момент можно восстановить данные информационной базы из созданной ранее резервной копии.
5. Технические неполадки. Этот раздел содержит информацию о возможных технических проблемах, которые могут возникнуть в процессе эксплуатации программного обеспечения. Рассматриваются проблемы, возникающие в результате некорректной работы оборудования, а также ситуации, возникающие в результате некорректного использования функций программного обеспечения «Зарплата и кадры». 

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

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

СПИСОК ЛИТЕРАТУРЫ

1. Радченко М.Г. 1С: Предприятие 0. Практическое пособие разработчика. Примеры и типовые приемы . – 1С – Паблишинг, 2004. – 656 с.
2. Тимофеев Г., Шумейко Д. Конфигурирование и администрирование 1С: Предприятия. – Ростов н/Д: Феникс, 2003. – 320 с.

За прекрасную картинку спасибо Toggl.com.

Подготовлено по материалам вебинара «Модели и методологии разработки ПО» Анастасии Кайгородовой, преподавателя факультета тестирования ПО.

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

Этапы жизненного цикла ПО

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

Рассмотрим эти этапы на примере жизненного цикла интернет-магазина.

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

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

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

Поддержка. Иван подписал акт сдачи-приёмки, и подрядчик разместил интернет-магазин на «боевых» серверах. Пользователи начали его посещать и сообщать о замеченных ошибках в поддержку, а программисты — оперативно всё исправлять.

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

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

Основные модели разработки ПО

• Code and fix — модель кодирования и устранения ошибок;
• Waterfall Model — каскадная модель, или «водопад»;
• V-model — V-образная модель, разработка через тестирование;
• Incremental Model — инкрементная модель;
• Iterative Model — итеративная (или итерационная) модель;
• Spiral Model — спиральная модель;
• Chaos model — модель хаоса;
• Prototype Model — прототипная модель.

Из этих моделей наиболее популярны пять основных: каскадная, V-образная, инкрементная, итерационная и спиральная. Разберём их подробнее.

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

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

Преимущества «водопада»

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

Недостатки каскадной модели

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

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

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

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

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

Преимущества V-образной модели

• Количество ошибок в архитектуре ПО сводится к минимуму.

Недостатки V-образной модели

• Если при разработке архитектуры была допущена ошибка, то вернуться и исправить её будет стоить дорого, как и в «водопаде».

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

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

Это модель разработки по частям (increment в переводе с англ. — приращение) уходит корнями в 1930-е. Рассмотрим её на примере создания социальной сети.

1. Заказчик решил, что хочет запустить соцсеть, и написал подробное техническое задание. Программисты предложили реализовать основные функции — страницу с личной информацией и чат. А затем протестировать на пользователях, «взлетит или нет».
2. Команда разработки показывает продукт заказчику и выпускает его на рынок. Если и заказчику, и пользователям социальная сеть нравится, работа над ней продолжается, но уже по частям.
3. Программисты параллельно создают функциональность для загрузки фотографий, обмена документами, прослушивания музыки и других действий, согласованных с заказчиком. Инкремент за инкрементом они совершенствуют продукт, приближаясь к описанному в техническом задании.

Преимущества инкрементной модели

• Не нужно вкладывать много денег на начальном этапе. Заказчик оплачивает создание основных функций, получает продукт, «выкатывает» его на рынок — и по итогам обратной связи решает, продолжать ли разработку.
• Можно быстро получить фидбэк от пользователей и оперативно обновить техническое задание. Так снижается риск создать продукт, который никому не нужен.
• Ошибка обходится дешевле. Если при разработке архитектуры была допущена ошибка, то исправить её будет стоить не так дорого, как в «водопаде» или V-образной модели.

Недостатки инкрементной модели

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

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

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

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

Рассмотрим на примере создания мессенджера, как эта модель работает.

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

Преимущества итеративной модели

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

Недостатки итеративной модели

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

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

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

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

Рассмотрим, как функционирует эта модель, на примере разработки системы «Умный дом». 

1. Заказчик решил, что хочет сделать такую систему, и заказал программистам реализовать управление чайником с телефона. Они начали действовать по модели «водопад»: выслушали идею, провели анализ предложений на рынке, обсудили с заказчиком архитектуру системы, решили, как будут её реализовывать, разработали, протестировали и «выкатили» конечный продукт.
2. Заказчик оценил результат и риски: насколько нужна пользователям следующая версия продукта — уже с управлением телевизором. Рассчитал сроки, бюджет и заказал разработку. Программисты действовали по каскадной модели и представили заказчику более сложный продукт, разработанный на базе первого.
3. Заказчик подумал, что пора создать функциональность для управления холодильником с телефона. Но, анализируя риски, понял, что в холодильник сложно встроить Wi-Fi-модуль, да и производители не заинтересованы в сотрудничестве по этому вопросу. Следовательно, риски превышают потенциальную выгоду. На основе полученных данных заказчик решил прекратить разработку и совершенствовать имеющуюся функциональность, чтобы со временем понять, как развивать систему «Умный дом».

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

Преимущества спиральной модели

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

Недостатки спиральной модели

• Есть риск застрять на начальном этапе — бесконечно совершенствовать первую версию продукта и не продвинуться к следующим.
• Разработка длится долго и стоит дорого.

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

Что такое Agile?

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

• экстремальное программирование (Extreme Programming, XP);
• бережливую разработку программного обеспечения (Lean);
• фреймворк для управления проектами Scrum;
• разработку, управляемую функциональностью (Feature-driven development, FDD);
• разработку через тестирование (Test-driven development, TDD);
• методологию «чистой комнаты» (Cleanroom Software Engineering);
• итеративно-инкрементальный метод разработки (OpenUP);
• методологию разработки Microsoft Solutions Framework (MSF);
• метод разработки динамических систем (Dynamic Systems Development Method, DSDM);
• метод управления разработкой Kanban.

Различия между Agile и традиционным подходом к разработке мы свели в таблице:

Не всё перечисленное в списке — методологии. Например, Scrum чаще называют не методологией, а фреймворком. В чём разница? Фреймворк — это более сформированная методология со строгими правилами. В скраме все роли и процессы чётко прописаны. Помимо Scrum, часто используют Kanban. 

Kanban

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

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

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

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

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

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

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

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

Определения

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

переходный

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

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

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

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

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

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

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

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

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

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

связь

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

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

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

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

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

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

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

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

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

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

кодирование

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

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

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

интеграция

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

Реализация

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

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

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

диспозиция

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

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

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

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

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

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

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

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

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

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

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

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

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

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

V – модель

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Модель Putnam

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

• COCOMO

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

базисный

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Диаграмма PERT

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Интервью

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

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

Обзоры

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

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

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

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

Анализ задач

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

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

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

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

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

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

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

наблюдение

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

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

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

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

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

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

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

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

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

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

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

Примеры –

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Модульность

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

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

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

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

совпадение

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

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

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

пример

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

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

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

когезия

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

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

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

Связь

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Типы ДФД

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

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

DFD Компоненты

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

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

Уровни DFD

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



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



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

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

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

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

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

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

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

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

Диаграмма HIPO

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

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

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

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

пример

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

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

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

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

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

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

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

IF-THEN-ELSE,  
DO-WHILE-UNTIL

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

пример

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

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

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

Псевдо-код

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

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

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

пример

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

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

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

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

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

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

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

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

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

пример

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

содержание

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

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

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

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

пример

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Элементы CLI

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  

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

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

  

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

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

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

  

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

пример

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  Нарисуй дугу

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

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

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

Нарисуй дугу

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

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

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

V(G) = e – n + 2

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

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

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

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

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

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

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

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

Внешний вход

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

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

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

• Средний – между простым и сложным.

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

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

Средний – между простым и сложным.

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

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

• Простой – если количество выводов мало

• Сложный – если количество выводов велико

• Средний – между простым и сложным.

Простой – если количество выводов мало

Сложный – если количество выводов велико

Средний – между простым и сложным.

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

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

• Просто – если количество типов записей мало

• Сложный – если количество типов записей велико

• Средний – между простым и сложным.

Просто – если количество типов записей мало

Сложный – если количество типов записей велико

Средний – между простым и сложным.

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

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

• Просто – если количество типов записей в общем файле мало

• Сложный – если количество типов записей в общем файле велико

• Средний – между простым и сложным.

Просто – если количество типов записей в общем файле мало

Сложный – если количество типов записей в общем файле велико

Средний – между простым и сложным.

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

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

• Просто – если запрос требует низкой обработки и выдает небольшое количество выходных данных

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

• Средний – между простым и сложным.

Просто – если запрос требует низкой обработки и выдает небольшое количество выходных данных

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

Средний – между простым и сложным.

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

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

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

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

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

• Нет влияния
• случайный
• умеренный
• Средний
• Значительное
• существенный

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

 CAF = 0,65 + 0,01N

Затем,

 Поставленные функциональные точки (FP) = CAF x Raw FP

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

Стоимость = $ / FP

Качество = Ошибки / FP

Производительность = FP / человеко-месяц

Стоимость = $ / FP

Качество = Ошибки / FP

Производительность = FP / человеко-месяц

Программная реализация

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Строгая оценка – это метод оценки выражения, переданного функции в качестве аргумента. Функциональное программирование имеет два типа методов оценки: строгий (нетерпеливый) или нестрогий (ленивый). Строгая оценка всегда вычисляет выражение перед вызовом функции. Нестрогая оценка не оценивает выражение, если оно не требуется.

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

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

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

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

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

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

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

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

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

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

Руководство по кодированию

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

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

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

• Отступ – это пробел, оставленный в начале строки, обычно 2-8 пробелов или одна вкладка.

• Пробелы – обычно не указываются в конце строки.

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

• Управляющие структуры – правила написания if-then-else, case-switch, while-before и для операторов потока управления исключительно и во вложенном виде.

• Длина строки и перенос – определяет, сколько символов должно быть в одной строке, в основном длина строки составляет 80 символов. Обтекание определяет способ переноса строки, если она слишком длинная.

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

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

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

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

Отступ – это пробел, оставленный в начале строки, обычно 2-8 пробелов или одна вкладка.

Пробелы – обычно не указываются в конце строки.

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

Управляющие структуры – правила написания if-then-else, case-switch, while-before и для операторов потока управления исключительно и во вложенном виде.

Длина строки и перенос – определяет, сколько символов должно быть в одной строке, в основном длина строки составляет 80 символов. Обтекание определяет способ переноса строки, если она слишком длинная.

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

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

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

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

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

Ухоженная документация должна включать следующие документы:

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

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

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

• Документация по разработке программного обеспечения – эта документация содержит всю необходимую информацию, необходимую для создания программного обеспечения. Он содержит: (a) архитектуру программного обеспечения высокого уровня, (b) детали разработки программного обеспечения, (c) диаграммы потоков данных, (d) проектирование базы данных

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

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

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

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

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

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

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

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

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

Документация по разработке программного обеспечения – эта документация содержит всю необходимую информацию, необходимую для создания программного обеспечения. Он содержит: (a) архитектуру программного обеспечения высокого уровня, (b) детали разработки программного обеспечения, (c) диаграммы потоков данных, (d) проектирование базы данных

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Целью теста являются –

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

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

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

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

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

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

Ручное и автоматическое тестирование

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Основанное на состоянии тестирование – система изменяет состояние при предоставлении ввода. Эти системы тестируются на основе их состояний и входных данных.

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

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

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

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

Основанное на состоянии тестирование – система изменяет состояние при предоставлении ввода. Эти системы тестируются на основе их состояний и входных данных.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Тестовые документы готовятся на разных этапах –

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

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

• Документ СГД – Документ о функциональных требованиях

• Документ о политике тестирования – описывает, как далеко должно пройти тестирование перед выпуском продукта.

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

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

Документ СГД – Документ о функциональных требованиях

Документ о политике тестирования – описывает, как далеко должно пройти тестирование перед выпуском продукта.

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

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

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

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

• Документ тестового примера – этот документ содержит список тестов, которые необходимо провести. Он включает в себя план модульных испытаний, план интеграционных испытаний, план системных испытаний и план приемочных испытаний.

• Описание теста – Этот документ представляет собой подробное описание всех тестовых случаев и процедур для их выполнения.

• Отчет о тестовом наборе – этот документ содержит отчет о тестовом наборе в результате теста.

• Журналы тестов – этот документ содержит журналы тестов для каждого отчета о тестовом примере.

Документ тестового примера – этот документ содержит список тестов, которые необходимо провести. Он включает в себя план модульных испытаний, план интеграционных испытаний, план системных испытаний и план приемочных испытаний.

Описание теста – Этот документ представляет собой подробное описание всех тестовых случаев и процедур для их выполнения.

Отчет о тестовом наборе – этот документ содержит отчет о тестовом наборе в результате теста.

Журналы тестов – этот документ содержит журналы тестов для каждого отчета о тестовом примере.

После тестирования

Следующие документы могут быть созданы после тестирования:

• Сводка теста – Эта сводка теста представляет собой сводный анализ всех отчетов и журналов испытаний. Он суммирует и делает вывод, готово ли программное обеспечение для запуска. Программное обеспечение выпущено под системой контроля версий, если оно готово к запуску.

Сводка теста – Эта сводка теста представляет собой сводный анализ всех отчетов и журналов испытаний. Он суммирует и делает вывод, готово ли программное обеспечение для запуска. Программное обеспечение выпущено под системой контроля версий, если оно готово к запуску.

Тестирование и контроль качества, обеспечение качества и аудит

Мы должны понимать, что тестирование программного обеспечения отличается от обеспечения качества программного обеспечения, контроля качества программного обеспечения и аудита программного обеспечения.

• Обеспечение качества программного обеспечения – это средства мониторинга процесса разработки программного обеспечения, с помощью которых гарантируется, что все меры принимаются в соответствии со стандартами организации. Этот мониторинг делается для того, чтобы убедиться, что были соблюдены надлежащие методы разработки программного обеспечения.

• Контроль качества программного обеспечения – это система для поддержания качества программного продукта. Это может включать функциональные и нефункциональные аспекты программного продукта, которые повышают доброжелательность организации. Эта система гарантирует, что клиент получает качественный продукт для своих требований и продукт, сертифицированный как «пригодный для использования».

• Аудит программного обеспечения – это обзор процедуры, используемой организацией для разработки программного обеспечения. Команда аудиторов, независимая от команды разработчиков, изучает процесс, процедуру, требования и другие аспекты SDLC. Целью аудита программного обеспечения является проверка того, что программное обеспечение и процесс его разработки соответствуют стандартам, правилам и нормам.

Обеспечение качества программного обеспечения – это средства мониторинга процесса разработки программного обеспечения, с помощью которых гарантируется, что все меры принимаются в соответствии со стандартами организации. Этот мониторинг делается для того, чтобы убедиться, что были соблюдены надлежащие методы разработки программного обеспечения.

Контроль качества программного обеспечения – это система для поддержания качества программного продукта. Это может включать функциональные и нефункциональные аспекты программного продукта, которые повышают доброжелательность организации. Эта система гарантирует, что клиент получает качественный продукт для своих требований и продукт, сертифицированный как «пригодный для использования».

Аудит программного обеспечения – это обзор процедуры, используемой организацией для разработки программного обеспечения. Команда аудиторов, независимая от команды разработчиков, изучает процесс, процедуру, требования и другие аспекты SDLC. Целью аудита программного обеспечения является проверка того, что программное обеспечение и процесс его разработки соответствуют стандартам, правилам и нормам.

Обзор обслуживания программного обеспечения

В настоящее время поддержка программного обеспечения является широко распространенной частью SDLC. Он обозначает все модификации и обновления, сделанные после поставки программного продукта. Существует ряд причин, по которым необходимо внести изменения, некоторые из них кратко упомянуты ниже:

• Рыночные условия – Политики, которые меняются с течением времени, такие как налогообложение и недавно введенные ограничения, такие как ведение бухгалтерского учета, могут вызывать необходимость внесения изменений.

• Требования к клиенту. Со временем клиент может запросить новые функции или функции в программном обеспечении.

• Модификации хоста. Если изменяется какое-либо оборудование и / или платформа (например, операционная система) целевого хоста, то для сохранения адаптивности необходимы изменения программного обеспечения.

• Изменения в организации – если на стороне клиента происходят какие-либо изменения на уровне бизнеса, такие как уменьшение силы организации, приобретение другой компании, организация, выходящая на новый бизнес, может возникнуть необходимость в модификации исходного программного обеспечения.

Рыночные условия – Политики, которые меняются с течением времени, такие как налогообложение и недавно введенные ограничения, такие как ведение бухгалтерского учета, могут вызывать необходимость внесения изменений.

Требования к клиенту. Со временем клиент может запросить новые функции или функции в программном обеспечении.

Модификации хоста. Если изменяется какое-либо оборудование и / или платформа (например, операционная система) целевого хоста, то для сохранения адаптивности необходимы изменения программного обеспечения.

Изменения в организации – если на стороне клиента происходят какие-либо изменения на уровне бизнеса, такие как уменьшение силы организации, приобретение другой компании, организация, выходящая на новый бизнес, может возникнуть необходимость в модификации исходного программного обеспечения.

Типы обслуживания

В течение срока службы программного обеспечения тип обслуживания может варьироваться в зависимости от его характера. Это могут быть просто рутинные задачи обслуживания, как некоторые ошибки, обнаруженные каким-либо пользователем, или это может быть большое событие само по себе в зависимости от размера или характера обслуживания. Ниже приведены некоторые виды обслуживания на основе их характеристик:

• Корректирующее обслуживание – это включает в себя модификации и обновления, сделанные для исправления или исправления проблем, которые либо обнаруживаются пользователем, либо заключаются в пользовательских отчетах об ошибках.

• Адаптивное обслуживание – сюда входят модификации и обновления, применяемые для поддержания программного продукта в актуальном состоянии и в соответствии с постоянно меняющимся миром технологий и бизнес-среды.

• Безупречное техническое обслуживание – это включает в себя модификации и обновления, сделанные для того, чтобы программное обеспечение работало в течение длительного периода времени. Он включает в себя новые функции, новые пользовательские требования для доработки программного обеспечения и повышения его надежности и производительности.

• Профилактическое обслуживание – включает в себя модификации и обновления, чтобы предотвратить будущие проблемы программного обеспечения. Он направлен на решение проблем, которые не являются существенными в данный момент, но могут вызвать серьезные проблемы в будущем.

Корректирующее обслуживание – это включает в себя модификации и обновления, сделанные для исправления или исправления проблем, которые либо обнаруживаются пользователем, либо заключаются в пользовательских отчетах об ошибках.

Адаптивное обслуживание – сюда входят модификации и обновления, применяемые для поддержания программного продукта в актуальном состоянии и в соответствии с постоянно меняющимся миром технологий и бизнес-среды.

Безупречное техническое обслуживание – это включает в себя модификации и обновления, сделанные для того, чтобы программное обеспечение работало в течение длительного периода времени. Он включает в себя новые функции, новые пользовательские требования для доработки программного обеспечения и повышения его надежности и производительности.

Профилактическое обслуживание – включает в себя модификации и обновления, чтобы предотвратить будущие проблемы программного обеспечения. Он направлен на решение проблем, которые не являются существенными в данный момент, но могут вызвать серьезные проблемы в будущем.

Стоимость обслуживания

Отчеты показывают, что стоимость обслуживания высока. Исследование по оценке обслуживания программного обеспечения показало, что стоимость обслуживания составляет 67% от стоимости всего цикла обработки программного обеспечения.

В среднем стоимость обслуживания программного обеспечения составляет более 50% всех фаз SDLC. Существуют различные факторы, которые вызывают высокую стоимость обслуживания, такие как:

Фактические факторы, влияющие на стоимость обслуживания

• Стандартный возраст любого программного обеспечения считается от 10 до 15 лет.
• Старые программные продукты, которые должны были работать на медленных компьютерах с меньшим объемом памяти и емкостью хранения, не могут противостоять новым улучшенным программным средствам на современном оборудовании.
• По мере развития технологий обслуживание старого программного обеспечения становится дорогостоящим.
• Большинство инженеров по техническому обслуживанию являются новичками и используют метод проб и ошибок, чтобы исправить проблему.
• Часто внесенные изменения могут легко повредить исходную структуру программного обеспечения, затрудняя любые последующие изменения.
• Изменения часто остаются недокументированными, что может вызвать больше конфликтов в будущем.

Конечные факторы, влияющие на стоимость обслуживания

• Структура программного обеспечения
• Язык программирования
• Зависимость от внешней среды
• Надежность и доступность персонала

Деятельность по обслуживанию

IEEE обеспечивает основу для последовательных действий по обслуживанию. Он может быть использован итеративным способом и может быть расширен, чтобы можно было включать настраиваемые элементы и процессы.

Эти действия идут рука об руку с каждым из следующих этапов:

• Идентификация и отслеживание – включает в себя действия, относящиеся к идентификации требования модификации или технического обслуживания. Он генерируется пользователем или система сама может сообщать через журналы или сообщения об ошибках. Здесь также классифицируется тип обслуживания.

• Анализ – Модификация анализируется на предмет ее воздействия на систему, включая последствия для безопасности. Если вероятное воздействие серьезное, ищется альтернативное решение. Набор необходимых модификаций затем материализуется в спецификации требований. Стоимость модификации / обслуживания анализируется и оценка завершается.

• Проектирование. Новые модули, которые необходимо заменить или модифицировать, разработаны с учетом требований, установленных на предыдущем этапе. Контрольные примеры создаются для проверки и подтверждения.

• Внедрение . Новые модули кодируются с помощью структурированного проекта, созданного на этапе проектирования. Предполагается, что каждый программист будет выполнять модульное тестирование параллельно.

• Системное тестирование – Интеграционное тестирование проводится среди вновь созданных модулей. Интеграционное тестирование также проводится между новыми модулями и системой. Наконец, система тестируется в целом, следуя процедурам регрессивного тестирования.

• Приемочное тестирование. После внутреннего тестирования система проверяется на прием с помощью пользователей. Если пользователь находится в этом состоянии, он жалуется на некоторые проблемы, которые он решает или отмечает для решения в следующей итерации.

• Доставка – после приемочного тестирования система развертывается по всей организации с помощью небольшого пакета обновлений или новой установки системы. Окончательное тестирование проводится на стороне клиента после доставки программного обеспечения.

  Учебный центр предоставляется в случае необходимости, в дополнение к печатному экземпляру руководства пользователя.

• Управление техническим обслуживанием. Управление конфигурацией является неотъемлемой частью технического обслуживания системы. Это помогает инструментам контроля версий управлять версиями, полу-версиями или исправлениями.

Идентификация и отслеживание – включает в себя действия, относящиеся к идентификации требования модификации или технического обслуживания. Он генерируется пользователем или система сама может сообщать через журналы или сообщения об ошибках. Здесь также классифицируется тип обслуживания.

Анализ – Модификация анализируется на предмет ее воздействия на систему, включая последствия для безопасности. Если вероятное воздействие серьезное, ищется альтернативное решение. Набор необходимых модификаций затем материализуется в спецификации требований. Стоимость модификации / обслуживания анализируется и оценка завершается.

Проектирование. Новые модули, которые необходимо заменить или модифицировать, разработаны с учетом требований, установленных на предыдущем этапе. Контрольные примеры создаются для проверки и подтверждения.

Внедрение . Новые модули кодируются с помощью структурированного проекта, созданного на этапе проектирования. Предполагается, что каждый программист будет выполнять модульное тестирование параллельно.

Системное тестирование – Интеграционное тестирование проводится среди вновь созданных модулей. Интеграционное тестирование также проводится между новыми модулями и системой. Наконец, система тестируется в целом, следуя процедурам регрессивного тестирования.

Приемочное тестирование. После внутреннего тестирования система проверяется на прием с помощью пользователей. Если пользователь находится в этом состоянии, он жалуется на некоторые проблемы, которые он решает или отмечает для решения в следующей итерации.

Доставка – после приемочного тестирования система развертывается по всей организации с помощью небольшого пакета обновлений или новой установки системы. Окончательное тестирование проводится на стороне клиента после доставки программного обеспечения.

Учебный центр предоставляется в случае необходимости, в дополнение к печатному экземпляру руководства пользователя.

Управление техническим обслуживанием. Управление конфигурацией является неотъемлемой частью технического обслуживания системы. Это помогает инструментам контроля версий управлять версиями, полу-версиями или исправлениями.

Реинжиниринг программного обеспечения

Когда нам нужно обновить программное обеспечение, чтобы оно соответствовало текущему рынку, не влияя на его функциональность, это называется реинжиниринг программного обеспечения. Это тщательный процесс, когда дизайн программного обеспечения меняется, а программы переписываются.

Устаревшее программное обеспечение не может продолжать настройку с использованием новейших технологий, доступных на рынке. По мере устаревания оборудования обновление программного обеспечения становится головной болью. Даже если программное обеспечение стареет со временем, его функциональные возможности – нет.

Например, изначально Unix разрабатывался на ассемблере. Когда появился язык C, Unix был переработан в C, потому что работать на языке ассемблера было сложно.

Помимо этого, иногда программисты замечают, что лишь немногие части программного обеспечения нуждаются в большем обслуживании, чем другие, и им также требуется реинжиниринг.

Процесс реинжиниринга

• Решите, что для реинжиниринга. Это целое программное обеспечение или его часть?
• Выполните Обратный инжиниринг, чтобы получить спецификации существующего программного обеспечения.
• Программа реструктуризации, если требуется. Например, изменение функционально-ориентированных программ в объектно-ориентированные программы.
• Перестройте данные по мере необходимости.
• Примените передовые инженерные концепции, чтобы получить переработанное программное обеспечение.

Есть несколько важных терминов, используемых в реинжиниринге программного обеспечения

Обратный инжиниринг

Это процесс достижения спецификации системы путем тщательного анализа, понимания существующей системы. Этот процесс можно рассматривать как модель обратного SDLC, т.е. мы пытаемся получить более высокий уровень абстракции, анализируя более низкие уровни абстракции.

В существующей системе ранее реализован дизайн, о котором мы ничего не знаем. Затем дизайнеры занимаются реверс-инжинирингом, просматривая код и пытаясь получить дизайн. С дизайном в руках, они пытаются заключить спецификации. Таким образом, происходит обратный переход от кода к спецификации системы.

Реструктуризация программы

Это процесс перестройки и перестройки существующего программного обеспечения. Это все о реорганизации исходного кода, либо на одном языке программирования, либо с одного языка программирования на другой. Реструктуризация может иметь либо реструктуризацию исходного кода и реструктуризации данных, либо и то и другое.

Реструктуризация не влияет на функциональность программного обеспечения, но повышает надежность и ремонтопригодность. Компоненты программы, которые очень часто вызывают ошибки, могут быть изменены или обновлены с помощью реструктуризации.

Надежность программного обеспечения на устаревшей аппаратной платформе может быть удалена путем реструктуризации.

Форвард Инжиниринг

Форвард-инжиниринг – это процесс получения желаемого программного обеспечения из имеющихся в наличии спецификаций, которые были получены с помощью реверс-инжиниринга. Предполагается, что в прошлом уже проводилась разработка программного обеспечения.

Форвард-инжиниринг такой же, как процесс разработки программного обеспечения, только с одним отличием – он выполняется всегда после реверс-инжиниринга.

Повторное использование компонентов

Компонент является частью программного программного кода, который выполняет самостоятельную задачу в системе. Это может быть небольшой модуль или сама подсистема.

пример

Процедуры входа в систему, используемые в Интернете, могут рассматриваться как компоненты, система печати в программном обеспечении может рассматриваться как компонент программного обеспечения.

Компоненты имеют высокую функциональность и меньшую скорость соединения, то есть они работают независимо и могут выполнять задачи независимо от других модулей.

В ООП объекты разрабатываются с особой спецификой и имеют меньше шансов для использования в каком-либо другом программном обеспечении.

В модульном программировании модули кодируются для выполнения конкретных задач, которые можно использовать в ряде других программ.

Существует совершенно новая вертикаль, которая основана на повторном использовании программного компонента и известна как компонентная разработка программного обеспечения (CBSE).

Повторное использование может быть сделано на разных уровнях

• Уровень приложения – когда все приложение используется в качестве подсистемы нового программного обеспечения.

• Уровень компонента – где используется подсистема приложения.

• Уровень модулей – где функциональные модули используются повторно.

  Программные компоненты предоставляют интерфейсы, которые можно использовать для установления связи между различными компонентами.

Уровень приложения – когда все приложение используется в качестве подсистемы нового программного обеспечения.

Уровень компонента – где используется подсистема приложения.

Уровень модулей – где функциональные модули используются повторно.

Программные компоненты предоставляют интерфейсы, которые можно использовать для установления связи между различными компонентами.

Процесс повторного использования

Могут быть использованы два вида методов: либо при сохранении одинаковых требований, либо при корректировке компонентов, либо при сохранении одинаковых компонентов и при изменении требований.

• Спецификация требований – указываются функциональные и нефункциональные требования, которым должен соответствовать программный продукт, с помощью существующей системы, пользовательского ввода или того и другого.

• Проектирование – это также стандартный этап процесса SDLC, где требования определяются на языке программного обеспечения. Создана базовая архитектура системы в целом и ее подсистем.

• Укажите компоненты. Изучая дизайн программного обеспечения, разработчики разделяют всю систему на более мелкие компоненты или подсистемы. Один полный дизайн программного обеспечения превращается в набор огромного набора компонентов, работающих вместе.

• Поиск подходящих компонентов – хранилище компонентов программного обеспечения направляется разработчиками для поиска соответствующего компонента на основе функциональности и предполагаемых требований к программному обеспечению.

• Включите компоненты – Все соответствующие компоненты упакованы вместе, чтобы сформировать их как законченное программное обеспечение.

Спецификация требований – указываются функциональные и нефункциональные требования, которым должен соответствовать программный продукт, с помощью существующей системы, пользовательского ввода или того и другого.

Проектирование – это также стандартный этап процесса SDLC, где требования определяются на языке программного обеспечения. Создана базовая архитектура системы в целом и ее подсистем.

Укажите компоненты. Изучая дизайн программного обеспечения, разработчики разделяют всю систему на более мелкие компоненты или подсистемы. Один полный дизайн программного обеспечения превращается в набор огромного набора компонентов, работающих вместе.

Поиск подходящих компонентов – хранилище компонентов программного обеспечения направляется разработчиками для поиска соответствующего компонента на основе функциональности и предполагаемых требований к программному обеспечению.

Включите компоненты – Все соответствующие компоненты упакованы вместе, чтобы сформировать их как законченное программное обеспечение.

Обзор программных инструментов

CASE расшифровывается как компьютерное программное обеспечение. Это означает разработку и сопровождение программных проектов с помощью различных автоматизированных программных средств.

CASE Инструменты

Инструменты CASE – это набор программных прикладных программ, которые используются для автоматизации действий SDLC. Инструменты CASE используются менеджерами программных проектов, аналитиками и инженерами для разработки программных систем.

Существует целый ряд инструментов CASE для упрощения различных этапов жизненного цикла разработки программного обеспечения, таких как инструменты анализа, инструменты проектирования, инструменты управления проектами, инструменты управления базами данных, инструменты документирования.

Использование инструментов CASE ускоряет разработку проекта для получения желаемого результата и помогает выявить недостатки, прежде чем перейти к следующему этапу разработки программного обеспечения.

Компоненты CASE Tools

Инструменты CASE можно широко разделить на следующие части в зависимости от их использования на определенной стадии SDLC:

• Центральный репозиторий – инструментам CASE требуется центральный репозиторий, который может служить источником общей, интегрированной и согласованной информации. Центральный репозиторий – это центральное место хранения, где хранятся спецификации продукта, документы с требованиями, соответствующие отчеты и диаграммы, другая полезная информация об управлении. Центральный репозиторий также служит словарем данных.

  

• Инструменты верхнего регистра. Инструменты верхнего регистра используются на этапах планирования, анализа и проектирования SDLC.

• Инструменты нижнего регистра – Инструменты нижнего регистра используются при внедрении, тестировании и обслуживании.

• Интегрированные инструменты Case – Интегрированные инструменты CASE полезны на всех этапах SDLC, от сбора требований до тестирования и документации.

Центральный репозиторий – инструментам CASE требуется центральный репозиторий, который может служить источником общей, интегрированной и согласованной информации. Центральный репозиторий – это центральное место хранения, где хранятся спецификации продукта, документы с требованиями, соответствующие отчеты и диаграммы, другая полезная информация об управлении. Центральный репозиторий также служит словарем данных.

Инструменты верхнего регистра. Инструменты верхнего регистра используются на этапах планирования, анализа и проектирования SDLC.

Инструменты нижнего регистра – Инструменты нижнего регистра используются при внедрении, тестировании и обслуживании.

Интегрированные инструменты Case – Интегрированные инструменты CASE полезны на всех этапах SDLC, от сбора требований до тестирования и документации.

Инструменты CASE могут быть сгруппированы, если они имеют схожую функциональность, процессы и возможность интеграции с другими инструментами.

Область применения инструментов Case

Сфера применения инструментов CASE распространяется на весь SDLC.

Типы инструментов

Теперь мы кратко рассмотрим различные инструменты CASE

Инструменты диаграммы

Эти инструменты используются для представления компонентов системы, данных и потока управления между различными компонентами программного обеспечения и структурой системы в графической форме. Например, инструмент Flow Chart Maker для создания современных блок-схем.

Инструменты моделирования процессов

Моделирование процесса – это метод для создания модели процесса программного обеспечения, которая используется для разработки программного обеспечения. Инструменты моделирования процессов помогают менеджерам выбрать модель процесса или изменить ее в соответствии с требованиями программного продукта. Например, EPF Composer

Инструменты управления проектами

Эти инструменты используются для планирования проекта, оценки затрат и усилий, планирования проекта и планирования ресурсов. Менеджеры должны строго соблюдать выполнение проекта с каждым упомянутым этапом в управлении программным проектом. Инструменты управления проектами помогают хранить и обмениваться информацией о проектах в реальном времени по всей организации. Например, Creative Pro Office, Trac Project, Basecamp.

Инструменты документации

Документация в программном проекте начинается до процесса разработки программного обеспечения, проходит через все фазы SDLC и после завершения проекта.

Инструменты документирования генерируют документы для технических пользователей и конечных пользователей. Технические пользователи – это, в основном, собственные специалисты команды разработчиков, которые ссылаются на системное руководство, справочное руководство, учебное руководство, руководства по установке и т. Д. Документы конечного пользователя описывают функционирование и инструкции системы, такие как руководство пользователя. Например, Doxygen, DrExplain, Adobe RoboHelp для документации.

Инструменты анализа

Эти инструменты помогают собирать требования, автоматически проверять любые несоответствия, неточности в схемах, избыточность данных или ошибочные пропуски. Например, Accept 360, Accommodationpa, CaseComplete для анализа потребностей, Visible Analyst для общего анализа.

Инструменты дизайна

Эти инструменты помогают разработчикам программного обеспечения спроектировать блочную структуру программного обеспечения, которая в дальнейшем может быть разбита на более мелкие модули с использованием методов уточнения. Эти инструменты обеспечивают детализацию каждого модуля и взаимосвязи между модулями. Например, Animated Software Design

Инструменты управления конфигурацией

Экземпляр программного обеспечения выпущен под одной версией. Инструменты управления конфигурацией имеют дело с –

• Управление версиями и ревизиями
• Управление базовой конфигурацией
• Управление изменениями

Инструменты CASE помогают в этом благодаря автоматическому отслеживанию, управлению версиями и управлению выпусками. Например, Fossil, Git, Accu REV.

Инструменты управления изменениями

Эти инструменты рассматриваются как часть инструментов управления конфигурацией. Они касаются изменений, внесенных в программное обеспечение после того, как его базовый уровень исправлен или когда программное обеспечение впервые выпущено. Инструменты CASE автоматизируют отслеживание изменений, управление файлами, управление кодом и многое другое. Это также помогает в реализации политики изменений в организации.

Инструменты программирования

Эти инструменты состоят из сред программирования, таких как IDE (интегрированная среда разработки), встроенных библиотек модулей и инструментов моделирования. Эти инструменты предоставляют всестороннюю помощь в создании программного продукта и включают функции для моделирования и тестирования. Например, Cscope для поиска кода в C, Eclipse.

Инструменты для прототипирования

Программный прототип представляет собой смоделированную версию предполагаемого программного продукта. Прототип обеспечивает первоначальный внешний вид продукта и имитирует несколько аспектов реального продукта.

Инструменты для создания прототипов CASE в основном поставляются с графическими библиотеками. Они могут создавать аппаратно-независимые пользовательские интерфейсы и дизайн. Эти инструменты помогают нам создавать быстрые прототипы на основе существующей информации. Кроме того, они обеспечивают симуляцию программного прототипа. Например, композитор-прототип Серены, конструктор макетов.

Инструменты веб-разработки

Эти инструменты помогают в разработке веб-страниц со всеми смежными элементами, такими как формы, текст, сценарий, графика и так далее. Веб-инструменты также предоставляют предварительный просмотр того, что разрабатывается и как оно будет выглядеть после завершения. Например, Fontello, Adobe Edge Inspect, Foundation 3, Brackets.

Инструменты обеспечения качества

Обеспечение качества в организации программного обеспечения – это мониторинг процесса разработки и методов, принятых для разработки программного продукта, с целью обеспечения соответствия качества в соответствии со стандартами организации. Инструменты QA состоят из инструментов контроля конфигурации и изменений и инструментов тестирования программного обеспечения. Например, SoapTest, AppsWatch, JMeter.

Инструменты обслуживания

Обслуживание программного обеспечения включает в себя модификации программного продукта после его доставки. Методы автоматической регистрации и сообщения об ошибках, автоматическая генерация квитанции об ошибках и анализ первопричин – это лишь немногие инструменты CASE, которые помогают в организации программного обеспечения на этапе обслуживания SDLC. Например, Bugzilla для отслеживания дефектов, HP Quality Center.

Сравнительный анализ структур руководств пользователя программы по ЕСПД и IEEE Std 1063-2001 с учетом рекомендаций «манифеста Кагарлицкого». Показано, что обобщенная структура руководства пользователя, собранная согласно требованиям «устаревших» ГОСТов 19-й системы, существенно превосходит структуру руководства, рекомендуемую суперсовременным IEEE Std 1063-2001. Редакция от 23.01.2022.

Создан 11.02.2005 11:14:22

Когда умирает надежда, приходит отчаяние.

Мудрая латинская поговорка

Как писать руководство пользователя программы? Создать древовидную иерархическую структуру разделов руководства пользователя и заполнить ее разделы содержимым. И вся любовь.

Где взять структуру разделов руководства пользователя? С руководствами на изделия (руководство по эксплуатации по ГОСТ 2.601-95) и на автоматизированные системы (руководство пользователя по РД 50-34.698-90) все более или менее ясно. А вот сам документ «Руководство пользователя» программы в ГОСТах 19-й системы отсутствует как класс.

Каким содержимым наполнять разделы руководства пользователя? Как быть? Главное — не отчаиваться.

Цели и задачи статьи

Цель, как всегда, — попытаться облегчить жизнь разработчику руководства пользователя программы.

Задачи:

• проанализировать существующие стандарты и рекомендации по разработке эксплуатационной программной документации, выявить достоинства и недостатки каждого документа по отдельности;
• вывести некую обобщенную структуру руководства пользователя по ГОСТам 19-й системы из имеющегося набора эксплуатационных программных документов;
• сравнить ее со структурой, рекомендованной IEEE Std 1063-2001;
• а все прочие задачи перекочевали во 2-ю часть статьи…

Примечание от 10.07.2014 г. — В феврале 2005 года был проведен, пожалуй, даже не сравнительный анализ, а скорее сравнительные испытания, показавшие неоспоримое превосходство ГОСТов 19-й системы стандартов над буржуйскими и практически полную несостоятельность последних.

Вопросы, на которые должно дать ответы руководство пользователя

Подарите ребенку незнакомую ему электронную игрушку. Перечень вопросов будет примерно таким (если сразу же не разломает):

• а что это;
• а что им можно делать;
• а что им нельзя делать (у особо одаренных);
• а что надо, чтобы оно работало;
• а что там у него внутри (у детей, склонных к глубокому анализу);
• а как его настроить, чтобы работало так, как я хочу;
• а как его проверить, работает оно или не работает;
• а что и где надо нажимать;
• а что оно еще может делать;
• а что оно говорит, если что-то не так нажимаешь?

Последовательность вопросов может оказаться самой разнообразной. И документ под названием «Руководство пользователя» должен дать ответы на все поставленные вопросы. Все просто. Не так страшен черт, как его малюют.

Руководство пользователя: четыре источника и четыре составных части

Располагаем документами:

• «метагайдом» Кагарлицкого;
• суперсовременным IEEE Std 1063-2001, «IEEE Standard for Software User Documentation»;
• классическими отечественными ГОСТами 19-й системы, включающим в себя перечисленные ниже документы «описательного» характера:
  • ГОСТ 19.402-78 ЕСПД. Описание программы;
  • ГОСТ 19.502-78 ЕСПД. Описание применения. Требования к содержанию и оформлению;
  • ГОСТ 19.503-79 ЕСПД. Руководство системного программиста. Требования к содержанию и оформлению;
  • ГОСТ 19.504-79 ЕСПД. Руководство программиста. Требования к содержанию и оформлению;
  • ГОСТ 19.505-79 ЕСПД. Руководство оператора. Требования к содержанию и оформлению.

Крайняя четверка из перечня — эксплуатационные программные документы.

Возможно, существуют и иные документы, но автору, основательно порывшемуся в рунетовской свалке, ничего более подходящего заполучить пока не удалось. Яндекс обнаружил в своих недрах еще одну страничку с названием «Как сделать хорошее руководство пользователя», автор которой именует себя на американЬский манер (типа John P. Morgan). Двухстраничное «наставление» с радостными возгласами было немедленно отправлено в корзину.

Манифест Кагарлицкого

Метагайд Кагарлицкого показался многообещающим. Только автор настоящей статьи не уразумел, что есть «метагайд», поэтому позволил себе наглось обозвать метагайд «манифестом». И не погрешил против истины (но это открылось позже — ниже).

(цитаты из манифеста Кагарлицкого)

Мы стремились свести в единую систему всю совокупность типовых требований, которые должны, с нашей точки зрения, предъявляться к технической документации: руководствам, справочникам и т.д. При этом мы основывались на стандартах(!!!) ГОСТ, стандартах компании Microsoft, опыте наших сотрудников и других разработчиков технической документации.

Начало обнадеживающее.

В состав технической документации входят две стержневые части, которые мы будем называть соответственно руководством пользователя и справочником пользователя, или коротко: руководством и справочником (по аналогии с английскими словосочетаниями User’s Guide и User’s Reference). Они могут быть оформлены в виде отдельных документов (для крупных программных продуктов), а могут, напротив, существовать в интегрированном виде. Между ними даже может не быть четкой границы: единый текст способен совмещать в себе черты руководства и черты справочника.

Что-то не так. Автору статьи всегда «казалось», что термин техническая документация трактуется более широко, значительно шире, чем эксплуатационная (программная) документация.

Руководство и справочник — это не столько части документации, сколько понятия, которые воплощают собой два подхода к описанию программного продукта.

По-понятиям так по-понятиям, вот только пацаны начинают нервничать. Руководство не есть понятие, а есть вид документа.

Наша задача не столько в том, чтобы рассказать, как выглядит документация, сколько в том, чтобы дать конкретные рекомендации по ее разработке. Всем известно, какие проблемы возникают в процессе написания связного текста большого объема — как приступить к работе, с чего начать, как расположить материал. Этот подход побуждает видеть в провозглашаемых нами нормах не хаотический их перечень, а иерархическую систему…

На небосклоне засияла звезда по имени Надежда — сейчас уважаемый г-н Кагарлицкий выдаст нам, лишенцам, всеобъемлющую иерархическую структуру руководства пользователя всех времен и народов. Ну же?!

Прежде чем приступить к разработке документации как таковой, необходимо наметить и спланировать общую логику изложения. Может показаться, что жанр технической документации крайне прост: ведь его задачей является «всего лишь» сообщение пользователю некоторых сведений о продукте. Однако если Вы будете исходить из этого в своей работе, Вы будете создавать образцы документации, вовсе непригодные или едва пригодные для практического использования, — даже если все необходимые сведения будут там содержаться. Ваша задача состоит в том, чтобы провести пользователя через перевал, то есть найти в горной цепи место, которое хотя бы и с трудом, но все-таки проходимо для Вашего «подопечного».

Жаль… А так все хорошо начиналось. Со «стандартов ГОСТ» — «стандартов ГОсударственных СТандартов» — простим г-на Кагарлицкого за тавтологию. Только вот решения первой задачи, поставленной автором настоящей статьи, в семидесятидвухстраничном манифесте (Arial’ом 12pt) нет. Уважаемый автор манифеста лишь поставил нам задачу. Что ж, нет пророка в своем отечестве. Может, есть пророк в отечестве буржуйском?

Руководство пользователя по IEEE Std 1063-2001 «IEEE Standard for Software User Documentation»

Забугорный «пророческий» документ IEEE Std 1063-2001 (IEEE в простонародье — «ай-яй-яй») в подразделе 1.2 (Puprose) содержит такую строчку:

This revision provides requirements for the structure, information content, and format of both printed and electronic documentation.

В авторском понимании назначение (намерение, цель, замысел, стремление) документа IEEE Std 1063-2001 состоит в «обеспечении требований к структуре, информационному наполнению, форматированию (оформлению) как электронной, так и печатной пользовательской документации по программным средствам». Что ж, подходяще. Какую же структуру руководства пользователя предлагает IEEE Std 1063-2001?

Структура руководства пользователя по IEEE Std 1063-2001

Опциональная типовая структура руководства пользователя содержится в таблице из раздела Structure of software user documentation документа IEEE Std 1063-2001:

Component	See subclause	Required?
Identification data (package label/title page)	4.3	Yes
Table of contents	5.7.1	Yes, in documents of more than eight pages after identification data
List of illustrations	5.7.2	Optional
Introduction	3.2	Yes
Information for use of the documentation	4.4	Yes
Concept of operations	4.5	Yes
Procedures	4.6, 4.7	Yes (instructional mode)
Information on software commands	4.8	Yes (reference mode)
Error messages and problem resolution	4.9	Yes
Glossary	4.10	Yes, if documentation contains unfamiliar terms
Related information sources	4.11	Optional
Navigational features	5.8	Yes
Index	5.7.3	Yes, if documents of more than 40 pages
Search capability	5.7.4	Yes, in electronic documents

For purposes of this standard, the following non-mandatory nomenclature is used for the structural parts of software user documentation. A printed document is structured into logical units called chapters, subdivided into topics, which may be subdivided into subtopics, and printed on physical units called pages.

Здорово. IEEE Std 1063-2001 предлагает «все взять и поделить» — разбить разделы руководства на главы, топики, субтопики и т.д. И наступит всем счастье.

Практический интерес (в рамках задач статьи) представляют выделенные разделы. Посмотрим, как дробить разделы руководства пользователя на более мелкие структурные единицы и каким содержимым предполагается заполнять указанные структурные единицы.

Introduction

Какие сведения должны быть изложены в разделе Introduction согласно IEEE Std 1063-2001? А вот какие

The introduction shall describe the intended audience, scope, and purpose for the document and include a brief overview of the software purpose, functions, and operating environment.

Что ж, замечательно. Структура подразделов Introduction начинает как-то вырисовываться.

Information for use of the documentation

The documentation shall include information on how it is to be used (for example, help on help), and an explanation of the notation (a description of formats and conventions-see 5.8). At least one document in a document set shall identify all documents in the set by title and intended use, including recommendations on which members of the audience should consult which sections of the documentation. In document sets comprising many volumes or products, this information may be provided in a separate «road map» or guide to the document set. Documentation may include identification and discussion of notable changes from the previous version of the document set and the software.

Весьма полезный раздел (в контексте разработки руководства пользователя). Руководство по руководству.

Concept of operations

Documentation shall explain the conceptual background for use of the software, using such methods as a visual or verbal overview of the process or workflow; or the theory, rationale, algorithms, or general concept of operation. Explanations of the concept of operation should be adapted to the expected familiarity of the users with any specialized terminology for user tasks and software functions. Documentation shall relate each documented function to the overall process or tasks. Conceptual information may be presented in one section or immediately preceding each applicable procedure.

Концептуальная информация безусловно важна.

Procedures

Task-oriented instructional mode documentation shall include instructions for routine activities that are applied to several functions:

— Software installation and de-installation, if performed by the user

— Orientation to use of the features of the graphical user interface (see 5.6)

— Access, or log-on and sign-off the software

— Navigation through the software to access and to exit from functions

— Data operations (enter, save, read, print, update, and delete)

— Methods of canceling, interrupting, and restarting operations

These common procedures should be presented once to avoid redundancy when they are used in more complex functions.

И пошла конктерика. Молодцы, буржуи!

Information on software commands

Documentation shall explain the formats and procedures for user-entered software commands, including required parameters, optional parameters, default options, order of commands, and syntax. Documentation may be provided on the development and maintenance of macros and scripts. Reference mode documentation shall contain a reference listing of all reserved words or commands. Examples should illustrate the use of commands. Documentation shall explain how to interrupt and undo operation during execution of a command and how to restart it, if possible. Documentation shall describe how to recognize that the command has successfully executed or abnormally terminated.

Error messages and problem resolution

Documentation should address all known problems in using the software in sufficient detail such that the users can either recover from the problems themselves or clearly report the problem to technical support personnel. Reference mode documentation shall include each error message with an identification of the problem, probable cause, and corrective actions that the user should take. A quick reference card may address error messages by referring the user to more detailed reference documentation. The documentation on resolving problems shall also include contact information for reporting problems with software or its documentation and suggesting improvements.

Выводы по IEEE Std 1063-2001

Но счастье оказалось неполным… Структура разделов первого уровня руководства показана в таблице явно. А дальше — «милый мой, хороший, догадайся сам» («догадайся, мол, сама»). IEEE Std 1063-2001, конечно, «provides requirements for the structure», но не предлагает явной структуры руководства пользователя до рекомендованного ГОСТ 2.105 четвертого уровня вложенности.

Рекомендации типа «Documentation shall explain…», «Examples should illustrate…», «Documentation shall describe…» и им подобные, безусловно, проверены временем. В руководстве пользователя надо и объяснять, и иллюстрировать, и описывать — без всякого сомнения. Но все это и козе понятно, и в ГОСТах 19-й системы прописано.

Итак, вряд ли целесообразно разрабатывать руководства пользователя, основываясь исключительно на рекомендациях IEEE Std 1063-2001. Причины, как минимум, две:

• отсутствие в IEEE Std 1063-2001 четко регламентированной структуры руководства пользователя;
• «поверхностность» IEEE Std 1063-2001, отсутствие «широты охвата» и «глубины проработки».

Отсутствие четко регламентированной структуры руководства пользователя даст возможность заказчику ТРЕТИРОВАТЬ разработчика, см. хотя бы Страшная правда о техническом задании. Бедняга-разработчик будет вынужден, по указке заказчика, изо дня в день менять местами разделы руководства пользователя (гарантированный минимум, полученный опытным путем).

Отсутствие четко регламентированной структуры оборачивается хаосом, как только уровень вложения заголовков снижается до второго-третьего. Пользователь просто зашвырнет такое руководство куда подальше и назовет его автора кретином.

По мнению автора, рекомендации IEEE Std 1063-2001, разработанного при участии сотни забугорных спецов, весьма и весьма поверхностны. Не сможет разработчик, работая по IEEE Std 1063-2001, охватить максимум «характеристик», свойственных программе. В IEEE Std 1063-2001 многие из них попросту не прописаны. Отсутствуют «широта охвата» и «глубина проработки», свойственные отечественным документам.

В крайнем разделе настоящей статьи приведена таблица соответствия ГОСТ 19 и IEEE Std 1063-2001, которую автор статьи начал было составлять, затем бросил и проверять не стал. А выводы пусть каждый сделает сам для себя. И, возможно, в чем-то поправит автора.

Пользовательские документы по ГОСТ 19 (ЕСПД)

В отличие от суперсовременного буржуйского IEEE Std 1063-2001, древние, многими ругаемые отечественные стандарты 19-й системы (Единая система программной документации — ЕСПД) содержат не пространные рассуждения о том, что и как должно разъяснять, иллюстрировать и описывать руководство пользователя, а конкретные требования к структуре и содержанию пользовательских (эксплуатационных) документов.

Перечень ГОСТов 19 «описательного» характера, на основе которых можно, не мудрствуя лукаво, сформировать четкую структуру разделов каждого из «описательных» документов, приведен в разделе Источники. Основной прием — детализация — подробно описан в статье «Как писать техническое задание?!». Далее — сформированные «детализацией» структуры разделов документов согласно ГОСТам из перечня.

Структура разделов описания программы по ГОСТ 19.402-78

Структура разделов описания применения по ГОСТ 19.502-78

Структура разделов руководства системного программиста по ГОСТ 19.503-79

Структура разделов руководства программиста по ГОСТ 19.504-79

Структура разделов руководства оператора по ГОСТ 19.505-79

Выводы по ГОСТам 19.ххх

Ни ГОСТ 19.505-79, ни ГОСТ 19.504-79, ни ГОСТ 19.503-79, взятые по одельности, не могут похвастаться достаточной полнотой структуры.

Зато структуры «описательных» документов ГОСТ 19 обладают как полностью идентичными (по тексту названий), так и схожими по тексту названий разделами и подразделами. К идентичным разделам относятся, к примеру, разделы «Аннотация», имеющие место во всех документах согласно ГОСТ 19.105-78. К схожим (фактически — идентичным) можно отнести подразделы «Назначение программы» и «Сведения о назначении программы».

А почему не попытаться объединить все «описательные» документы? Объединить идентичные и схожие разделы документов, выделить специфические разделы? Быть может, удастся избавиться от неполноты ГОСТ 19.505-79, ГОСТ 19.504-79 и ГОСТ 19.503-79 и получить обобщенную структуру «описательного» документа и обозвать сам документ руководством пользователя программы?

ГОСТы 19.ххх допускают «вводить дополнительные разделы или объединять отдельные разделы», а также «вводить новые». Согласно ГОСТ 19.101-77 «Допускается объединять отдельные виды эксплуатационных документов (за исключением ведомости эксплуатационных документов и формуляра). Необходимость объединения этих документов указывается в техническом задании. Объединенному документу присваивают наименование и обозначение одного из объединяемых документов. В объединенных документах должны быть приведены сведения, которые необходимо включать в каждый объединяемый документ [из 2.6 ГОСТ 19.101-77]»

Сказано — сделано. Только мы нарушим ГОСТы и создадим объединенный документ под названием «Руководство пользователя».

Обобщенная структура руководства пользователя по ГОСТам 19-й системы

Путем слияния структур «описательных» документов ГОСТов 19-й системы в единую структуру, удаления «лишних» одноименных разделов, слияния схожих разделов сформирована общая структура руководства пользователя программы. В табличке сведены и «*» отмечены разделы, присутствующие в каждом отдельном документе.

ГОСТ 19.ххх — обобщенная структура разделов руководства	ГОСТ 19.402-78	ГОСТ 19.502-78	ГОСТ 19.503-79	ГОСТ 19.504-79	ГОСТ 19.505-79
Аннотация	*	*	*	*	*
•Назначение документа	*	*	*	*	*
•Краткое изложение основной части документа	*	*	*	*	*
Общие сведения о программе	*		*
•Обозначение и наименование программы	*			*
•Языки программирования, на которых написана программа	*
•Сведения о назначении программы	*	*	*	*	*
••Информация, достаточная для понимания функций программы и ее эксплуатации					*
•••Возможности программы		*
•••Классы решаемых задач	*
••••Описание задач		*
••••Методы решения задач		*
•••Функции, выполняемые программой			*	*
••Описание основных характеристик и особенностей программы		*		*
•••Временные характеристики				*
•••Режим работы				*
•••Средства контроля правильности выполнения и самовосстанавливаемости программы				*
••Ограничения области применения программы		*
•••Сведения о функциональных ограничениях на применение	*
Условия применения программы		*		*	*
•Условия, необходимые для выполнения программы		*	*		*
••Сведения о технических и программных средствах, обеспечивающих выполнение программы			*
•••Требования к техническим средствам	*	*
••••Типы ЭВМ, устройства, используемые при работе программы	*
••••Объем оперативной памяти				*
••••Минимальный и (или) максимальный состав аппаратурных и программных средств					*
••••Требования к составу и параметрам периферийных устройств				*
•••Программное обеспечение, необходимое для функционирование программы	*
••••Требования к программному обеспечению				*
••••Требования к другим программам		*
••••Требования и условия организационного, технического и технологического характера		*
Описание логической структуры	*
•Алгоритм программы	*
•Используемые методы	*
•Сведения о структуре программы	*		*
•Сведения о составных частях программы			*
•Описание функций составных частей	*
•Сведения о связях между составными частями программы	*		*
•Сведения о связях с другими программами	*		*
Сведения о входных и выходных данных		*		*
•Общие характеристики входной и выходной информации		*
•Сведения о входных данных	*	*
••Характер, организация и предварительная подготовка входных данных	*			*
•Сведения о выходных данных	*	*
••Характер и организация выходных данных	*			*
••Формат, описание и способ кодирования выходных данных	*
•Описание кодирования информации				*
Настройка программы			*
•Описание действий по настройке программы			*
••Настройка на состав технических средств			*
••Выбор функций			*
••Поясняющие примеры			*
Проверка программы			*
•Описание способов проверки работоспособности программы			*
••Контрольные примеры			*
••Методы прогона			*
••Результаты			*
Выполнение программы					*
•Загрузка программы •Способ вызова программы с соответствующего носителя данных •Описание процедур вызова программы	*			*	*
•Запуск программы					*
•Входные точки в программу*	*
•Способы передачи управления и параметров данных				*
•Выполнение программы					*
••Описание выполняемой функции 1					*
••Формат и возможные варианты команд для выполнения функции 1					*
••Ответы программы на команды выполнения функции 1					*
•Завершение выполнения программы					*
Дополнительные возможности			*
•Описание дополнительных функциональных возможностей программы			*
•Описание применения дополнительных функциональных возможностей программы			*
Сообщения программы			*	*	*
•Тексты сообщений, выдаваемых в ходе (настройки, проверки, выполнения) программы			*	*	*
••Описание содержания			*	*	*
••Описание действий, которые необходимо предпринять по этим сообщениям			*	*	*

Выводы по обобщенной структуре руководства пользователя по ГОСТ 19.ххх

Обобщенная структура руководства пользователя по ГОСТ 19.ххх явно не страдает, как IEEE Std 1063-2001, отсутствием широты охвата. Избыток, как известно, рождает качество. Перечислено все, чем может характеризоваться программа. Отдельные подразделы могут показаться даже излишними, к примеру, подраздел «Языки программирования, на которых написана программа».

Казалось бы, какое дело пользователю, на каком языке был написан исходный текст программы? С другой стороны, может «…это кому-нибудь нужно? Значит — это необходимо…». Ведь хочется при покупке буржуйского телевизора заполучить и принципиальную схему на него. Самсунги и соньки тоже выходят из строя. А вдруг неисправность пустяковая и устранить ее представляется возможным в домашних условиях, без поездки в сервисный центр?

В то же время, при всей широте охвата, в явном виде отсутствуют:

• Software installation and de-installation, if performed by the user;
• Orientation to use of the features of the graphical user interface;
• Access, or log-on and sign-off the software;
• Navigation through the software to access and to exit from functions и многое другое.

Автору удалось разбросать кое-что в разделе Таблица соответствия ГОСТ 19.ххх и IEEE Std 1063-2001, но времени «наморщить ум» всегда не хватает, руководство пользователя, как всегда, должно было быть готово еще на прошлой неделе.

Показать связи разделов обобщенного руководства пользователя с разделами ГОСТ 19.201-78 ЕСПД. Техническое задание, требования к содержанию и оформлению автор поленился, поскольку указанные связи очевидны.

Выводы по источникам

Итак, если первые три задачи в целом решены, крайняя задача осталась нерешенной.

Автор манифеста более склонен к рекомендациям по подбору слов* и построению предложений, IEEE Std 1063-2001, в лучшем случае, приводит требования к структуре руководства пользователя, но не дает особой конкретики, в ГОСТ 19.ххх не прописаны процедуры заполнения содержимым разделов руководства. Может, организовать эдакую смесь французского с нижегородским? Использовать все четыре источника в качестве четырех составных частей?

* Нынче в моде буржуйское понятие — т.н. контролируемый язык. Среди представителей «просвещенной русской интеллигенции» наибольшей популярностью пользуется отечественный аналог в глагольной форме повелительного наклонения — фильтруй базар!

Смесь французского с нижегородским

Почему бы нет? Взять лучшее из ГОСТов 19-й системы, — обобщенную структуру руководства пользователя, добавить к ней немногочисленные толковые рекомендации из IEEE Std 1063-2001 и разбавить неисчерпаемой стилистической культурой и ресурсами языка из манифеста Кагарлицкого? Придать смеси стройный строгий вид, сформировать очередной учебно-тренировочный документ с подробными комментариями? А что делать, если ни один из перечисленных выше источников и составных частей в отдельности не способны дать ответы на все поставленные вопросы?

Таблица соответствия ГОСТ 19 и IEEE Std 1063-2001

ГОСТ 19.ххх	IEEE Std 1063-2001
Аннотация	Introduction
	The introduction shall describe the intended audience, scope, and purpose for the document and include a brief overview of the software purpose, functions, and operating environment
•Назначение документа	purpose for the document (Introduction)
•Краткое изложение основной части документа	scope (Introduction)
Общие сведения о программе
•Обозначение и наименование программы	аналогичный подраздел отсутствует
•Языки программирования, на которых написана программа	то же
•Сведения о назначении программы	brief overview of the software purpose (Introduction)
••Информация, достаточная для понимания функций программы и ее эксплуатации	аналогичный подраздел отсутствует
•••Возможности программы	то же
•••Классы решаемых задач	»
••••Описание задач	»
••••Методы решения задач	Documentation shall relate each documented function to the overall process or tasks
•••Функции, выполняемые программой	brief overview of the software … functions (Introduction)
••Описание основных характеристик и особенностей программы	аналогичный подраздел отсутствует
•••Временные характеристики	то же
•••Режим работы	»
•••Средства контроля правильности выполнения и самовосстанавливаемости программы	»
••Ограничения области применения программы	»
•••Сведения о функциональных ограничениях на применение	»
Условия применения программы	If different versions of the software are available for different operating environments, the title page should specify the applicable operating environment(s), including version(s) of hardware, communications, and operating system(s) (4.3. Content of identification data)
•Условия, необходимые для выполнения программы	аналогичный подраздел отсутствует
••Сведения о технических и программных средствах, обеспечивающих выполнение программы	Documentation for the hardware and software environment (4.11 Information on related information sources)
•••Требования к техническим средствам	аналогичный подраздел отсутствует
••••Типы ЭВМ, устройств, используемые при работе программы	то же
••••Объем оперативной памяти	»
••••Минимальный и (или) максимальный состав аппаратурных и программных средств	»
••••Требования к составу и параметрам периферийных устройств	»
•••Программное обеспечение, необходимое для функционирование программы	brief overview of the … operating environment (Introduction)
••••Требования к программному обеспечению	аналогичный подраздел отсутствует
••••Требования к другим программам	то же
•••Требования и условия организационного, технического и технологического характера	»
Описание логической структуры
•Алгоритм программы	algorithms (4.5 Concept of operations)
•Используемые методы	using such methods as a visual or verbal overview of the process or workflow (4.5 Concept of operations)
•Сведения о структуре программы	аналогичный подраздел отсутствует
•Сведения о составных частях программы	то же
•Описание функций составных частей	»
•Сведения о связях между составными частями программы	»
•Сведения о связях с другими программами	»
Сведения о входных и выходных данных
•Общие характеристики входной и выходной информации	аналогичный подраздел отсутствует
•Сведения о входных данных	то же
••Характер, организация и предварительная подготовка входных данных	»
•Сведения о выходных данных	»
••Характер и организация выходных данных	»
••Формат, описание и способ кодирования выходных данных	»
•Описание кодирования информации	»
Настройка программы	Identification of technical or administrative activities that must be done before starting the task (4.7 Information for procedures and tutorials)
•Описание действий по настройке программы	аналогичный подраздел отсутствует
••Настройка на состав технических средств	то же
••Выбор функций	»
••Поясняющие примеры	»
Проверка программы
•Описание способов проверки работоспособности программы	аналогичный подраздел отсутствует
••Контрольные примеры	Examples should illustrate the use of commands (4.8 Information on software commands)
••Методы прогона	аналогичный подраздел отсутствует
••Результаты	то же
Выполнение программы
•Загрузка программы •Способ вызова программы с соответствующего носителя данных •Описание процедур вызова программы	Software installation and de-installation, if performed by the user (4.6 Information for general use of the software)
•Запуск программы	аналогичный подраздел отсутствует
•Входные точки в программу*	Access, or log-on and sign-off the software (4.6 Information for general use of the software)
•Способы передачи управления и параметров данных	аналогичный подраздел отсутствует
•Выполнение программы	то же
••Описание выполняемой функции 1	A brief overview of the purpose of the procedure and definitions or explanations of necessary concepts not elsewhere included (4.7 Information for procedures and tutorials)
••Формат и возможные варианты команд для выполнения функции 1	Navigation through the software to access … functions (4.6 Information for general use of the software) Instructional steps shall be presented in the order of performance (4.7 Information for procedures and tutorials) Documentation shall explain how to interrupt and undo operation during execution of a command and how to restart it, if possible. Documentation shall explain the formats and procedures for user-entered software commands, including required parameters, optional parameters, default options, order of commands, and syntax (4.8 Information on software commands)
••Ответы программы на команды выполнения функции 1	Documentation shall describe how to recognize that the command has successfully executed or abnormally terminated (4.8 Information on software commands)
•Завершение выполнения программы	Navigation through the software … to exit from functions Methods of canceling, interrupting, and restarting operations (4.6 Information for general use of the software)
Дополнительные возможности
•Описание дополнительных функциональных возможностей программы	аналогичный подраздел отсутствует
•Описание применения дополнительных функциональных возможностей программы	то же
Сообщения программы	Relevant warnings, cautions, and notes that apply to the entire procedure (4.7 Information for procedures and tutorials)
•Тексты сообщений, выдаваемых в ходе (настройки, проверки, выполнения) программы	аналогичный подраздел отсутствует
••Описание содержания	то же
••Описание действий, которые необходимо предпринять по этим сообщениям	»

Документация на программное обеспечение — это документы, сопровождающие некоторое программное обеспечение (ПО) — программу или программный продукт. Эти документы описывают то, как работает программа и/или то, как её использовать.

Документирование — это важная часть в разработке программного обеспечения, но часто ей уделяется недостаточно внимания.

Процесс управления конфигурацией является процессом применения административных и технических процедур на всем протяжении ЖЦ ПС для определения состояния (базовой линии) программных объектов в системе, управления их изменениями и выпуском.

Данный процесс состоит из шести работ. Общее число задач по данным работам равно 6.

Источник: