Методы и средства выявления и представления требований к разработке ПО

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

Рубрика Программирование, компьютеры и кибернетика
Вид дипломная работа
Язык русский
Дата добавления 24.08.2016
Размер файла 2,4 M

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

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

Каждый бизнес-процесс на нотации может быть декомпозирован (разбит на детальные бизнес-процессы).

Пример блок-схемы представлен на рисунке 13. Возможный инструмент для моделирования: Visio.

Рисунок 18 Пример блок-схемы

Процедура (Cross Functional Flowchart, функциональная блок-схема) - нотация для отображения процесса на нижнем уровне бизнес-модели.

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

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

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

На Процедуре так же могут использоваться решения (условия) для ветвления бизнес-процесса.

Пример моделирования Процедуры представлен на рисунке 14. Возможный инструмент для моделирования: Visio.

Рисунок 19 Пример моделирования процедуры

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

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

ЗАКЛЮЧЕНИЕ

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

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

2) Анализ основных типов методологий разработки и этапов разработки позволил предложить обобщенный процесс выявления и представления требований, определить место данного процесса в жизненном цикле проекта.

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

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

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

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

БИБЛИОГРАФИЧЕСКИЙ СПИСОК

1. Software Engineering - Guide to the Software Engineering Body of Knowledge (SWEBOK) // TECHNICAL REPORT ISO/IEC TR 19759 IEEE. First edition 2005- 9-15. [Electronic resource]. - ISO/IEC 2005. - Mode of access: http://profs.etsmtl.ca/claporte/English/Enseignement/CMU_SQA/Lectures/Corpus/SWEBOK_ISO_IEC_TR_19759_2005%28E%29.pdf (Date of access: 01.12.2014).

2. Карл И. Вигерс. Разработка требований к программному обеспечению, 2004.: 2-е изд., перераб. и доп. Пер. с англ. - М.: Русская редакция. - 554 c.

3. Орлик C. Основы программной инженерии: [Электронный ресурс]. - URL: http://swebok.sorlik.ru/1_software_requirements.html (дата обращения: 24.12.2014)

4. Системная и программная инженерия. Процессы жизненного цикла. Разработка требований, ISO/IEC/IEEE 29148:2011 [Электронный ресурс]. - URL: http://www.iso.org/iso/ru/catalogue_detail.htm?csnumber=45171 (дата обращения: 24.12.2014)

5. Jacobson I., Booch G., and Rumbaugh J. The Unified Software Development Process. Reading, MA.: Addison-Wesley,1999.

6. IEEE Standard Glossary of Software Engineering Terminology, [Electronic resource]. - ISO/IEC 2005. - Mode of access: http://ieeexplore.ieee.org/xpl/mostRecentIssue.jsp?punumber=2238 (Date of access: 01.12.2014).

7. Маглинец Ю.А. Анализ требований к информационным системам, 2007 //Конспект лекций, Красноярск,СФУ

8. IT Infrastructure Library ITIL® (ITIL 2011, ITIL V3 & V2), ISO 20000 and IT Service Management (ITSM) WIKI. [Electronic resource]. - Mode of access: http://wiki.en.it-processmaps.com/index.php/ITIL_2011 (Date of access: 01.12.2014).

9. Software Engineering -- Software product Quality Requirements and Evaluation (SQuaRE) -- Quality Requirements, ISO/IEC 25030:2007 [Electronic resource]. - Mode of access: http://www.iso.org/iso/catalogue_detail.htm?csnumber=35755 (Date of access: 01.12.2014).

10. Kossiakoff A., Sweet W. N., Seymour S. J., Biemer S. M. Systems Engineering Principles and Practice. -- 2-е изд. -- Hoboken, New Jersey: A John Wiley & Sons, 2011. -- 599 с. -- ISBN 978-0-470-40548-2.

11. Software Engineering -- Software product Quality Requirements and Evaluation (SQuaRE) -- Quality Requirements, ISO/IEC/IEEE 29148:2011 [Electronic resource]. - Mode of access: http://www.iso.org/iso/ru/catalogue_detail.htm?csnumber=45171 (Date of access: 01.12.2014).

