Файл: Основы проектирования программ. Этапы создания программного обеспечения (Основы проектирования программ).pdf
Добавлен: 31.03.2023
Просмотров: 94
Скачиваний: 2
сложно планировать процессы, так как требования постоянно меняются;
редко используется для реализации больших проектов.
Рисунок 1.5 Гибкая модель
Скрам (Scrum)
Скрам – это гибкая модель разработки ПО, в которой делается акцент на качественном контроле процесса разработки.
Роли в методологии (Scrum Master, Product Owner, Team) позволяют четко распределить обязанности в процессе разработки. За успех Scrum в проекте отвечает Scrum Master и является связующим звеном между менеджментом и командой. За разработку продукта отвечает Product Owner, который также ставит задачи и принимает окончательные решения для команды.
Команда – это единое целое, в ней результаты оцениваются не по каждому отдельному участнику, а по тому, что получается в итоге у всех.
Спринты в данной методологии длятся от 1 до 4 недель. После каждого спринта команда предоставляет вариант законченного продукта.
Плюсы:
быстрая обратная связь от специалистов в разных сферах (дизайнеров, архитекторов, тестировщиков и пр.);
благодаря вовлеченности тестировщика в работу происходит быстрое добавление нового функционала и быстрый запуск продукта с минимальными функциями;
самостоятельная и самоорганизованная команда.
Минусы:
некоторые люди, знающие продукт, становятся незаменимыми, так как документация не предоставляется в процессе разработки;
невозможно спланировать точную дату завершения, так как всё уточняется по результатам предыдущего спринта;
заказчики не всегда могут понять суть данной методологии и необходимо потратить время на “ликбез”.
Рисунок 1.6 Скрам (Scrum)
1.4 Стандарты жизненного цикла ПО
Существует целый ряд стандартов, регламентирующих ЖЦ ПО, а в некоторых случаях и процессы разработки.
Среди наиболее известных стандартов можно выделить следующие:
ГОСТ 34.601-90 - распространяется на автоматизированные системы и устанавливает стадии и этапы их создания. Кроме того, в стандарте содержится описание содержания работ на каждом этапе. Стадии и этапы работы, закрепленные в стандарте, в большей степени соответствуют каскадной модели жизненного цикла.
ISO/IEC 12207:1995 - стандарт на процессы и организацию жизненного цикла. Распространяется на все виды заказного ПО. Стандарт не содержит описания фаз, стадий и этапов.
CustomDevelopmentMethod(методика Oracle) по разработке прикладных информационных систем - технологический материал, детализированный до уровня заготовок проектных документов, рассчитанных на использование в проектах с применением Oracle. Применяется CDM для классической модели ЖЦ (предусмотрены все работы/задачи и этапы), а также для технологий "быстрой разработки" (Fast Track) или "облегченного подхода", рекомендуемых в случае малых проектов.
RationalUnifiedProcess(RUP)предлагает итеративную модель разработки, включающую четыре фазы: начало, исследование, построение и внедрение. Каждая фаза может быть разбита на этапы (итерации), в результате которых выпускается версия для внутреннего или внешнего использования. Прохождение через четыре основные фазы называется циклом разработки, каждый цикл завершается генерацией версии системы. Если после этого работа над проектом не прекращается, то полученный продукт продолжает развиваться и снова минует те же фазы. Суть работы в рамках RUP - это создание и сопровождение моделей на базе UML.
MicrosoftSolutionFramework(MSF)сходна с RUP, так же включает четыре фазы: анализ, проектирование, разработка, стабилизация, является итерационной, предполагает использование объектно-ориентированного моделирования. MSF в сравнении с RUP в большей степени ориентирована на разработку бизнес- приложений.
ExtremeProgramming(XP).Экстремальное программирование (самая новая среди рассматриваемых методологий) сформировалось в 1996 году. В основе методологии командная работа, эффективная коммуникация между заказчиком и исполнителем в течение всего проекта по разработке ИС, а разработка ведется с использованием последовательно дорабатываемых прототипов.
2. Этапы создания программного обеспечения.
2.1 Общая характеристика этапов
В зависимости от размера программных проектов этапы разработки могут отличаться, в некоторых случаях это будут очень детализированные и бюрократичные этапы, а в некоторых — просто сформулированные в любом удобном для разработчиков виде.
Точно так же происходит и при разработке ПО, если проект крупный и очень важный, который возможно будет влиять на жизни людей или связан с огромными финансовыми рисками, все этапы разработки ПО будут соблюдаться, т.е. детально проработаны и даже будут добавляться новые этапы, микроэтапы и так далее.
Все это делается для того, чтобы не допустить появления ошибок и реализовать тот продукт, который действительно нужен.
Чем раньше будут обнаружены ошибки или выявлен неправильных подход в реализации того или иного действия, тем цена этих ошибок будет меньше. Иными словами, в зависимости от этапа обнаружения ошибки ее цена может меняться от 10 до 100 раз. Например, если на самом начальном этапе цена исправления ошибки будет равняться 100 рублей, то на этапе тестирования она может вылиться в 10000. Поэтому этапы разработки ПО очень важны, и разработчик должен их соблюдать и попытаться донести это видение до менеджеров, которым всегда нужен только результат. Так как они или отводят на это слишком мало времени или и вовсе не считают это необходимым, например, зачем при программировании вырабатывать какие-то требования или что-то там проектировать [8].
Основные этапы разработки ПО
Вот этапы, которые в большинстве случаев должны соблюдаться при разработке программного обеспечения:
Этап 1 – Определение проблемы
Этап 2 – Выработка требований
Этап 3 – Создание плана разработки
Этап 4 – Разработка архитектуры системы или высокоуровневое проектирование
Этап 5 – Детальное проектирование
Этап 6 – Кодирование и отладка
Этап 7 – Тестирование компонентов
Этап 8 – Интеграция компонентов
Этап 9 – Тестирование всей системы
Этап 10 – Сопровождение, внесение изменений, оптимизация
2.2 Описание этапов создания программного обеспечения
Сейчас давайте рассмотрим каждый этап, т.е. узнаем, какие действия необходимо выполнять на каждом этапе.
Этап 1 – Определение проблемы
Перед тем как приступать к кодированию, необходимо четко сформулировать проблему, которую Ваша будущая программа должна решать. Так как, не имея хорошего определения проблемы, Вы можете потратить много усилий и времени на решение не той проблемы, которую требуется решить.
На данном этапе проводится простая формулировка сути проблемы без каких-либо намеков на ее возможные решения, при этом формулировать ее следует на языке, понятном пользователю, т.е. она должна быть описана с пользовательской точки зрения.
Определение проблемы – это фундамент всего процесса программирования!
Этап 2 – Выработка требований
Что такое требования и зачем их нужно выработать?
Требования к программе – это подробное описание всех возможностей программы и действий, которые должна выполнять программа. Такие требования иногда также называют «Функциональной спецификацией» или просто «Спецификацией».
Требования вырабатывают для того, чтобы свести к минимуму изменения системы после начала непосредственной разработки. Такие требования должны быть обязательно официальными, т.е. документально оформлены. Так как это гарантирует то, что функциональность системы определяется заказчиком, а не программистом. Даже в случае с внутрикорпоративными разработками такие требования должны быть зафиксированы, например, в виде технического задания, подписанного всеми задействованными лицами, тем самым Вы избежите лишних разговоров и споров, например, о том, что реализованный функционал делает не все или не так [2].
Выработка требований очень важна, так как она позволяет определить функциональность программы до начала программирования.
От уровня качества напрямую зависит готовность продукта к серийному выпуску, так что еще одним из основных этапов разработки является качественно составленное техническое задание на разработку ПО.
Составление ТЗ является ответственной и трудной задачей, потому как большинство данных еще неизвестно, но как раз правильная постановка задания может упростить, или наоборот усложнить дальнейшее проектирование. У самого заказчика часто нет соответствующих знаний и навыков, бывает, что ограничены ресурсы, поэтому он обращается за помощью к разработчику. Многие специалисты уверены, что грамотное ТЗ – это уже пятьдесят процентов успеха, так что время, затраченное на его подготовку – одно из правильных вложений, сделанных заказчиком. Важно доверять этот начальный этап настоящим специалистам, которые продумают и просчитают все сразу, помогут сэкономить время и деньги.
Этап 3 – Создание плана разработки
На данном этапе Вы уже должны в формальном виде составить план разработки программного обеспечения с учётом существующей проблемы и выработанных требований. Иными словами, Вы должны составить план того, как Вы будете действовать дальше.
Этап 4 – Разработка архитектуры системы или высокоуровневое проектирование
Архитектура системы – это каркас программы, это высокоуровневое проектирование программы.
Данный этап также очень важный, так как, не имея хорошей архитектуры, Вы можете решать правильную проблему, но прийти к неправильному решению. Хорошая архитектура программы упрощает программирование, а плохая архитектура усложняет его [4].
Архитектура системы обычно включает:
Общее описание системы;
Основные компоненты;
Формат и способ хранения данных;
Специфические бизнес-правила;
Способ организации пользовательского интерфейса;
Подход к безопасности системы;
Оценки производительности;
Возможности масштабирования;
Моменты, связанные с интернациональностью, т.е. будет ли система интернациональной.
Кроме того, в архитектуру необходимо включить подтверждение того, что при разработке этой архитектуры рассматривались альтернативные варианты в каждом из вышеперечисленных направлений, с обоснованием окончательного выбора и подхода.
Этап 5 – Детальное проектирование
На этом этапе проводится проектирование программы на низком уровне, иными словами, здесь проектируются классы и методы, рассматриваются, оцениваются и сравниваются различные варианты и причины выбора окончательных подходов и способов реализации.
При разработке небольших программ программисты обычно сами проектируют программу на таком уровне, это выглядит как написание псевдокода или рисование схем, поэтому часто этот этап рассматривается как часть непосредственного кодирования и в таких случаях итоговый документ (если того требует формальность) состоит преимущественно из различных набросков и заметок программистов.
Но при реализации крупных проектов данному процессу отводится отдельный этап и проектирование в этом случае проводится с очень высокой степенью детальности.
Этап 6 – Кодирование и отладка
Это как раз тот этап, который все знают и, наверное, думают, что это единственный этап в процессе разработке программного обеспечения – это непосредственное написание кода и его отладка. Но, как видите, это далеко не первый и не единственный этап разработки ПО.
Если все вышеперечисленные этапы выполнены, то данный этап подразумевает чисто механическую работу, т.е. кодинг. Программисту в этом случае не нужно что-то выдумывать и самостоятельно разрабатывать, ему нужно просто написать код, который реализует заданный, очень детально описанный в проекте, алгоритм.
После того как код написан, программисту необходимо отладить этот код, чтобы в нем не было никаких ошибок.
Этап 7 – Тестирование компонентов
После того, как код написан, и проведена отладка, необходимо провести тестирование реализованного функционала. Если программа состоит из нескольких компонентов, сначала тестируют каждый компонент в отдельности, так как очень крупные программы включают огромный функционал, который часто разделяют на отдельные компоненты, разработка которых осуществляется по отдельности. В менее крупных проектах этот этап может включать просто тестирование отдельных классов.