Системы моделирования процесса разработки программного обеспечения
Использование моделирования в программной инженерии в процессе разработки программного обеспечения. Основные этапы процесса разработки программного обеспечения, их характеристика. Моделирование процессов, их определение фазами и видами деятельности.
| Рубрика | Программирование, компьютеры и кибернетика |
| Вид | реферат |
| Язык | русский |
| Дата добавления | 25.12.2017 |
| Размер файла | 2,2 M |
Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
25
Размещено на http://www.allbest.ru/
Приднестровский государственный университет им. Т.Г. Шевченко
Инженерно-технический институт
Кафедра программного обеспечение вычислительной техники и автоматизированных систем
РЕФЕРАТ
по теме: "Системы моделирования процесса разработки программного обеспечения"
Работу выполнил
студент группы ИТ17ДР68ПИ1
Абрамов С.С.
Работу проверил, доцент Помян C.В.
Тирасполь, 2017
Содержание
- Введение
- 1. Процесс разработки программного обеспечения
- 2. Модели разработки программного обеспечения
- 3. Моделирование процесса разработки программного обеспечения
- Заключение
- Список литературы
Введение
В настоящее время нельзя назвать область человеческой деятельности, в которой в той или иной степени не использовались бы методы моделирования. Особенно это относится к сфере управления различными системами, где основными являются процессы принятия решений на основе получаемой информации.
"Моделирование" как метод исследования, характеризует один из путей познания, который дает возможность переноса результатов, полученных в ходе построения и изучения моделей на оригинал на том основании, что модель в определенном смысле отображает его стороны. Модель (modulus - мера, образец, норма), в методологии науки - аналог определенного фрагмента природной или социальной реальности - оригинала модели. Смысл моделирования заключается в воспроизведении характеристик (структуры, свойств, взаимоотношений, отношений) некоторого объекта на другом, специально созданном для их изучения. Моделирование связано с абстрагированием и идеализацией, посредством которых выделяются и отражаются существенные стороны моделируемых объектов и процессов для выявления наиболее эффективных средств для решения поставленных задач.
Моделирование активно применяется в программной инженерии, в процессе разработки программного обеспечения. Моделирование позволяет улучшить представление о разработке программного обеспечения, предусмотреть критические ситуации, провести анализ перспектив будущей системы. Моделирование направлено на повышение эффективности деятельности, что в случае с разработкой программного обеспечения значит получение максимально ожидаемого и предсказуемого результата с наименьшими затратами. Снизить риски и потери как компании, так и сотрудников (в том числе и имиджевые) может только грамотно настроенная и соблюдаемая методология производства, в том числе и производства программного обеспечения.
1. Процесс разработки программного обеспечения
Программное обеспечение (ПО) - комплекс программных продуктов, суть которых ориентирована на автоматизирование каких-либо процессов. Программное обеспечение - это неотделимая часть любых технических сооружений, которым необходимо реализовать алгоритмы решений необходимых задач.
Известный специалист в области программной инженерии из компании IBM Харальд Милсом считает, что программное обеспечение - это множество развивающихся во времени логических предписаний, с помощью которых некоторый коллектив людей управляет и использует многопроцессорную и распределенную систему вычислительных устройств.
По мнению Х. Милсона, ПО включает:
не только сами программы, но и различную документацию, определяющую определенную систему отношений между людьми, использующими эти программы в рамках некоторого процесса деятельности;
распределенную и многопроцессорную вычислительную среду (персональные компьютеры, сервера и т.д.), в которой ПО функционирует;
постоянное развитие ПО во времени, направленное на исправление ошибок добавление новых функций, выпуск новых версий, изменений его аппаратной базы.
ПО - это сложная динамическая система, для которой характерны следующие особенности:
сложность программных объектов, которая существенно зависит от их размеров. Как правило, большее ПО (большее количество пользователей, больший объем обрабатываемых данных, более жесткие требования по быстродействию и пр.) с аналогичной функциональностью - это другое ПО.
согласованность - ПО должно быть согласовано с большим количеством интерфейсов, плохо поддающихся стандартизации (поскольку основываются на многочисленных и плохо формализуемых человеческих соглашениях), с которыми впоследствии оно должно взаимодействовать;
изменяемость - ПО легко изменить и, как следствие, требования к нему постоянно меняются в процессе разработки. Это создает много дополнительных трудностей при его разработке и эволюции;
нематериальность (незримость) - ПО невозможно увидеть, оно виртуально. Поэтому, например, трудно воспользоваться технологиями, основанными на предварительном создании чертежей, успешно используемыми в других промышленных областях (например, в строительстве, машиностроении) (Фредерик Брукс).
Создание ПО предполагает множество различных видов деятельности, методов, методик и шагов, используемых для разработки и эволюции ПО и связанных с ним продуктов (планов проекта, проектных документов, программного кода, тестов и руководств пользователя и пр.). Все это множество направлений деятельности называют процессом разработки ПО.
Процесс разработки ПО состоит из следующих этапов:
1. Анализ. На этом этапе участникам процесса необходимо определить необходимые требования. Так же на этом этапе происходит систематизирование, документирование, анализ этих требований, выявление и разрешение противоречий, предъявляемые к конечному продукту. Требования должны быть сформулированы недвусмысленно, непротиворечиво.
2. Моделирование. Этот этап реализовывается с помощью CASE инструментов, например, BPwin, ERwin, Rational Rose, Vantage Team Builder и др. Этот процесс включает в себя: определение структуры ПО, данных, интерфейсов взаимодействия системных компонентов, формализацию и детализацию разрабатываемого ПО.
3. Кодирование. Этот этап заключается в реализации разработанных алгоритмов, составлении по ним текстов программы с использованием определенного языка программирования. В ходе разработки кода должны соблюдаться назначенные стандарты: способ выбора названий, регистр символов, стиль отступов, расстановки скобок, пробелов, использование комментариев.
4. Тестирование системы. На этом этапе проверяются все модули программы на соответствие требованиям программной системы. Результатом тестирования является сравнение текущего состояния системы и ожидаемого.
5. Документирование. Важным этапом разработки ПО является документирование, направленное на то, чтобы разработчик правильно все представил заказчику. Документация содержит спецификацию требований, описание системы, анализ осуществимости и анализ рисков, план распределения бюджета, сроки выполнения проекта, варианты использования продукта, объяснение терминов, использованных при описании продукта и т.д. Документирование должно осуществляться в соответствии с действующими стандартами.
Несмотря на активное развитие программной инженерии, до сегодняшнего дня не существует универсального процесса разработки ПО - т.е. набора методик, правил и предписаний, подходящих для ПО любого вида, для любых компаний, для команд любой национальности. Каждый текущий процесс разработки ПО, осуществляемый некоторой командой в рамках определенного проекта, имеет большое количество особенностей и индивидуальностей. В то же время, перед началом проекта происходит планирование процесса работы, направленное на определение роли и обязанностей в команде, рабочих продуктов (промежуточных и финальных), порядка участия в их разработке членов команды и т.д. - это так называемый конкретный процесс, в отличии от плана работ, проектных спецификаций и пр. Например, в системе Microsoft Visual Team System оказывается шаблон процесса, создаваемый или адаптируемый (в случае использования стандартного) перед началом разработки. В VSTS существуют заготовки для конкретных процессов на базе CMMI, Scrum и др. (Электронная книга).
В рамках компании возможен стандартный процесс (стандартизация всех текущих процессов), содержащий:
информацию, правила использования, документацию и инсталляционные пакеты средств разработки, используемых в проектах компании (систем версионного контроля, средств контроля ошибок, средств программирования - различных IDE, СУБД и т.д.);
описание практик разработки - проектного менеджмента, правил работы с заказчиком и т.д.;
шаблоны проектных документов - технических заданий, проектных спецификаций, планов тестирования и пр.
Также возможна стандартизация процедуры разработки конкретного процесса, направленная на курсирование внутри компании передового опыта и унификацию средств разработки.
Считается, что наличие стандартного процесса свидетельствует о наличии "единой воли" в организации, существующей именно на уровне процесса.
Процесс разработки программного обеспечения является, преимущественно, проектной областью. Проект - это уникальная деятельность, имеющая начало и конец во времени, направленная на достижение определённого результата/цель, создание определённого, уникального продукта или услуги, при заданных ограничениях по ресурсам и срокам, а также требованиям к качеству и допустимому уровню риска.
2. Модели разработки программного обеспечения
Процесс создания программного обеспечения не является однородным. Тот или иной метод разработки ПО, как правило, определяет некоторую динамику развертывания тех или иных видов деятельности, то есть, определяет модель процесса (process model).
моделирование программное обеспечение
Модель является хорошей абстракцией различных методов разработки ПО, позволяя лаконично, сжато и информативно их представить.
Говоря о моделях процессов, необходимо различать фазы и виды деятельности.
Фаза (phase) - это определенный этап процесса, имеющий начало, конец и выходной результат. Например, фаза проверки осуществимости проекта, сдачи проекта и т.д. Фазы следуют друг за другом в линейном порядке, характеризуются предоставлением отчетности заказчику и, часто, выплатой денег за выполненную часть работы.
Фазы позволяют создавать и предъявлять промежуточные результаты проекта. Кроме того, фазы помогают синхронизировать деятельность разных рабочих групп, а также отслеживать продвижение проекта.
Примерами фаз может служить согласование с заказчиком технического задания, реализация определенной функциональности ПО, этап разработки, оканчивающийся сдачей системы на тестирование или выпуском альфа-версии.
Вид деятельности (activity) - это определенный тип работы, выполняемый в процессе разработки ПО. Разные виды деятельности часто требуют разные профессиональные навыки и выполняются разными специалистами. Например, управление проектом выполняется менеджером проекта, кодирование - программистом, тестирование - тестировщиком. Есть виды деятельности, которые могут выполняться одними и теми же специалистами - например, кодирование и проектирование (особенно в небольшом проекте) часто выполняют одни и те же люди.
В рамках одной фазы может выполняться много различных видов деятельности. Кроме того, один вид деятельности может выполняться на разных фазах - например, тестирование: на фазе анализа и проектирования можно писать тесты и налаживать тестовое окружение, при разработке и перед сдачей производить, собственно, само тестирование. На настоящий момент для сложного программного обеспечения используются многомерные модели процесса, в которых отделение фаз от видов деятельности существенно облегчает управление разработкой ПО.
Виды деятельности, фактически, присутствуют, под разными названиями, в каждом методе разработки ПО. В RUP они называются рабочими процессами (work flow), в CMM - ключевыми областями процесса (key process area).
В то же время, существуют традиционные названия, принятые в том или ином методе (в той или иной модели). Рассмотрим их более подробно:
1. Водопадная (каскадная) модель - это модель процесса разработки программного обеспечения, в которой процесс разработки выглядит как поток, последовательно проходящий фазы анализа требований, проектирования, реализации, тестирования, интеграции и поддержки. Эта модель является стандартным циклом жизни ПО. Водопадная (каскадная) модель была предложена в 1970 году Винстоном Ройсом. Фактически, впервые в процессе разработки ПО были выделены различные шаги разработки и поколеблены примитивные представления о разработке ПО в виде анализа системы и ее кодирования (рис.1). Достоинством водопадной модели явилось ограничение возможности возвратов на произвольный шаг назад (например, от тестирования - к анализу, от разработки - к работе над требованиями), существенно увеличивающих стоимость проекта и сроки его выполнения. Возвраты допустимы только на предыдущий шаг, например, от тестирования к кодированию, от кодирования к проектированию и т.д. Кроме того, в рамках этой модели было введено прототипирование, то есть предлагалось разрабатывать систему дважды, чтобы уменьшить риски разработки. Первая версия - прототип - позволяет увидеть основные риски и обосновано принять главные архитектурные решения. На создание прототипа отводилось до одной трети времени всей разработки.
Рис.1. Водопадная (каскадная) модель процесса разработки ПО
К недостаткам водопадной модели относят:
· отождествление фаз и видов деятельности, что вызывает трудности поддержки итеративного процесса разработки;
· требование полного окончания фазы-деятельности, закрепление результатов в виде подробного исходного документа (технического задания, проектной спецификации);
· интеграция всех результатов разработки происходит в конце, вследствие чего интеграционные проблемы дают о себе знать слишком поздно;
· пользователи и заказчик не могут ознакомиться с вариантами системы во время разработки, не могут повлиять на процесс создания системы, что приводит к увеличению рисков непонимания между разработчиками и пользователями/заказчиком;
· модель неустойчива к сбоям в финансировании проекта или перераспределению денежных средств, начатая разработка, фактически, не имеет альтернатив "по ходу дела".
Водопадная модель вошла в качестве составной части в другие модели и методологии, например, в MSF.
Сегодня этот способ разработки ПО не актуален: он применяется в основном для небольших проектов или при разработке типовых систем, где итеративность не так востребована.
2. Спиральная (циклическая) модель. Была предложена Бэри Боемом в 1988 году для преодоления недостатков водопадной модели, прежде всего, для лучшего управления рисками. Спиральная модель наиболее реально отображает разработку программного обеспечения; каждый последующий шаг определяется только после общения с заказчиком; использует моделирование для уменьшения риска и совершенствования программного изделия.
В спиральной модели разработки ПО каждый виток является определенной фазой разработки, в его рамках может осуществляться много различных видов деятельности. Изначально количество витков не определено, каждый виток может стать последним при разработке системы, при его завершении составляются планы следующего витка. Последовательность витков в спиральной модели процесса разработки ПО может быть следующей: на первом витке принимается решение о целесообразности создания ПО, на следующем определяются системные требования, потом осуществляется проектирование системы и т.д. Витки могут иметь и иные значения.
Каждый виток имеет следующую структуру (секторы):
определение целей, ограничений и альтернатив проекта;
оценка альтернатив, оценка и разрешение рисков; возможно использование прототипирования (в том числе создание серии прототипов), симуляция системы, визуальное моделирование и анализ спецификаций; фокусировка на самых рисковых частях проекта;
разработка и тестирование - здесь возможна водопадная модель или использование иных моделей и методов разработки ПО;
планирование следующих итераций - анализируются результаты, планы и ресурсы на последующую разработку, принимается (или не принимается) решение о новом витке; анализируется, имеет ли смысл продолжать разрабатывать систему или нет; разработку можно и приостановить, например, из-за сбоев в финансировании; спиральная модель позволяет сделать это корректно.
Использование данной модели достаточно эффективно, так как обеспечивается взаимодействие между заказчиком и разработчиком на всех этапах разработки. Очередность этапов подобна шагам в каскадной модели, но на каждом этапе помимо разработки вдобавок происходит анализ, оценка альтернатив и спецификаций и тестирование. При использовании спиральной модели снижаются риски, что очень важно при разработке больших систем.
В то же время, спиральную модель нецелесообразно применять в проектах с небольшой степенью риска, с ограниченным бюджетом, для небольших проектов.
Спиральная модель не нашла широкого применения в индустрии и важна, скорее в историко-методологическом плане: она является первой итеративной моделью, имеет красивую метафору - спираль, - и, подобно водопадной модели, использовалась в дальнейшем при создании других моделей процесса и методологий разработки ПО.
3. Компонентная (пошаговая) модель. Основана на спиральной модели. Предполагает повторное использование созданных компонент и постепенное пополнение библиотеки компонент. Компонента ПО, созданная в проекте одним разработчиком и предоставленная для использования другому разработчику, оказывается рабочим продуктом ( (work product) - любой артефакт, произведенный в процессе разработки ПО, например, файл или набор файлов, документы, составные части продукта, сервисы, процессы, спецификации, счета и т.д.), т.е. отдельно оформленный результат промежуточной или окончательной работы).
Для того, чтобы полученную компоненту мог использовать другой разработчик, ее надо минимально протестировать, поправить имена интерфейсных классов и методов, что-то лишнее, не имеющее отношение к функциональности данной компоненты, может быть убрать, разделить public и private и т.д. Объем этих дополнительных работ существенно возрастает, если компонента должна быть представлена для использования в разработке, например, в другой центр разработки. Таким образом, изготовление хороших промежуточных рабочих продуктов очень важно для успешности проекта, но требует дополнительной работы от их авторов. Работать одному, не предоставляя рабочих продуктов - легче и для многих предпочтительнее. Но работа в команде требует накладных издержек, в том числе и в виде трат на создание промежуточных рабочих продуктов.
Преимуществами компонентной модели являются сокращение времени и стоимости разработки ИС. Основной задачей модели является тестирование и интеграция. Компонентная модель подразумевает реализацию ПО из готовых компонентов, тем самым риск системных ошибок снижается.
4. Формальная модель. Принцип данной модели заключается в том, что после спецификации требований разработчик сразу же приступает к трансляции требований в программный код. Этот подход к разработке доступен только опытным разработчикам, так как в результате система будет тестироваться в целом и должна полностью соответствовать спецификации требований.
5. Эволюционная модель. Эта модель подразумевает постепенную разработку, но плохую структурированность и документацию. Происходит разработка так называемых под-проектов, что приводит к частичной разработке всей системы. Такой подход обеспечивает постоянный учет требований заказчика.
По мнению Томаса Алва, разработчика из Эдисона, возможно применение следующих моделей процесса разработки ПО:
каскадная модель (описана выше);
"V-Model" (рис.2) - унаследовала структуру "шаг за шагом" от каскадной модели. Особенностью модели является то, что она направлена на тщательную проверку и тестирование продукта, находящегося уже на первоначальных стадиях проектирования. Главная идея данной модели - validation and verification.
Рис.2. "V-Model" процесса разработки ПО
Стадия тестирования проводится одновременно с соответствующей стадией разработки, например, во время кодирования пишутся модульные тесты. V-образная модель применима к системам, в которых особенно важно бесперебойное функционирование, например, прикладные программы в клиниках для наблюдения за пациентами, интегрированное ПО для механизмов управления аварийными подушками безопасности в транспортных средствах и т.п. V-модель используется когда требуется тщательное тестирование продукта; для малых и средних проектов, где требования четко определены и фиксированы; в условиях доступности инженеров необходимой квалификации, особенно тестировщиков;
"Incremental Model" (инкрементная модель) (рис.3) - в ней полные требования к системе делятся на различные сборки. Терминология часто используется для описания поэтапной сборки ПО. Имеют место несколько циклов разработки, и вместе они составляют жизненный цикл "мульти-водопад". Цикл разделен на более мелкие легко создаваемые модули. Каждый модуль проходит через фазы определения требований, проектирования, кодирования, внедрения и тестирования.
Рис.3. Инкрементная модель процесса разработки ПО
Процедура разработки по инкрементной модели предполагает выпуск на первом большом этапе продукта в базовой функциональности, а затем уже последовательное добавление новых функций, так называемых "инкрементов". Процесс продолжается до тех пор, пока не будет создана полная система. Инкрементные модели используются там, где основные требования к системе четко определены и понятны, в то же время некоторые детали могут дорабатываться с течением времени; требуется ранний вывод продукта на рынок; есть несколько рисковых "фич" или целей;
- "RAD Model" (rapid application development model или быстрая разработка приложений) - это разновидность инкрементной модели, в которой компоненты или функции разрабатываются несколькими высоко квалифицированными командами параллельно, будто несколько мини-проектов (рис.4).
Рис.4. "RAD Model" процесса разработки ПО
Временные рамки одного цикла жестко ограничены. Созданные модули затем интегрируются в один рабочий прототип. Синергия позволяет очень быстро предоставить клиенту для обозрения что-то рабочее с целью получения обратной связи и внесения изменений. Модель быстрой разработки приложений включает бизнес-моделирование: определение списка информационных потоков между различными подразделениями; моделирование данных: информация, собранная на предыдущем этапе, используется для определения объектов и иных сущностей, необходимых для циркуляции информации; моделирование процесса: информационные потоки связывают объекты для достижения целей разработки; сборку приложения: используются средства автоматической сборки для преобразования моделей системы автоматического проектирования в код; тестирование: тестируются новые компоненты и интерфейсы. RAD-модель используется только при наличии высококвалифицированных и узкоспециализированных архитекторов. Она может быть выбрана при уверенном знании целевого бизнеса и необходимости срочного производства системы в течение 2-3 месяцев;
"Agile Model" (гибкая методология разработки) (рис.5) - заказчик после каждой итерации может наблюдать результат и понимать, удовлетворяет он его или нет. Это одно из преимуществ гибкой модели.
Рис.5. Гибкая модель процесса разработки ПО
К недостаткам гибкой модели относят то, что из-за отсутствия конкретных формулировок результатов сложно оценить трудозатраты и стоимость, требуемые на разработку. Эта модель подходит для больших или нацеленных на длительный жизненный цикл проектов, постоянно адаптируемых к условиям рынка. Использовать Agile можно тогда, когда потребности пользователей постоянно меняются в динамическом бизнесе; изменения на Agile реализуются за меньшую цену из-за частых инкрементов; в отличие от модели водопада, в гибкой модели для старта проекта достаточно лишь небольшого планирования;
"Iterative Model" (итеративная или итерационная модель) - не требует для начала полной спецификации требований. Создание начинается с реализации части функционала, становящейся базой для определения дальнейших требований. Этот процесс повторяется. Версия может быть неидеальна, главное, чтобы она работала. Примером итерационной разработки может служить распознавание голоса. Первые исследования и подготовка научного аппарата начались давно, в начале - в мыслях, затем - на бумаге. С каждой новой итерацией качество распознавания улучшалось. Тем не менее, идеальное распознавание еще не достигнуто, следовательно, задача еще не решена полностью. Использовать итеративную модель оптимально тогда, когда требования к конечной системе заранее четко определены и понятны; проект большой или очень большой; основная задача должна быть определена, но детали реализации могут эволюционировать с течением времени;
"Spiral Model" (спиральная модель) (рис.6) - похожа на инкрементную, но с акцентом на анализ рисков. Она хорошо работает для решения критически важных бизнес-задач, когда неудача несовместима с деятельностью компании, в условиях выпуска новых продуктовых линеек, при необходимости научных исследований и практической апробации. Подробное описание спиральной модели дано ранее.
Рис.6. Спиральная модель процесса разработки ПО
3. Моделирование процесса разработки программного обеспечения
На ранних этапах развития программной инженерии считалось, что удачная модель процесса разработки ПО - самое главное, что способствует успеху разработки. Позднее пришло осознание, что существует множество других аспектов (принципы управления и разработки, структуру команды и т.д.), которые должны быть определены согласовано друг с другом. И стали развиваться интегральные методологии разработки.
Моделирование - это способ исследования процессов разработки программного обеспечения с использованием объекта-модели, создание образов действий, ориентированных на внедрение в процесс современных методов разработки систем.
Моделирование процессов позволяет улучшить представление о разработке обеспечения, предусмотреть критические ситуации, провести анализ перспектив будущей системы. Для того чтобы смоделировать какой-либо процесс, потребуется его структурная схема.
Моделирование может применяться во всех перечисленных моделях разработки.
Моделирование может производиться и на этапе постановки задачи, как заказчиком, так и разработчиком. Здесь спектр задач моделирования весьма велик. Например, заказчик предъявил особые требования к дизайну сайта и сделал макеты страниц в системе Axure RP Pro. Если есть готовая модель web-страниц, то нет необходимости перечислять требования к дизайну страниц в техническом задании, достаточно просто сослаться на модель.
На этапе анализа требований моделирование - хороший способ обезопасить себя как заказчика, ведь некоторые детали можно уточнить у заказчика. Примером может служить случай, когда дизайн сайта описан в словесной форме и, чтобы уточнить, что именно имел в виду заказчик, можно воспользоваться системой Axure RP Pro 7.0. Также необходимо поступать и с графическим интерфейсом программ, ведь графическая часть плохо описывается словесно. Если предметом разработки является компьютерная игра, то, возможно необходимы 3D модели элементов игры.
Моделирование активно применяется на этапе проектирования программного продукта. Простейшим примером моделирования является составление блок-схемы, которая является модель алгоритма решения задачи. Примером системы для моделирования на этапе проектирования может служить Astah - программа, предназначенная для создания UML диаграмм.
UML (Unified Modeling Language) - унифицированный язык моделирования, активно применяется при объектно-ориентированном анализе. Цель UML наглядное проектирование архитектуры программного продукта. В стандарт UML входят следующие виды диаграмм:
диаграмма вариантов использования;
диаграмма классов;
диаграмма компонентов и другие.
Диаграмма вариантов использования (use case diagram) состоит из экторов (англ. Actor) и претендентов. Эктор отражает объект, а претендент - действие. Диаграмма хорошо подходит для моделирования практически любых процессов. Пример диаграммы приведён на рисунке 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.
Заключение
Модели процесса разработки ПО устанавливают правила игры, которых должна придерживаться команда разработчиков, чтобы не "влазить в чужие тапки", по возможности избегать конфликтов и понимать, что уже сделано и что предстоит сделать. В современной практике модели разработки программного обеспечения многовариантны. Нет единственно верной для всех проектов, стартовых условий и моделей оплаты. Даже самая популярная модель не может применяться повсеместно из-за неготовности некоторых заказчиков или невозможности гибкого финансирования. Модели частично пересекаются в средствах и в чем-то похожи друг на друга.
По сути существуют всего два больших подхода:
сделать систему целиком в деталях (waterfall, RUP/OpenUP etc);
сделать компонент системы из-за невозможности представить всю систему (гибкие и быстрые модели, хотя "быстрость" не гарантирует того, что полноценный продукт появится раньше, чем если бы его делали по "водопаду").
При этом следует помнить, что весь современный уход в "гибкость" вызван высокой конкурентностью рынка ИТ-продуктов. Пока одни думают "как сделать сразу всё правильно", другие уже выпустили "хоть что-то" и заняли место в своём сегменте.
Для составления более точной спецификации требований, которая лежит в основе модели продукта и дальнейшего его кодирования предназначены системы моделирования процессов разработки программного обеспечения, играющие немаловажную роль в программной инженерии. Рассмотрев несколько систем, можно сделать вывод: методы разработки программного обеспечения развиваются и прогрессируют, конкурируя между собой.
Если говорить об эффективных моделях разработки процессов, то следует учитывать такие признаки как частота общения с заказчиком, наличие и полнота документации и др.
Список литературы
1. Брукс Фредерик Серебряной пули нет: сущность и акциденция в программной инженерии // Мифический человеко-месяц или как создаются программные системы [Электронный ресурс]. - Режим доступа: https: // www.litmir. me/br/? b=104516
2. Кознов Д.В. Введение в программную инженерию. Электронная книга. - Режим доступа: https: // www.intuit.ru/goods_store/ebooks/8432
3. Маркунин Т. Моделирование процессов разработки ПО и создание сайтов процессов с помощью Rational Method Composer [Электронный ресурс]. - Режим доступа: https: // www.ibm.com/developerworks/ru/library/r-rmc-model/index.html
4. Петрухин В.А., Лаврищева Е.М. Методы и средства инженерии программного обеспечения. Электронная книга. - Режим доступа: https: // www.intuit.ru/studies/courses/2190/237/lecture/6116
5. Советов Б.Я., Яковлев С.А. Моделирование систем: учебник для вузов, 3-е издание перераб. и доп. - М.: Высш. шк., 2001. - 343 стр.: ил. [Электронный ресурс]. - Режим доступа: http://www.sciyouth.ru/ElBibl/2015_16_uch_year/2_kurs_magistratura/Metody_issledovaniya_i_modelirovaniya_inform_proc_i_tehnologiy/%D0%90%D1%80%D1%85%D0%B8%D0%B2/%D0%9C%D0%BE%D0%B4%D0%B5%D0%BB%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5%20%D1%81%D0%B8%D1%81%D1%82%D0%B5%D0%BC. pdf
6. Ткачева А.Ю., Абрамова О.Ф. Системы моделирования процессов разработки программного обеспечения // VII Международная студенческая электронная научная конференция "Студенческий научный форум" - 2015 [Электронный ресурс]. - Режим доступа: https: // www.scienceforum.ru/ 2015/857/9662
7. Thomas Alva. Ещё раз про семь основных методологий разработки [Электронный ресурс]. - Режим доступа: https: // habrahabr.ru/ company/edison/blog/269789/
Размещено на Allbest.ru
Подобные документы
Понятие программной инженерии как применения определенного систематического измеримого подхода при разработке, эксплуатации и поддержке программного обеспечения. Модели процесса разработки программного обеспечения. Управление программными проектами.
презентация [870,6 K], добавлен 12.11.2014Понятие программного обеспечения, вопросы его разработки и использования. Общая характеристика системного программного обеспечения и работа операционной системы. Специфика процесса управления разработкой программного обеспечения и его особенности.
курсовая работа [636,2 K], добавлен 23.08.2011Цели и задачи программной инженерии. Понятие программного обеспечения. Шесть принципов эффективного использования программного обеспечения. Виды программного обеспечения: общесистемное, сетевое и прикладное. Принципы построения программного обеспечения.
курсовая работа [30,4 K], добавлен 29.06.2010Проблема надежности программного обеспечения, ее показатели и факторы обеспечения. Методы контроля процесса разработки программ и документации, предупреждение ошибок. Этапы процесса отладки ПО, приемы структурного программирования и принцип модульности.
презентация [379,5 K], добавлен 30.04.2014Понятие технологии разработки программного обеспечения и модели жизненного цикла. Сущность объектно-ориентированного подхода. Строительные блоки, общие механизмы языка моделирования UML, диаграммы классов, состояний, взаимодействий и компонентов.
курсовая работа [262,5 K], добавлен 10.07.2014Несоответствие процессов разработки программного обеспечения международным стандартам. Фазы, развитие вычислительной инфраструктуры. История развития компьютерных систем. Этапы разработки программ и их тестирование. Ошибки в программном обеспечении.
реферат [176,2 K], добавлен 27.08.2009Понятие и ключевое отличие распределенной разработки программного обеспечения, его достоинства и недостатки. Концептуальное решение и выбор типа разработки. Особенности программного обеспечения с открытым исходным кодом. Идея и развитие Open Source.
курсовая работа [97,7 K], добавлен 14.12.2012Оценка финансовой, стратегической ценности и уровня рисков проекта. Классификация проектов: "свой" заказчик, продукт под заказ, тиражируемый продукт, аутсорсинг. Организация процесса разработки программного обеспечения, методологии его проектирования.
презентация [82,8 K], добавлен 07.12.2013Разработка программного обеспечения для моделирования процесса абсорбции; расчёт характеристик при варьировании температуры. Требования к программному обеспечению; структуры данных и алгоритмы в программе; дисплейные фрагменты, внешний вид приложения.
курсовая работа [2,8 M], добавлен 20.11.2012Технологии разработки программного обеспечения. Процедура постановки задачи, определения требований. Последовательность действий логической, разветвленной и циклической структуры. Терминология программирования. Этапы создания программного продукта.
презентация [793,8 K], добавлен 15.11.2010