6.Понятие унифицированного процесса разработки по. Фазы проекта по rup.

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

подготовительную работу - выбор модели ЖЦ, стандартов, методов и средств разработки и также составления плана работ;

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

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

проектирование архитектуры ПО - определение структуры ПО, документирование интерфейсов его компонентов, разработку предварительной версии пользовательской документации;

ПО - подробное описание компонентов ПО и интерфейсов между ними, обновление пользовательской документации;

кодирование и тестирование ПО, интеграция ПО, установка и приемка ПО. 7.Понятие экстремального программирования.

Методология разработки програмного обеспечения eXtreme Programming (изобретатель - Kent Beck) получает всебольшее признание благодаря максимальному упрощению процессов проектирования и непосредственной разработки програмных продуктов в среде с быстро изменяющимися требованиями.Существует всего лишь 5 ценностей экстремального программирования: простота, общение, обратная связь, смелость и уважение ("уважение" добавилось в последнейредакции ХР). На реализию этих основных ценностей и направлены 12 практическихметодик ХР. Рассмотрим ихв небольшом приближении.

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

Процесс планирования (planning game). В ХР планирование - это основная часть разработки. То, что планы могут внезапно поменяться, учитывается еще в самом начале.

Аппетит заказчика приходит во время еды и нужно всегда держать ситуацию под контролем. Общение с заказчиком должно происходить как можно чаще. Это позволит точнее оценить сроки выполнения задач и внести необходимые коррективы в случае необходимости.Быстрый выпуск версий (small releases). Как бы красиво не был описан продукт, всепрелести его использования можно понять только работая с ним. Методика быстрого выпуска версий позволяет понять, чего же хочет заказчик, обеспечивая ранний выпуск рабочих версий продукта.Простота реализации (simple design). ХР предлагает делать код программы простым. 3ачем усложнять себе жизнь,если простую программу легче понимать и поддерживать и она менее подвержена ошибкам.Опережающее тестирование (test-driven development). Экстремальное программирование рекомендует проверять.

существующий код как можно чаще. Именно поэтому и практикуется данная методика. Тесты пишутся еще до того, как будет написан кусок кода. Это позволяет лучше понимать поставленные задачи и предоставляет возможность проверить код сразу, как только он будет написан.Рефакторинг (design improvement). Добавление новой функциональности и увеличение объема кода усложняет разработку и поиск ошибок. Решением этой проблемы является постоянная переработкa (refactoring) кода. Рефакторинг - очень мощная и полезная вещь и заслуживает нето что отдельной статьи, а целых книг.Парное программирование (pair programming). Периодический просмотр чужого кода положительно влияет на его качество. Этот принцип лежит в основе парного программирования. Заключается оно в том, что два программиста одновременно работают за одним компьютером. Как ни странно, затраты на разработку не увеличиваются в два раза, а остаются приблизительно на том же уровне. С другой стороны при парном программировании повышается качество кода, осуществлявтся неявная и явная передача знаний, а также проиходит постоянное общение между разработчиками. Совместное владение кодом (collective code ownership). Чаще всего при разработке програмных продуктов за определенную часть кода отвечает один человек. Отпуск, увольнение или же болезнь (прости, Господи) одного из программистов может сильно затормозить разработку продукга. Именно поэтому в ХР за один кусок кода отвечаетне менее двух человек и любой программист может внести изменения в любую частьпрограмного кода.Продолжающаяся интеграция (continuous integration).Команды ХР-программистов создают новые билды продукта несколько раз в день. Это позволяет всем программистам быть в курсе происходящего и предотвратить проблемы интеграции с другими продукгами и частями кода.40-часовая неделя (forty houг week). Ради дела люди спопобны на многое, но экстремальное программирование категорически против самопожертвования разработчиков.Человек должен отдыхать, именно тогда он достигнет максимальной производительности в рабочее время. Контакт с заказчиком (on-sitecustomer). Проблема, с которой часто сталкиваются разработчики, - это незнание предметнои ооласти, особенно,если она узкоспециализированная. Данная методика учит привлекать заказчика к процессу разработки для помощи в решении специализированных задач. Если возможности привлечь заказчика нет, иногда бывает полезным найм специалиста со стороны, работающего в необходимой отрасли.Стандарты кодирования (сing standard). Для успешной работы над проектом ХР ввитает требование применения стандартов при кодировании. Это в свою очередь обеспечивает успешность методик как совместное владение кодом и парное программирование. Да и вообще стандарты не для того, чтобы просто существовать, а для того, чтобы их придерживались.Непротиворечивость всех этих методик позволяет заметно повысить качество продукта и выпустить его точно в срок. Еще одна прелесть ХР - общение и повышение квалификации программистов без отрыва от производства.Ну что ж, экстремальное программирование - в массы. 8.Определение требований к программному обеспечению. Анализ предметной области. Техническое задание.

Этап постановки задачи - один из наиболее ответственных этапов. На этом этапе формулируют основные требования к разрабатываемому ПО.Основные эксплуатационные требования к ПП.правильность - функционирование в соответствии с ТЗ; универсальность - обеспечение правильной работы прилюбых допустимых данных и защиты от неправильных данных;

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

точность результатов - обеспечение погрешности результатов не выше заданной; защищенность - обеспечение конфиденциальности информации;

программная совместимость - возможность совместного функционирования с другим ПО;

аппаратная совместимость -возможность совместного функционирования с некоторым оборудованием;

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

реентерабельность - возможность «параллельного» использования несколькими процессами.

Анализ предметной области

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

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

Анализом предметной области занимаются системные аналитики или бизнес-аналитики.

Техническое задание

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

Как правило, этапу составления технического задания предшествует проведение обследования предметной области, которое завершается созданием аналитического отчета. Именно аналитический отчет (или аналитическая записка) ложится в основу документа Техническое задание