Разработка программы и руководство ее реализацией

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

Разработка программы включает:

1) подготовку тестовых исходных данных;

2) написание текста программы на алгоритмическом языке;

3) перенос программ и данных на машинные носители компьютера;

4) отладку и тестирование программы.

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

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

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

ИИ в 2023 году: Руководство по выживанию для разработчиков ПО

Текст программы обязательно должен содержать подробные комментарии.

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

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

Контрольный пример

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

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

Выводы по работе

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

1) Какова была задача курсовой работы? Была ли она решена и достигнуты ли основные цели?

2) Какие новые знания и навыки были получены в процессе выполнения курсовой работы?

3) Где в дальнейшем могут быть применены полученные знания?

Разработка руководства пользователя (оператора)

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

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

Примерный план написания руководства пользователя в соответствии с ГОСТ 19.505-79 «Руководство оператора» /2/:

SCRUM — метод управления проектами. Обучающий мультик для вас и ваших сотрудников!

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

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

3. Каким образом осуществляется ввод данных.

4. Какая информация выводится на экран.

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

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

Структура пояснительной записки

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

2. Задание на курсовую работу

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

5. Математическая модель решения задачи

6. Описание и блок-схема решения задачи

7. Контрольный пример

8. Выводы по курсовой работе

9. Список использованных источников

Оформление пояснительной записки

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

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

При описании литературного источника необходимо указать /4,5/:

— фамилии и инициалы авторов,

— название книги или статьи,

При описании ссылки на сайт Интернета указать:

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

Защита курсовой работы

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

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

В ходе защиты курсовой работы оцениваются:

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

— знание среды программирования и основ алгоритмизации, степень владения материалом;

— аккуратность оформления пояснительной записки;

— соответствие материалов работы требованиям ГОСТ и правилам, установленным кафедрой;

— понимание использованных математических методов;

— изложение материалов в устном докладе.

Заключение

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

— делать постановку задачи;

— формировать математическую модель с использованием соответствующих математических методов;

— создавать программу в выбранной среде программирования в соответствии с основными этапами ее разработки;

— строить схемы алгоритма работы программы в соответствии с требованиями ГОСТ 19.701-90;

— анализировать результаты работы программы и делать выводы.

Список литературы

1. ГОСТ 19.701 – 90 (ИСО 5807 – 85) Схемы алгоритмов, программ, данных и систем. – М.: Издательство стандартов, 1991.

2. ГОСТ 19.505 – 79 Единая система программной документации. Руководство оператора. Требования к содержанию и оформлению. – М.: Издательство стандартов, 1988.

3. Методические указания по оформлению курсовых и дипломных работ. – Ижевск: Издательство ИжГТУ, 2008.

4. ГОСТ 7.1 – 2003 Библиографическое описание документа. Общие требования и правила составления. – М.: ИПК Издательство стандартов, 2004.

5. ГОСТ 7.82 – 2001 Библиографическая запись. Библиографическое описание электронных ресурсов. Общие требования и правила составления. – М.: Издательство стандартов, 2001.

6. Немнюгин С. А.. Turbo Pascal. Учебник. — С.-Пб.: Питер, 2001.

7. Немнюгин С.А. Turbo Pascal. Практикум [текст]. 2-е изд./ СПб.: Питер, 2007. — 268 с.: ил.

8. Осипов Д. Delphi. Профессиональное программирование. – М.: Символ-Плюс, 2006.

9. Попов И. Паскаль и Дельфи.Самоучитель. — С.-Пб.: Питер, 2003.

10. Редактор блок-схем [Электронный ресурс]: содержится информация о редакторе блок-схем, доступна ссылка для скачивания. – Электрон. дан. – режим доступа: http://alglib.sources.ru/aboutbls.php

11. Ускова О. Ф. Программирование на языке Pascal. – С.-Пб.: Питер, 2002.

Источник: megalektsii.ru

Стадии и этапы разработки программной документации

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

Разработка технического задания

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

Составление эскизного проекта

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

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

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

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

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

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

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

Внедрение технической документации

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

Источник: tehpis.ru