12. ГОСТ Р ИСО/МЭК 12207, 2010: [Электронный ресурс]. - URL: http://labsm.ru/pluginfile.php/969/mod_resource/content/2/12207.pdf (дата обращения: 12.12.2014)

13. Guide to the Systems Engineering Body of Knowledge, SEbok.: [Electronic resource]. - Mode of access: http://sebokwiki.org/wiki/Guide_to_the_Systems_Engineering_Body_of_Knowledge_%28SEBoK%29 (Date of access: 01.12.2014).

14. Object Management Group, OMG Essence, 2014: [Electronic resource]. - Mode of access: http://www.omg.org/spec/Essence/1.0/ (Date of access: 01.12.2014).

15. Systems Engineering Principles and Practice, 2011: [Electronic resource]. - Mode of access: http://www.psconsultech.com/yahoo_site_admin/assets/docs/di-0967.132122129.pdf (Date of access: 01.12.2014).

16. Химонин Ю.И., Сбор и анализ требований к программному продукту, 2009.

17. Википедия, свободная энциклопедия: [Электронный ресурс]. - https://ru.wikipedia.org/wiki/%D0%A1%D1%82%D0%B5%D0%B9%D0%BA%D1%85%D0%BE%D0%BB%D0%B4%D0%B5%D1%80 ((дата обращения: 20.12.2014)

18. Википедия «Академик», 2010: [Электронный ресурс]. - URL: http://dic.academic.ru/dic.nsf/ruwiki/232465 (дата обращения: 12.12.2014)

19. Технологии программирования, НИТПУ, 2014: [Электронный ресурс]. - URL: http://lms2.tpu.ru/pluginfile.php/42416/mod_resource/content/0/Contents/3.pdf (дата обращения: 12.12.2014)

20. Лешек А. Мацяшек. Анализ требований и проектирование систем. Разработка информационных систем с использованием UML: Пер. с англ. - М.: Вильямс, 2002. - 143 с.

21. Бариленко В. И. и др. Основы бизнес -- анализа: учебное пособие. / под ред. В. И. Бариленко. -- М.: КНОРУС, 2014. -- 272 с.

22. Бариленко В. И. Бизнес-анализ как важный вид консалтинговых услуг // РИСК: Ресурсы, Информация, Снабжение, Конкуренция. -- № 4. -- 2012. -- С.202-207.

23. Конрад Карлберг Бизнес-анализ с использованием Excel. Решение бизнес-задач, 4-е издание = Business Analysis: Microsoft Excel. -- М.: «Вильямс», 2013.

24. Основы бизнес - анализа: учебное пособие. / под ред. В.И. Бариленко. - М.: КНОРУС, 2013.

25. Паклин Н.Б. Орешков В.И. Бизнес-аналитика: от данных к знаниям, 2013.

26. Э. Халл, К. Джексон, Д. Дик. Разработка и управление требованиями // Практическое руководство пользователя. - 2-е изд., 2005.

27. Г. Буч, Р. Максимчук, М. Энгл, Б. Янг, Д. Коналлен, К.Хьюстон. Объектно-ориентированный анализ и проектирование с примерами приложений,2008. 3-е изд.

28. Д. Арлоу, А. Нейштадт. UML 2 и Унифицированный процесс. Практический объектно-ориентированный анализ и проектирование, 2008.

29. A Guide to the Business Analysis Body of Knowledge® (BABOK® Guide) IIBA (Author), Kevin Brennan (Editor). International Institute of Business Analysis; 2nd edition (March 31, 2009). ISBN: 978-0981129211.

30. М. Фаулер. UML. Основы, 2005 - 3-е изд.

ПРИЛОЖЕНИЯ

Приложение А

Графический материал

Рисунок А1 - Отображение графического материала на слайде 1

Рисунок А2 - Отображение графического материала на слайде 2

Размещено на Allbest.ru


Подобные документы

Работы в архивах красиво оформлены согласно требованиям ВУЗов и содержат рисунки, диаграммы, формулы и т.д.
PPT, PPTX и PDF-файлы представлены только в архивах.
Рекомендуем скачать работу.