Программное обеспечение – совокупность программных продуктов, сущность которых направлена на автоматизацию каких-либо процессов. Так же программное обеспечение является неотъемлемой частью других технических сооружений, которые должны реализовать алгоритмы решения предназначенных для них задач. Поэтому на сегодняшний день актуален вопрос о разработке этого программного обеспечения. Для разработчика важно, чтобы продукт был качественным и компактным.
Ведь ещё 15 лет назад люди не могли представить себе фотоаппарат, который может подключиться к беспроводной сети Wi-Fi, телефон без кнопок, с которого можно дозвониться в любую точку мира, телевизор, на котором можно переключать канал взмахом руки, терминалы, электронные деньги и тому подобное. Резкому скачку в техническом прогрессе, по мнению успешных разработчиков, способствовала конкуренция между ними. За идеей одного разработчика рождалась идея другого. Поэтому конкуренция между ними порождала новые процессы разработки программных систем, появился стимул для их совершенствования, который существует по сегодняшний день.
Процесс – вид деятельности, производящийся по определённому алгоритму с целью получения конкретного результата (продукта, услуги и т. п.). Чтобы выполнить процесс разработки программного обеспечения разработчику необходимо:
Разработать спецификацию требований, которым должна подчиняться система. Программа должна полностью соответствовать предназначенному ей описанию. Требования должны быть сформулированы недвусмысленно, непротиворечиво, обладать такими свойствами как полнота, проверяемость.
Смоделировать будущее программное обеспечение. Этот шаг может быть осуществлён при помощи CASE средств, таких как MS Project, Power Builder, Rational Rose. На этом этапе создатель системы разрабатывает проект программного средства. Здесь он должен предусмотреть все заданные требования, описание системы, надёжность и безопасность системы, эффективность и удобство использования. В проектировании должны применяться только современные методы разработки
Кодирование. После моделирования системы с учетом требований заказчика разработчик приступает к кодированию. Правильная реализация данного пункта заключается в том, что в процессе разработки кода должны учитываться установленные стандарты качества кода (способ выбора названий, регистр символов, стиль отступов, расстановки скобок, пробелов, использование комментариев).
Тестирование системы. На этапе тестирования проводится контроль соответствия требованиям программной системы. Тестирование проводится как отдельных модулей системы, так и всей системы в целом. Результатом тестирования является сравнение текущего состояния системы и ожидаемого. Таким образом, тестирующий выявляет несоответствия программы требованиям и устраняет их.
Документирование. Самым ответственным шагом разработки системы является именно документирование. Потому что разработчик должен уметь не только изобрести продукт, но и правильно его представить заказчику, сопроводить, чтобы в дальнейшем была возможна профилактика и совершенствование программы. Документацию содержит любой стандартный процесс разработки программного обеспечения. В неё входит спецификация требований, подробное описание системы, анализ осуществимости и анализ рисков, план распределения бюджета и сроков выполнения проекта, варианты использования продукта, объяснение терминов, использованных при описании продукта, а также другие индивидуальные предписания по использованию системы в зависимости от её назначения. Проект должен быть документирован в соответствии со стандартами.
В процессе разработки программного обеспечения ведется контроль выполнения проекта и его улучшение.
Моделированием является способ познания процессов разработки программного обеспечения с использованием объекта-модели. Это создание образов действий, ориентированных на внедрение в процесс современных методов разработки систем. Моделирование процессов позволяет улучшить представление о разработке обеспечения, предусмотреть критические ситуации, провести анализ перспектив будущей системы. Для того чтобы смоделировать какой-либо процесс, потребуется его структурная схема.
Рассмотрим несколько моделей разработки систем:
Каскадная модель. После анализа последовательности этапов каскадной модели разработки становится видно, что эта модель является стандартным процессом, описанным ранее. Этот способ создания программы не эффективен на сегодняшний день: разработчик, используя данную модель, ограничивает себя в общении с заказчиком. Заказчик, в свою очередь должен четко формулировать требования заранее, а разработчик общается с ним только после выполнения определённого этапа и после завершения процесса должен предоставить конечный продукт с полным пакетом документации.
Спиральная (циклическая) модель. Смысл этой модели заключается в том, что каждый последующий шаг определяется только после общения с заказчиком. Например, если уже на стадии разработки спецификации требований возникло недопонимание между разработчиком и заказчиком, процесс не будет продвигаться на следующий шаг, пока эти разногласия не будут устранены. Зацикливание может возникнуть на любом этапе процесса разработки. Использование данной модели достаточно эффективно, так как самый главный залог успешного выполнения проекта, постоянное промежуточное консультирование с заказчиком, и есть её основным отличием от других.
Последовательность этапов схожа с порядком шагов в каскадной модели, но на каждом из них кроме разработки также происходит анализ, оценка альтернатив и спецификаций и тестирование. Данная модель требует высоких затрат и нецелесообразна при ограниченных финансах. Но основной проблемой модели является определение момента перехода к следующему этапу. При использовании спиральной модели снижаются риски, что не мало важно при разработке крупных систем.
Компонентная (пошаговая) модель.Под компонентом программы в узком смысле понимается программный модуль. Компонент имеет возможность поставки и удаления в отрыве от всей программы. Основной задачей модели является тестирование и интеграция. Так как компонентная модель подразумевает сборку продукта из готовых компонентов, то риск системных ошибок значительно снижается. Данная модель позволяет активно использовать прототипы, в чем заключается приоритетность разработки. В процессе разработки рассматривается не только в целом жизненный цикл системы, но и жизненный цикл каждого программного модуля.
Формальная модель. Принцип данной модели заключается в том, что после спецификации требований разработчик сразу же приступает к трансляции требований в программный код. Этот подход к разработке доступен только опытным разработчикам, так как в результате система будет тестироваться в целом и должна полностью соответствовать спецификации требований.
Эволюционная модель. Эта модель подразумевает постепенную разработку, но плохую структурированность и документацию. Происходит разработка так называемых под-проектов, что приводит к частичной разработке всей системы. Такой подход обеспечивает постоянный учет требований заказчика.
Итак, системы моделирования процессов разработки строились на качестве выполнения требований к разрабатываемой системе. При анализе каждой модели выявлена эффективность только тех, в которых предусмотрено постоянное общение с заказчиком, наличие, качество и полнота документации.
Моделирование может применяться во всех перечисленных моделях разработки.
Моделирование может производиться и на этапе постановки задачи, как заказчиком, так и разработчиком. Здесь спектр задач моделирования весьма велик. Например, заказчик предъявил особые требования к дизайну сайта и сделал макеты страниц в системе Axure RP Pro. Если есть готовая модель web-страниц, то нет необходимости перечислять требования к дизайну страниц в техническом задании, достаточно просто сослаться на модель.
На этапе анализа требований моделирование – хороший способ обезопасить себя как заказчика, ведь некоторые детали можно уточнить у заказчика. Примером может служить случай, когда дизайн сайта описан в словесной форме и, чтобы уточнить, что именно имел в виду заказчик, можно воспользоваться системой Axure RP Pro 7.0. Также необходимо поступать и с графическим интерфейсом программ, ведь графическая часть плохо описывается словесно. Если предметом разработки является компьютерная игра, то, возможно необходимы 3D модели элементов игры.
Моделирование активно применяется на этапе проектирования программного продукта. Простейшим примером моделирования является составление блок-схемы, которая является модель алгоритма решения задачи. Примером системы для моделирования на этапе проектирования может служить Astah – программа, предназначенная для создания UML диаграмм.
UML (Unified Modeling Language) — унифицированный язык моделирования, активно применяется при объектно-ориентированном анализе. Цель UML наглядное проектирование архитектуры программного продукта. В стандарт UML входят следующие виды диаграмм:
- диаграмма вариантов использования;
- диаграмма классов;
- диаграмма компонентов и другие.
Диаграмма вариантов использования (use case diagram) состоит из экторов (англ. Actor) и претендентов. Эктор отражает объект, а претендент – действие. Диаграмма хорошо подходит для моделирования практически любых процессов. Пример диаграммы приведён на рисунке 2. На диаграмме эктором является «человек», а претендентами «идти» и «бежать». Таким образом, с помощью диаграммы вариантов использования можно показать, что может делать пользователь при работе с программой.
Рисунок 2. Пример диаграммы вариантов использования.
Диаграммы классов применяются только в объектно-ориентированном программировании. Они являются визуальным представлением структуры классов в программе. Диаграммы классов используются гораздо чаще других диаграмм, они позволяют разработчикам правильно спроектировать архитектуру программного продукта.
Диаграмма компонентов – отражает компоненты программной системы взаимодействия между ними.
В процессе тестирования и внедрения также могут использоваться системы моделирования.
Одна из таких систем - Rational Method Composer. Этот продукт является инструментом для создания, изменения и развёртывания процессов разработки. RMS включает в себя базу знаний, являющуюся основой для моделирования процессов. RMC разрабатывался как система управления содержанием (content management system), предоставляющая единую структуру управления и отображения всей базы знаний процессов организации. Все содержание баз знаний процессов может быть опубликовано в виде html-файлов и выложено на веб-сервера для распределенного использования.
Другим известным средством моделирования является BOUML. Оно предназначено для автоматизации построения программного обеспечения, а также для генерации кодов на различных языках и выпуска проектной документации. Принцип его работы заключается в построении диаграмм и далее по ним определять и генерировать код на C + +, Java, PHP, Python и IDL. Эти диаграммы определяют логическую и физическую структуру модели.
Ещё одно средство моделирования Vantage Team Builder (Westmount I-CASE). Этому средству свойственно проектирование диаграмм потоков данных, структур данных , проектирование диаграмм архитектуры системы – SAD, генерация кода программ на языке 4GL целевой СУБД с полным обеспечением программной среды и генерация SQL-кода для создания таблиц БД, индексов, ограничений целостности и хранимых процедур, программирование на языке C со встроенным SQL, управление версиями и конфигурацией проекта, многопользовательский доступ к репозиторию проекта, генерация проектной документации по стандартным и индивидуальным шаблонам.
Среди систем моделирования также числится Designer/2000 компании Oracle. Данный продукт компании Oracle, возможно, наиболее полно поддерживает все этапы создания приложений обработки данных. Однако, следует оговориться, что, в отличие от других средств, он поддерживает практически одну целевую СУБД - Oracle Server (имеется еще возможность генерации скриптов на ANSI SQL). То же самое касается и средств создания пользовательсокго интерфейса. Хотя возможна генерация прототипов программ для языков Visual Basic, C, Java, полностью все возможности Designer/2000 реализуются только при использовании его вместе со средством разработки Oracle Developer/2000.
Таким образом, рассмотрев несколько систем, можно сделать вывод: методы разработки программного обеспечения развиваются и прогрессируют, конкурируя между собой. Системы моделирования предназначены для составления более точной спецификации требований, которая лежит в основе модели продукта и дальнейшего его кодирования. Поэтому системы моделирования играют не маловажную роль в программной инженерии.
Было рассмотрено такое понятие, как системы моделирования процессов разработки программного обеспечения. Были выявлены наиболее эффективные модели разработки процессов по следующим признакам: частота общения с заказчиком, наличие и полнота документации. Был также представлен стандартный процесс разработки программного продукта. Особое внимание концентрировалось на том, что именно моделируют системы моделирования разработки, а также представлен краткий обзор нескольких таких систем.
Список литературы:
Б. Я. Советов, С. А. Яковлев Моделирование систем: учебник для вузов, 3-е издание перераб. и доп. – М.: Высш. шк., 2001. – 343 стр.:ил.
Поппендик Мэри, Поппендик Том Бережливое производство программного обеспечения: от идеи до прибыли: Пер. с англ. – М.:ООО «И. Д. Вильямс», 2010. – 256с.:ил. – Парал. тит. англ.
А. О. Шульгин Особенности жизненного цикла автоматизированной информационной системы ВУЗа.
Режим доступа: http://vestnik.stavsu.ru/70-2010/12.pdf
Жизненный цикл программного обеспечения (материал из википедии)
Режим доступа: https://ru.wikipedia.org/wiki/%D0%96%D0%B8%D0%B7%D0%BD%D0%B5%D0%BD%D0%BD%D1%8B%D0%B9_%D1%86%D0%B8%D0%BA%D0%BB_%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%BD%D0%BE%D0%B3%D0%BE_%D0%BE%D0%B1%D0%B5%D1%81%D0%BF%D0%B5%D1%87%D0%B5%D0%BD%D0%B8%D1%8F
Екатерина Лаврищева, Владимир Петрухин, Методы и средства инженерии программного обеспечения
Режим доступа: http://www.intuit.ru/studies/courses/2190/237/lecture/6120?page=3
6. Моделирование процессов разработки ПО и создание сайтов процессов с помощью Rational Method Composer
Режим доступа: http://www.ibm.com/developerworks/ru/library/r-rmc-model/
7. http://citforum.ru/database/case/glava5_2_1.shtml
8. http://citforum.ru/database/kbd96/63.shtml
Ткачева Александра Юрьевна
Стр. 20.12.2014