Глава 5. Разработка и виды туристических программ Изначальной функцией туристических фирм является планирование туров. В процессе выполнения этой функции создается конкурентоспособный и привлекательный туристский продукт.Для того чтобы его создать, необходимо

Один из подходов к разработке ПО в рамках спиральной модели ЖЦ – получившая широкое распространение методология (технология) быстрой разработки приложений RAD (Rapid Application Development) . Данная модель очень хорошо подходит к разработке учебных программ, т.к. включает в себя три составляющие:

Ø небольшую команду программистов (от 2 до 10 человек);

Ø короткий, но тщательно проработанный производственный график (от 2 до 6 мес.);

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

Рассмотрим данную модель более подробно. Команда разработчиков должна представлять собой группу профессионалов, имеющих опыт в анализе, проектировании, генерации кода и тестировании ПО с использованием CASE-средств, способных хорошо взаимодействовать с конечными пользователями и трансформировать их предложения в рабочие прототипы. Жизненный цикл ПО по методологии RAD состоит из четырёх фаз (рисунок 21):

1. Анализа и планирования требований;

2. Проектирования;

3. Построения;

4. Внедрения.

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

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

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

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

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

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

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

Результатом фазы является готовая система, удовлетворяющая всем согласованным требованиям.

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

Технология RAD (как и любая другая) не может претендовать на универсальность, она хороша в первую очередь для относительно небольших проектов, разрабатываемых для конкретного заказчика. Она неприменима для разработки операционных систем; сложных расчетных программ с большим объемом программного кода и сложными уникальными алгоритмами управления; приложений, в которых отсутствует ярко выраженная интерфейсная часть, наглядно определяющая логику работы системы (приложения реального времени), так как итерационный подход предполагает, что несколько первых версий не будут полностью соответствовать требованиям.

В заключение перечислим основные принципы технологии RAD:

Ø разработка приложений итерациями;

Ø необязательность полного завершения работ на каждом этапе ЖЦ;

Ø обязательное вовлечение пользователей на этапе разработки;

Ø использование прототипирования, позволяющего выяснить и удовлетворить все требования конечного пользователя;

Ø тестирование и развитие проекта одновременно с разработкой;

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

Контрольные вопросы к главе 3:

1. Что такое стандартизация и сертификация программного продукта?

2. Какие существуют типы стандартов?

3. Перечислите наиболее известные стандарты жизненного цикла, которые использовались для разработки программного обеспечения?

4. Что такое жизненный цикл ПО?

5. Перечислите основные этапы жизненного цикла ПО. Что такое процесс, действие, задача?

6. Какие типы процессов и конкретные процессы вы запомнили?

7. Расскажите об основных инженерных процессах жизненного цикла ПО.

8. Что такое модель жизненного цикла ПО? Дайте определения основных понятий, связанные с понятием «модель».

9. Какие типы моделей вы знаете? В чем их преимущества, недостатки, область применимости?

10.Что вы можете сказать об особенностях каскадной модели жизненного цикла?

11.В чем отличие обобщенной каскадной модели от базовой?

12.Что вы можете сказать об особенностях спиральной модели жизненного цикла?

13.Перечислите составляющие технологии RAD. Для разработки каких типов ПО можно применять технологию RAD?

14.Опишите основные фазы жизненного цикла по технологии RAD.

15.Перечислите основные принципы технологии RAD.

СПИСОК ЛИТЕРАТУРЫ

1. Аптекарь М. Д., Рамазанов С. К., Фрегер Г. Е. История инженерной деятельности. – Киев, 2003. – 204 с. : ил.

2. Арчибальд Р. Модели жизненного цикла высокотехнологичных проектов. http://www.pmprofy.ru/content/rus/107/1073-article.html

3. Брукс Ф. Мифический человеко-месяц или как создаются программные системы. – СПб. : Символ-плюс, 1999. – 321 с. : ил.

4. Буч Г. Объектно-ориентированное проектирование с примерами применения. – М.: Конкорд, 1992. – 586с. : ил.

5. Буч Г. Объектно-ориентированный анализ и объектно-ориентированное проектирование на С++. – М. : Бином, – 2001. – 558 с. : ил.

6. Вендров А. М. CASE-технологии. Современные методы и средств проектирования информационных систем. – М. : Финансы и статистика, – 1999. – 256 с. : ил.

7. Вирт Н. Алгоритмы + структуры данных = программы: Пер. с англ. – М. : Мир, 1985. – 406 с.: ил.

8. Дал О., Дейкстра Э., Хоор К. Структурное программирование: Пер. с англ. – М.: Мир, 1975. – 247 с. : ил.

9. Дзержинский Ф. Я., Калиниченко И.М. Дисциплина программирования: концепция и опыт реализации методических средств программной инженерии. – М.: ЦНИИ информации и технико-экономических исследований по атомной науке и технике, 1988. – 245 с. : ил.

10. Жоголев Е. А. Технологии программирования. – М. : Научный мир, 2004. – 216 с. : ил.

11. Закон РФ № 149-ФЗ от 29.07.2006. «Об информации, информационных технологиях и защите информации»// Российская газета, № 165 от 27.07.2006 г.

12. Иванова Г. С. Технология программирования: Учебник для вузов. – 2-е изд., стереотип. – М. : Изд-во МГТУ им. Н.Э.Баумана, 2003. – 320 с.: ил.

13. Калянов Г. Н. CASE: Структурный системный анализ (автоматизация и применение). – М. : «Лори», 1996. – 356 с. : ил.

14. Кораблин М. А. Программирование, ориентированное на объекты: Учебное пособие. – Самара: изд-во СГАУ, 1994. – 94 с.