Разработка программы и руководство ее реализацией

Плюсы и минусы подхода

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

Каким проектам подходит

Каскадная модель – хороший вариант, если выполняются эти условия:

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

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

V-образная модель SDLC

V-образная модель – это своего рода другая версия каскада, но в её основе лежит контроль качества каждой фазы. Например, когда группа разработчиков собирает требования к проекту, QA-специалисты пишут приемочные тесты на основе этих сценариев. Точно так же на этапе проектирования системы создаются сценарии тестирования и так далее. После написания кода команда QA проверяет продукт на соответствие заранее написанным тестам (правая часть буквы «V»).

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

Каким проектам подходит

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

Модель эволюционного прототипирования

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

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

Каким проектам подходит

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

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

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

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

Плюсы	Минусы
Модель инкрементальной и итеративной разработки обеспечивает быструю и регулярную «доставку» работающего программного обеспечения клиентам.	Во время интеграции модуля могут возникнуть архитектурные проблемы.
Легче и дешевле учесть изменения в требованиях проекта.	Несмотря на некоторую гибкость, систему следует планировать с самого начала; в противном случае его нельзя разделить на модули.
Обратная связь от клиента на ранней стадии.	Участие клиентов может быть проблематичным.
Небольшие части программного обеспечения легче тестировать и исправлять.	Не всегда можно разбить систему на сегменты.
Экономия на издержках.	Хотя выпуск одного модуля дешевле, общие затраты на систему будут увеличиваться по мере интеграции новых модулей.

Каким проектам подходит

Модель будет эффективна в следующих случаях:

• Если система состоит из нескольких сегментов с чёткими требованиями.
• Ограниченные ресурсы на проекте или есть ограничения по времени выхода решения на рынок.
• Для стартапов, проходящих инвестиционные раунды.
• Масштабные проекты.
• Проекты, в основе которых новые технологии.
• Проекты, которые потребуется развивать после выпуска.

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

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

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

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

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

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

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

Каким проектам подходит

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

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

Microsoft, IBM и Tata Consultancy используют спиральную модель.

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

Вопреки распространённому мнению Agile не является ни структурой, ни методологией. Это философия с набором принципов, ориентированных на ускорение процесса разработки программного обеспечения, обеспечение 100% удовлетворённости клиентов и предоставление высококачественных решений в быстро меняющейся среде. Фактически, существует 12 принципов гибкой разработки, которые сводятся к следующим ценностям:

• Люди и взаимодействие важнее процессов и инструментов.
• Рабочее программное обеспечение над обширной документацией.
• Сотрудничество с клиентами вместо переговоров по контракту.
• Реагирование на изменения вместо следования плану.

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

Scrum

Скрам-проекты разбиты на спринты. Спринт – это небольшой объём работы, который необходимо выполнить в течение определённого периода времени. Обычно заказчику доставляется часть проекта, которая была завершена во время спринта (инкремент продукта, от англ. increment). Скрам подразумевает активное общение и сотрудничество между всеми участниками проекта. Наряду с ежедневными 15-минутными встречами разработчиков, есть также:

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

Сердце процессов Scrum – это backlog, своего рода список задач, которые необходимо сделать для завершения проекта. По мере того, как проект продвигается, и команда узнаёт о нём больше, они редактируют бэклог продукта, добавляя, удаляя и переупорядочивая его элементы. Тем не менее, нельзя сделать что-то, если этого нет в очереди продукта.

Но на самом ли деле всё так гладко и красиво в Agile? Посмотрим на его основные варианты использования, а также на плюсы и минусы.

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

Примеры использования

Большинство современных проектов требуют определённого уровня «маневренности», особенно когда:

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

В общем, Agile кажется именно тем, что нужно большинству проектов во времена неопределённости. Неудивительно, что более 70% компаний применяют Agile , включая Microsoft, IBM, Procter https://proglib.io/p/sdlc-modeli-kak-vybrat-pravilnyy-podhod-k-razrabotke-i-ne-zavalit-proekt-2021-05-15″ target=»_blank»]proglib.io[/mask_link]