ПЗ (1218909), страница 2
Текст из файла (страница 2)
7) возможность вести базу данных покупателей, с указанием их контактных данных;
8) ведение журнала закупок;
9) ведение журнала продаж;
10) выгрузка отчетов в Microsoft Exel.
Технические требования к информационной системе следующие:
1) работа на компьютере под управлением операционной системы Windows 7/Windows Server 2008 и новее;
2) работа на компьютере с оперативной памятью не более 4 ГБ для серверной части программы и не более 2 ГБ – для клиентской части;
3) программа должна генерировать как можно меньше сетевого трафика.
Прочие требование к информационной системе:
1) использование бесплатной системы управления базами данных;
2) использование только бесплатных компонентов и библиотек;
3) отсутствие необходимости в регулярном обновлении;
4) простой и интуитивно понятный интерфейс;
5) возможность добавлять новые рабочие места без необходимости докупать лицензии.
Поскольку на российском рынке не представлено программных продуктов, удовлетворяющих вышеперечисленным требованиям, необходимо разработать такую информационную систему.
Но, прежде чем делать это, необходимо определиться с подходом к разработке программного продукта.
3 ПОДХОДЫ К РАЗРАБОТКЕ ПРОГРАММНЫХ ПРОДУКТОВ
3.1 Каскадная (Водопадная) модель
Водопадная модель жизненного цикла ПО предполагает последовательное выполнение различных этапов деятельности, включая анализ требований, проектирование, кодирование и тестирование отдельных модулей (компонентов), тестирование сборок и интегрированное тестирование всего конечного продукта.
При этом предполагается четкое разграничение этапов, на которых набор документов, выработанный на предыдущей этапе, передается в качестве входных данных для следующего.
Таким образом, каждый вид деятельности выполняется на какой-то одной фазе жизненного цикла ПО, движение в обратную сторону по этой цепочке невозможно.
Согласно данной модели, процесс разработки состоит из нескольких этапов.
Анализ. На этапе анализа изучается и определяется задача, которую должна выполнять программа. Результатом выполнения этой фазы является совокупность требований, предъявляемых к ПО.
Проектирование. На этом этапе требования, выявленные при анализе, преобразуются в описание принципов решения - документ, в соответствии с которым принимаются конкретные решения при реализации программы. Основным итогом второй фазы является получение проекта, который может включать текст на естественном языке, модель ПО, алгоритмы, таблицы, математические формулы и т. п. Детальное проектирование предполагает выделение компонент ПО, определение их структуры и методов взаимодействия.
Реализация. По завершении исходного проектирования следует этап реализации, на котором создаются и тестируются программные модули, определенные при проектировании. Главными результатами этого этапа являются модули исходного кода и автономные тесты модулей. После реализации переходят к тестированию системы, а затем к сдаче ее в эксплуатацию.
Внедрение и эксплуатация. Готовый программный продукт передается заказчику, производятся приемо-сдаточные испытания, осуществляется обучение пользователей и опытная эксплуатация, после чего ПО ставится на сопровождение и начинается производственная эксплуатация программной системы.
Недостатки водопадного подхода:
1) накопление различных ошибок, допущенных на ранних стадиях проекта. Если только к концу проекта, становится очевидно, что были допущены ошибки, то любой возврат к предыдущим стадиям с целью исправления ошибок становится крайне дорогостоящим. Метод «водопада" не позволяет эффективно выявлять и нивелировать последствия подобных рисков;
2) неоправданное увеличение времени реализации, превышение бюджета и риск полного срыва проекта из-за накопления ошибок от этапа к этапу;
3) все ключевые решения принимаются тогда, когда у аналитиков и разработчиков нет полного понимания системы.
Очень сложно уложить реальный процесс создания программного обеспечения в такую жесткую схему, поэтому постоянно возникает необходимость возврата к предыдущим этапам с целью уточнения и пересмотра ранее принятых решений.
В начале проекта перед разработчиками стоит обескураживающая задача: полностью определить все требования к системе. Для этого необходимо тщательно и всесторонне обсудить с пользователями и исследовать бизнес-процессы. Пользователи должны согласиться со всем тем, что выясняется в ходе такого обследования, хотя они могут и не ознакомиться до конца с его результатами. При некотором везении таким способом на стадии анализа удается собрать около 80% требований к системе. При проектировании могут возникнуть новые проблемы, их необходимо опять обсуждать с пользователями, что выразится в появлении новых требований к системе. В процессе реализации и тестирования зачастую обнаруживается, что некоторые из принятых ранее решений невозможно осуществить или выясняется, что требования не были достаточно детализированы и их реализация некорректна. Нужно возвращаться назад на этап анализа и пересматривать эти требования.
4) метод водопада не дает возможности быстрой адаптации к изменениям, особенно на поздних стадиях жизненного цикла ПО;
5) конечный продукт может оказаться невостребованным из-за неточного изложения требований или их изменения за длительное время создания ПО.
Водопадный подход хорошо работает в проектах, где требования к программному продукту четко определены и не должны меняться, вовлечение заказчика в процесс разработки не требуется. То же касается проектов, сложность которых определяется необходимостью реализации сложных алгоритмов, а роль и объем пользовательского интерфейса невелик [10].
Схема каскадной модели приведена на рисунке 3.
Рисунок 3 ̶ Схема каскадной модели
Подводя итог, можно сказать, что данная модель применима только в очень крупных проектах, с большой командой разработчиков.
Данная модель эффективна, только когда у заказчика есть четкое понимание того, какой конечный продукт он хочет получить. В данном случае такого понимания нет, описанные в предыдущей главе функциональные требования, это наболевшие и самые заметные проблемы заказчика.
Автору ясно, что на этом заказчик не остановится, и в случае успешного внедрения первой версии программы последуют новые пожелания заказчика, функционал системы будет значительно расширен. Да и команда разработчиков состоит всего из одного специалиста, поэтому трудозатраты на предполагаемую в водопадном подходе формализацию не окупятся. В данном случае требуется более гибкий подход.
3.2 Итерационная модель
Итеративный инкрементный подход к разработке ПО (iterative and incremental development, IID) берет свое начало с середины 50-х годов прошлого столетия. Но если в те времена понятие «Итеративная разработка» сводилась к исправлению уже сделанного, то в контексте современных методов быстрой разработки этот термин означает нечто иное: не просто пересмотр проделанной работы, но и эволюционное продвижение вперед. Итеративный инкрементный подход основывается на базовом формальном описании системы, дающем возможность создать первую исполняемую функциональную модель.
Полученная модель проверяется на соответствие описанию системы, а затем расширяется далее, последовательно преобразуясь в новые модели, в которых отражается увеличение требований к системе и уточнение деталей их реализации. Процесс продолжается до трансформации модели в реальную программную систему.
Итеративный подход предполагает разбиение жизненного цикла проекта на последовательность итераций, каждая из которых напоминает "мини-проект", включая все этапы жизненного цикла ПО в применении к созданию меньших фрагментов функциональности, по сравнению с проектом, в целом.
Цель каждой итерации – получение работающей версии (релиза) ПО, включающей функциональность всех предыдущих и текущей итерации. Результат финальной итерации содержит всю требуемую функциональность продукта. Таким образом, с завершением каждой итерации, продукт развивается инкрементно.
С точки зрения структуры жизненного цикла такую модель называют итеративной (iterative). С точки зрения развития продукта - инкрементной (incremental). Опыт разработки ПО показывает, что невозможно рассматривать каждый из этих взглядов изолировано. Чаще всего такую смешанную эволюционную модель называют просто итеративной (говоря о процессе) и/или инкрементной (говоря о наращивании функциональности продукта).
Шансы успешного создания сложной системы будут максимальными, если она реализуется в серии небольших шагов и если каждый шаг заключает в себе четко определенный результат, а также возможность «Отката назад», к результатам предыдущей успешной итерации, в случае неудачи. Перед тем, как пустить в дело все ресурсы, предназначенные для создания ПО, разработчик имеет возможность получать обратную связь из реального мира (заказчиков, пользователей) и исправлять возможные ошибки в проекте.
Эволюционная модель подразумевает возможность не только сборки работающей (с точки зрения результатов тестирования) версии системы, но и её развертывания в реальных операционных условиях с анализом откликов пользователей для определения содержания и планирования следующей итерации.
Поскольку на каждом шаге мы имеем работающую систему, то можно:
1) очень рано начать тестирование пользователями;
2) принять стратегию разработки в соответствии с бюджетом, значительно защищающую от перерасхода времени или средств (в частности, за счет сокращения второстепенной функциональности).
Таким образом, значимость эволюционного подхода на основе организации итераций особо проявляется в снижении неопределенности с завершением каждой итерации. В свою очередь, снижение неопределенности позволяет уменьшить риски. Итеративному разбиению может быть подвержен не только жизненный цикл ПО в целом, включающий перекрывающиеся этапы - формирование требований, проектирование, реализация и др., но и каждый этап может, в свою очередь, разбиваться на уточняющие итерации, связанные, например, с детализацией структуры декомпозиции проекта - например, архитектуры модулей ПО.
Идея, лежащая в основе инкрементной разработки, состоит в том, что программную систему следует разрабатывать по принципу приращений, так, чтобы разработчик мог использовать данные, полученные при разработке более ранних версий (релизов) ПО. Новые данные получаются как в ходе разработки ПО, так и в ходе его использования, где это возможно.
Ключевые этапы этого процесса – простая реализация подмножества требований к программе и совершенствование модели в серии последовательных релизов до тех пор, пока ПО не будет реализовано полностью. В ходе каждой итерации организация модели изменяется, и к ней добавляются новые функциональные возможности.
Для организации инкрементной разработки обычно выбирается характерный временной интервал, например неделя. Затем в течение этого интервала происходит обновление проекта: добавляется новая документация как текстовая, так и графическая (например, новые диаграммы на UML), расширяется набор тестов, добавляются новые программные коды и т. д.
Теоретически шаги разработки (increments) могут выполняться и параллельно, но такой процесс очень сложно скоординировать. Инкрементная разработка проходит лучше всего, если следующая итерация n+1 начинается после того, как обновление всех артефактов в итерации n закончено, и существенно хуже, если время, требуемое на обновление артефактов, значительно превышает выбранный интервал.
В результате каждой итерации получается работающее, но не полнофункциональное ПО, которое еще не является программным продуктом и не подлежит распространению. Результат каждой итерации в общем случае нельзя рассматривать и как прототип ПО. Точнее следует считать, что в результате каждой итерации создается версия некоторой части ПО.
Необходимо заметить, хотя как правило на каждой итерации определяются и реализуются новые требования, некоторые итерации могут быть целиком посвящены усовершенствованию существующей программы, например с целью повышения ее производительности.
Разработка ПО – очень молодая отрасль, и не приходится удивляться, что построенная в соответствии со схемой «требования, проектирование, реализация» упрощенческая модель водопада, предусматривающая создание ПО за один проход на основании заранее составленных документов устояла в ходе первых попыток найти идеальный процесс разработки. Можно назвать и другие причины, объясняющие быстрое распространение и долгую популярность идеи «водопада». Эту идею легко объяснить и легко запомнить. «Выяви требования, потом проектируй, а потом реализуй». Она создает иллюзию упорядоченного, объяснимого и обеспечивающего возможность измерений процесса, размеченного простыми вехами, взятыми из документов (например, «стадия выявления требований завершена»). Итерационную модель труднее и описать, и понять.
Начиная с середины прошлого десятилетия, подход итерационный подход стал завоевывать ведущие позиции. Были изданы сотни книг и статей, главной темой которых стала пропаганда итерационного подхода. Появились десятки новых методов, их общей отличительной особенностью стала все более явственно прослеживающаяся тенденция отдавать предпочтение жестко ограниченным по времени итерациям продолжительностью от одной до шести недель. Примером может служить спиральная модель Боэма.
Согласно этой модели каждая итерация должна начинаться с выделения целей и планирования очередной итерации, определения основных альтернатив и ограничений при ее выполнении, их оценки, а также оценки возникающих рисков и определения способов избавления от них. Итерация должна заканчиваться оценкой результатов проведенных в ее рамках работ. Основным новым элементом спиральной модели является общая структура действий на каждой итерации - планирование, определение задач, ограничений и вариантов решений, оценка предложенных решений и рисков, выполнение основных работ итерации и оценка их результатов.
Схема итерационной модели представлена на рисунке 4.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