15. Леоненков А. В. Самоучитель UML. – СПб: ВХВ Петербург, – 2001. – 304 с. : ил.

16. Липаев В. В. Качество программного обеспечения. – М.: Финансы и статистика, 1983. – 263 с. : ил.

17. Липаев В. В. Отладка сложных программ: Методы, средства, технология. –М. : Энергоатомиздат, 1993. – 384 с. : ил.

18. Липаев В. В., Филиппов Е. Н. Мобильность программ и данных в открытых информационных системах. – М. : Научная книга, 1997. – 297 с. : ил.

20. Ожегов С. И. Словарь русского языка. – М. : Мир и образование, 2006. – 1328 с.

21. Технология проектирования комплексов программ АСУ/ В. В. Липаев, Л. А. Серебровский, П. Г. Гаганов и др.; Под ред. Ю. В. Афанасьева, В. В. Липаева. – М. : Радио и связь, 1983. – 256 с. : ил.

22. Хювенен Э., Сеппянен Й. Мир ЛИСПа: Пер. с финск. В 2 т. Т.1: Введение в язык Лисп и функциональное программирование.– М. : Мир, 1990. – 447 с. : ил.

23. Хювенен Э., Сеппянен Й. Мир ЛИСПа: Пер. с финск. В 2 т. Т.2: Методы и системы программирования.– М. : Мир, 1990. – 319 с. : ил.

24. Boehm B.«A Spiral Model of Software Development and Enhancement», IEEE Computer, Vol. 21, No. 5, pp. 61–72, 1988.

25. Courtois P. June 1985. On Time and Space Decomposition of Complex Structures. Communications of the ACM vol.28(6), p.596.

26. Criteria for Evaluation of Software. ISO TC97/SC7 #383.

27. Dijktra E. 1979. Programming Considered as a Human Activity. Classics in Software Engineering. New York, NY: Yourdon Press.

28. http://www.pmi.ru/glossary/.

29. http://www.staratel.com/iso/InfTech/DesignPO/ISO12207/ISO12207-99/ISO12207.htm.

30. Microsoft Corporation. Принципы проектирования и разработки программного обеспечения. Учебный курс MCSD: Пер. с англ. – М.: Издательско-торговый дом «Русская редакция», 2000. –608 с. : ил.

31. Parnas D., Clements P., Weiss D. 1983. Enhancing Reusability with Information Hiding. Proceedings of the Workshop on Reusability in Programming. Stratford, CT: ITT Programming. p.241.

32. Rechtin E. October 1992. The Art of Systems Architecting. IEEE Spectrum, vol.29 (10), p.66.

33. Royce W.W. Managing the Development of Large Software Systems. http://facweb.cti.depaul.edu/jhuang/is553/Royce.pdf.

34. Shaw M. October 1984. Abstraction Techniques in Modern Programming Languages. IEEE Software vol.1 (4).

35. Simon H. 1982. The Sciences of the Artificial. Cambridge, MA: The MIT Press. – p.218.

36. Sommerville I. Software engineering. – Addison-Wesley Publishing Company, 1992. p.87.

37. Tesler L. August 1981. The Smalltalk Environment. Byte vol.6(8), p.142.

38. Yonezawa A., Tokoro M. 1987. Objectt-Oriented Concurrent Programming. Cambridge, MA: The MIT Press.

список терминов

В конце 2002 года московское издательство "Лори" выпустило книгу Алистера Коберна (Alistair Cockburn) "Быстрая разработка программного обеспечения". Русское название книги немного удивляет, потому что в оригинале она называется "Agile Software Development" и более правильный перевод звучал бы как "Гибкая разработка ПО". Впрочем, не будем придираться к переводчику, потому что подобных книг на русском языке еще не издавалось.

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

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

Периодически находились люди, которые начинали понимать проблемы создания ПО, но настоящий прорыв происходит именно теперь, после появления экстремального программирования (eXtreme Programming, www.extremeprogramming.com) и создания альянса гибкой разработки ПО (Agile Alliance, www.agilealliance.org). Гибкие методологии ломают стереотипы и полностью изменяют процесс разработки программ. Они изменяют сами принципы организации процесса.

Чем же отличаются гибкие методологии от традиционных? Можно выделить несколько основных отличий:

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

Многие гибкие методологии позволяют использовать сильные черты отдельно взятой команды разработчиков, потому что их можно подстроить под команду. Традиционные методологии заставляют команду подстроиться под себя.

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

Какие бывают методологии, как они влияют на процесс разработки ПО и зачем они вообще нужны? В книгу включены крайне интересные приложения: программирование как построение теорий, применение языковых игр Витгенштейна к разработке ПО, применение методов Мусаши (самурай, живший в 17 веке и написавший книгу "Книга пяти колец") к разработке ПО.

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

Что действительно подкупает, так это исключительная рассудительность автора. Он никогда не заявляет, что его мнение единственно правильное, он всегда аргументирует свою точку зрения и делает это убедительно. Если вы до сих пор не особенно интересовались методологиями при разработке программного обеспечения, то после прочтения книги обязательно заинтересуетесь. Если активно интересовались, но не особенно применяли, то начнете применять.

Для управляющих проектами (Project Manager) и лидеров групп (Team Leader) книга из категории must read. Ваша эффективность, как руководителя, заметно возрастет.

Если говорить о качестве издания, то перевод достаточно хорош, за исключением термина agile. Единственный минус книги - плохая полиграфия, что не редкость для компьютерной литературы. Что удивительно, цена книги при таком качестве тоже не маленькая.

Книгу Алистера Коберна "Быстрая разработка программного обеспечения" можно приобрести в интернет-магазине www.rodina.by (www.rodina.by/book/info/go/6047.html).

Михаил ДУБАКОВ