|
|
ПаскальСиАссемблерJavaMatlabPhpHtmlJavaScriptCSSC#DelphiТурбо Пролог1С Компьютерные сетиСистемное программное обеспечениеИнформационные технологииПрограммирование Linux Unix Алгоритмические языки Аналоговые и гибридные вычислительные устройства Архитектура микроконтроллеров Введение в разработку распределенных информационных систем Введение в численные методы Дискретная математика Информационное обслуживание пользователей Информация и моделирование в управлении производством Компьютерная графика Математическое и компьютерное моделирование Моделирование Нейрокомпьютеры Проектирование программ диагностики компьютерных систем и сетей Проектирование системных программ Системы счисления Теория статистики Теория оптимизации Уроки AutoCAD 3D Уроки базы данных Access Уроки Orcad Цифровые автоматы Шпаргалки по компьютеру Шпаргалки по программированию Экспертные системы Элементы теории информации |
Оценка надежности объектов при разрегулированииДата добавления: 2014-04-22; просмотров: 1981; Нарушение авторских прав
Microsoft Solutions Framework является наиболее сбалансированной технологией, ориентированной на проектные группы малых и средних размеров. MSF не накладывает никаких ограничений на используемый инструментарий и содержит рекомендации весьма общего характера. Однако, эти рекомендации могут быть использованы для построения конкретного процесса, соответствующего потребностям коллектива разработчиков.
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
эксплуатируемых объектов опять устанавливается начальное значение параметра R0 и случайный процесс разрегулирования повторяется вновь (см. рис.).
Рисунок 1. — Качество в жизненном цикле ПС
Требования пользователя к качеству в спецификациях (см. рисунок 2) должны в процессе верификации (проверку того, что ПС разработаны в соответствии со всеми требованиями к нему или что очередной этап разработки выполнен в соответствии с ограничениями, сформулированными на предшествующих этапах ) преобразовываться в требования к внешнему качеству, а затем в требования к внутреннему качеству. Процессы реализации требований к внутреннему качеству должны обеспечивать внешнее качество, а последнее — воплощаться в качество для пользователей.
Различные подходы к качеству ПС и соответствующим метрикам качества.
Характеристики качества
Модель внутренних и внешних характеристик качества ПС состоит из шести групп базовых показателей, каждая из которых детализирована несколькими нормативными субхарактеристиками:
функциональная пригодность;
1. пригодностью для применения;
2. корректностью (правильностью, точностью);
3. способностью к взаимодействию;
4. защищенностью;
надежность;
5. уровнем завершенности (отсутствия ошибок);
6. устойчивостью к дефектам;
7. восстанавливаемостью;
8. доступностью;
9. готовностью;
эффективность;
10. временной эффективностью;
11. используемостью ресурсов;
применимость;
12. понятностью;
13. простотой использования;
14. изучаемостью;
15. привлекательностью;
сопровождаемость;
16. удобством для анализа;
17. изменяемостью;
18. стабильностью;
19. тестируемостью;
переносимость;
20. адаптируемостью;
21. простотой установки (инсталляции);
22. сосуществованием (соответствием);
23. замещаемостью.
Дополнительно каждая характеристика сопровождается субхарактеристикой — согласованностью, которая должна отражать отсутствие противоречий с прочими стандартами и нормативными документами, а также с другими показателями в этих сериях стандартов.
В стандартах также определена модель характеристик качества в использовании. В этой модели используются несколько другие базовые характеристики по сравнению с моделью внутреннего и внешнего качества. Основными характеристиками качества ПС в использовании являются:
· системная эффективность применения программного продукта (ПП) по назначению;
· продуктивность;
· безопасность;
· удовлетворение требований и затрат пользователей в соответствии с целями применения ПС.
ОСНОВЫ ЭРГОНОМИКИ
Эргономика - это наука об оптимальной деятельности человека в конкретных условиях современного производства и построении оптимальных орудий, условий и процесса труда.
Эргономика комплексно изучает человека (группу людей) в конкретных условиях его (их) деятельности, связанной с использованием технических средств. Человек, технические средства и среда рассматривается в эргономике как сложное функциональное целое, в котором ведущая роль принадлежит человеку. Эргономика является одновременно научной и проектировочной дисциплиной, т.к. в ее задачу входит разработка методов учета человеческих факторов при модернизации действующей и создание новой техники и технологии, а также соответствующих условий труда.
Предметом эргономики является конкретная деятельность человека (группы людей), использующего машины (технические средства), а объектом исследования система "человек (группа людей)- машина (техническое средство)- среда".
Эргономика рассматривает технический и человеческий аспекты в неразрывной связи. Стремление раскрыть закономерности этого синтеза характеризует эргономику как науку особого типа. Общая цель эргономики формулируется как единство двух аспектов исследования и проектирования: повышения эффективности деятельности и соответственно функционирования человеко-машинных систем и охраны здоровья людей, участвующих в трудовом процессе.
Методической базой эргономики является системный подход. На его основании возможно использование в эргономическом исследовании методов различных наук, на стыке которых возникают и решаются качественно новые проблемы изучения систем "человек-машина". При этом происходит определенная трансформация используемых методов, приводящая к созданию новых методических приемов исследования. В эргономике используются методы исследования, сложившиеся в социологии, физиологии и гигиене труда, в функциональной анатомии, кибернетике, системотехнике и др.
Оптимальные задачи эргономики
Эргономические требования, требования по обитаемости и требования технической эстетике к изделиям (системам "человек-машина") должны быть направлены на повышение эффективности деятельности и сохранение здоровья оператора, команды, расчета, экипажа (далее в тексте - операторов), взаимодействующего (взаимодействующих) с изделием, за счет оптимизации:
- структуры взаимодействия операторов и операторов и технических средств деятельности;
- физической, информационной, психологической, умственной нагрузок на оператора;
- условий деятельности, поддержания и восстановления здоровья и работоспособности операторов;
- уровня профессиональной подготовки операторов.
Эргономические требованиядолжны обеспечивать:
• распределение функций между операторами и техническими средствами в соответствии с их преимущественными возможностями и степенью ответственности решаемых задач;
• соответствие системы отбора, подготовки и организации деятельности операторов возложенным на них функциям и заданному качеству деятельности (быстродействию, точности, надежности, производительности, согласованности операторов и т.п.);
• достаточность и достоверность информации о состоянии управляемого объекта, возможность предвидения направлений развития управляемого процесса, оптимальность состава, содержания, кода, темпа обновления, степени обобщения и детализации информации;
• рациональную и устойчивую рабочую позу оператора, экономию физических усилий при эксплуатации, проведении профилактики и ремонта изделий, а также равномерное распределение физической нагрузки на различные части тела оператора;
• быстроту и надежность запоминания и воспроизведения логики действий оператором за счет учета при компоновке элементов рабочего места принципов функционального соответствия, объединения, совмещения, последовательности расположения, важности и частоты использования средств отображения информации (СОИ) и органов управления (ОУ);
• оптимальное сочетание визуальных, акустических, тактильных и других видов сигналов, их быстрое и надежное обнаружение, различение, опознание и дифференцирование в различных условиях деятельности, в том числе в условиях помех;
• надежность поиска, захвата, фиксации, необходимую чувствительность и оптимальные усилия перемещения ОУ при управлении ими, а также исключение неправильных действий при работе с несколькими однотипными ОУ;
• надежность обнаружения, наблюдения и рассмотрения объектов при помощи оптических приборов в условиях дня и ночи, снижение искажений изображений, защиту (включая автоматическую) органов зрения оператора от световых вспышек;
• формирование и совершенствование необходимых навыков и умений оператора или группы операторов в условиях, приближенных к реальным условиям деятельности, с учетом степени ответственности предстоящей деятельности и степени влияния на обучение оператора приобретенных ранее стереотипов мышления и действий;
• наглядность и иллюстративность специальной и эксплуатационной документации с учетом уровня профессиональной подготовки операторов и соответствие ее заданным условиям эксплуатации (например при повышенной влажности среды, слабой освещенности, агрессивной среде и т.п.);
• удобство использования инструмента и приспособлений для профилактических и ремонтных работ с учетом экипировки и условий деятельности оператора;
• удобство и надежность поддержания связи между операторами и оператором и внешними объектами с учетом воздействия шумовых помех и вибраций.
Место оператора ПЭВМ в эргономической системе
Независимо от степени автоматизации производства человек остается главным звеном системы «человек – машина». Именно он ставит цели перед системой, планирует, направляет и контролирует весь процесс ее функционирования. Деятельность оператора имеет ряд особенностей, определяемых тенденциями развития производства:
· увеличением числа объектов, которыми необходимо управлять;
· с развитием дистанционного управления человек все более удаляется от управляемых объектов. При этом он получает необходимую информацию в закодированном виде (т.е. в виде показаний измерительных приборов), что обусловливает необходимость декодирования и мыслительного сопоставления полученной информации с состоянием реального объекта;
· увеличением сложности и скорости течения производственных процессов, а, следовательно, повышением требований к точности действий оператора, быстроте принятия решений и выполнения управляющих действий. Поэтому работа оператора характеризуется увеличением нагрузки на нервно-психическую деятельность человека, именно она становится критерием тяжести операторского труда;
· для деятельности оператора характерно ограничение двигательной активности. Кроме того, он должен работать в условиях изоляции, в окружении приборов и индикаторов. Может возникнуть ситуация «конфликта» человека с приборами;
· от оператора требуется высокая готовность к экстренным действиям. Т.е. резкий переход от монотонного наблюдения и контроля к переработке большого количества информации, принятию и осуществлению принятого решения. Это может привести к возникновению сенсорных, эмоциональных и интеллектуальных перегрузок.
При изучении связей оператора с машиной необходимо иметь в виду, что они осуществляются в первую очередь через информационное взаимодействие. При этом, в самом информационном взаимодействии учитываются:
· особенности функции входа, от которых зависит обеспечение ввода информации в органы чувств человека;
· особенности функции управления, осуществляемые центральной нервной системой и зависящие от ее состояния;
· особенности функции выхода, которые в большинстве случаев реализуются посредством сенсомоторных органов и мышечной системы человека, а также зависят от их функционального состояния.
Этапы операторской деятельности
Деятельность оператора в системе может быть представлена в виде четырех этапов:
1. Прием информации - обнаружение сигналов, выделение из их совокупности наиболее значимых, их расшифровка и декодирование. На этом этапе информация приводится к виду пригодному для оценки и принятия решения.
2. Оценка и переработка информации – осуществляется сопоставление заданных и текущих режимов работы системы, производится анализ и обобщение информации, выделяются критические объекты и ситуации и на основании заранее известных критериев важности и срочности определяется очередность обработки информации.
3. Принятие решения – решение о необходимых действиях принимается на основе проведенного анализа и оценки информации, а также на основе других известных сведений о целях и условиях работы системы, возможных способах действия, последствиях правильных и ошибочных решений.
4. Реализация принятого решения – осуществляется приведение принятого решения в исполнение: перекодирование принятого решения в машинный код, поиск нужного органа управления, движение руки и (или) ноги к органу управления и манипуляция с ним.
Первые два этапа операторской деятельности в совокупности называют получением информации, последние два этапа – ее реализацией.
На качество и эффективность выполнения каждого действия влияет целый ряд факторов.
Прием информации зависит:
· от вида и количества приборов;
· от организации информационного поля;
· от психофизиологических характеристик информации (размеров изображений, цвета, контраста и т.д.).
На оценку и переработку информации влияют:
· способ кодирования информации;
· объем ее отображения;
· динамика смены информации;
· соответствие ее возможностям памяти и мышления оператора.
Эффективность принятия решения определяется:
· типом решаемой задачи;
· числом и сложностью проверяемых логических условий;
· сложностью алгоритма и количеством возможных вариантов решения.
Выполнение управляющих движений зависит:
· от числа органов управления;
· от их типа и способа размещения;
· а также от большой группы характеристик, определяющих степень удобства работы с отдельными органами управления.
Эргономическое обеспечение
Эргономическое обеспечение(ЭО) АИС совокупность методов и средств, предназначенных для создания оптимальных условий эффективной и безошибочной деятельности специалистов в процессе создания и функционирования АИС.
В состав ЭО входит: комплекс документации, содержащей требования к рабочим местам, условиям работы персонала, программному обеспечению; набор наиболее целесообразных способов реализации этих требований и экспертиза их реализации; комплекс методов, учебно-методических материалов и технических средств, позволяющих сформулировать требования к уровню подготовки персонала.
Эргономическая экспертиза
Эргономическая экспертиза - комплекс научно-технических и организационно-методических мероприятий по оценке выполнения в проектных, предпроектных и рабочих документах и в образцах СЧТС эргономических требований технического задания, нормативно-технических документов, а также по разработке рекомендаций для устранения отступлений от этих требований.
Указанная экспертиза проводится при обосновании выполнения каждого этапа опытно-конструкторской разработки: технического предложения, эскизного проекта, технического проекта, рабочего проекта. Материалы ее - акт либо протокол - включаются в документы, представляемые на защиту проекта.
ТЕСТИРОВАНИЕ, ВЕРИФИКАЦИЯ И ВАЛИДАЦИЯ
Верификация – это процесс определения, выполняют ли программные средства и их компоненты требования, наложенные на них в последовательных этапах жизненного цикла разрабатываемой программной системы.
Основная цель верификации состоит в подтверждении того, что программное обеспечение соответствует требованиям. Дополнительной целью является выявление и регистрация дефектов и ошибок, которые внесены во время разработки или модификации программы.
Верификация является неотъемлемой частью работ при коллективной разработке программных систем. При этом в задачи верификации включается контроль результатов одних разработчиков при передаче их в качестве исходных данных другим разработчикам.
Для повышения эффективности использования человеческих ресурсов при разработке, верификация должна быть тесно интегрирована с процессами проектирования, разработки и сопровождения программной системы.
Заранее разграничим понятия верификации и отладки. Оба этих процесса направлены на уменьшение ошибок в конечном программном продукте, однако отладка – процесс, направленный на локализацию и устранение ошибок в системе, а верификация – процесс, направленный на демонстрацию наличия ошибок и условий их возникновения.
Кроме того, верификация, в отличие от отладки – контролируемый и управляемый процесс. Верификация включает в себя анализ причин возникновения ошибок и последствий, которые вызовет их исправление, планирование процессов поиска ошибок и их исправления, оценку полученных результатов. Все это позволяет говорить о верификации, как о процессе обеспечения заранее заданного уровня качества создаваемой программной системы.
Жизненный цикл разработки программного обеспечения
Коллективная разработка, в отличие от индивидуальной, требует четкого планирования работ и их распределения во время создания программной системы. Один из способов организации работ состоит в разбиении процесса разработки на отдельные последовательные стадии, после полного прохождения которых получается конечный продукт или его часть. Такие стадии называют жизненным циклом разработки программной системы. Как правило, жизненный цикл начинается с формирования общего представления о разрабатываемой системе и их формализации в виде требований верхнего уровня. Завершается жизненный цикл разработки вводом системы в эксплуатацию. Однако, нужно понимать, что разработка – только один из процессов, связанных с программной системой, которая также имеет свой жизненный цикл. В отличие от жизненного цикла разработки системы, жизненный цикл самой системы заканчивается выводом ее из эксплуатации и прекращением ее использования.
Жизненный цикл программного обеспечения– совокупность итерационных процедур, связанных с последовательным изменением состояния программного обеспечения от формирования исходных требований к нему до окончания его эксплуатации конечным пользователем.
В контексте данного курса практически не будут затрагиваться такие этапы жизненного цикла, как системная интеграция и сопровождение. Для целей курса достаточно ограничиться упрощенным представлением, что после реализации кода и доказательства его соответствия требованиям разработка ПО завершается.
Модели жизненного цикла
Любой этап жизненного цикла имеет четко определенные критерии начала и окончания. Состав этапов жизненного цикла, а также критерии, в конечном итоге определяющие последовательность этапов жизненного цикла, определяется коллективом разработчиков и/или заказчиком. В настоящее время существует несколько основных моделей жизненного цикла, которые могут быть адаптированы под реальную разработку.
Каскадный жизненный цикл
Каскадный жизненный цикл (иногда называемый водопадным) основан на постепенном увеличении степени детализации описания всей разрабатываемой системы. Каждое повышение степени детализации определяет переход к следующему состоянию разработки (Рис. 1).
Рис. 1 Каскадная модель жизненного цикла
На первом этапе составляется концептуальная структура системы, описываются общие принципы ее построения, правила взаимодействия с окружающим миром – определяются системные требования.
На втором этапе по системным требованиям составляются требования к программному обеспечению – здесь основное внимание уделяется функциональности программной компоненты, программным интерфейсам. Естественно, все программные комплексы выполняются на какой-либо аппаратной платформе. Если в ходе проекта требуется также разработка аппаратной компоненты, параллельно с требованиями к программному обеспечению идет подготовка требований к аппаратному обеспечению.
На третьем этапе на основе требований к программному обеспечению составляется детальная спецификация архитектуры системы - описываются разбиение системы по конкретным модулям, интерфейсы между ними, заголовки отдельных функций и т.п.
На четвертом этапе пишется программный код, соответствующий детальной спецификации, на пятом этапе выполняется тестирование – проверка соответствия программного кода требованиям, определенным на предыдущих этапах.
Особенность каскадного жизненного цикла состоит в том, что переход к следующему этапу происходит только тогда, когда полностью завершены все работы предыдущего этапа. То есть сначала полностью готовятся все требования к системе, затем по ним полностью готовятся все требования к программному обеспечению, полностью разрабатывается архитектура системы и так далее до тестирования.
Естественно, что в случае достаточно больших систем такой подход себя не оправдывает. Работа на каждом этапе занимает значительное время, а внесение изменений в первичные документы либо невозможно, либо вызывает лавинообразное изменения на всех других этапах.
Как правило, используется модификация каскадной модели, допускающая возврат на любой из ранее выполненных этапов. При этом фактически возникает дополнительная процедура принятия решения.
Действительно если тесты обнаружили несоответствие реализации требованиям, то причина может крыться: (а) в неправильном тесте, (б) в ошибке кодирования (реализации), (в) в неверной архитектуре системы, (г) некорректности требований к программному обеспечению и т.д. Все эти случаи требуют анализа для принятия решения о том, на какой этап жизненного цикла надо возвратиться для устранения обнаруженного несоответствия.
V-образный жизненный цикл
В качестве своеобразной «работы над ошибками» классической каскадной модели стала применяться модель жизненного цикла, содержащая процессы двух видов – основные процессы разработки, аналогичные процессам каскадной модели и процессы верификации, представляющие собой цепь обратной связи по отношению к основным процессам (Рис. 2).
Рис. 2 V-образный жизненный цикл
Таким образом, в конце каждого этапа жизненного цикла разработки, а зачастую и в процессе выполнения этапа, осуществляется проверка взаимной корректности требований различных уровней. Данная модель позволяет более оперативно проверять корректность разработки, однако, как и в каскадной модели предполагается, что на каждом этапе разрабатываются документы, описывающие поведение всей системы в целом.
Спиральный жизненный цикл
Оба рассмотренных типа жизненных циклов предполагают, что заранее известны все требования пользователей или, по крайней мере, предполагаемые пользователи системы настолько квалифицированы, что могут высказывать свои требования к будущей системе, не видя ее перед глазами.
Естественно, такая картина достаточно утопична, поэтому постепенно появилось решение, исправляющее основной недостаток V-образного жизненного цикла – предположение о том, что на каждом этапе разрабатывается очередное полное описание системы. Этим решением стала спиральная модель жизненного цикла (Рис. 3).
Рис. 3 Спиральный жизненный цикл
В спиральной модели разработка системы происходит повторяющимися этапами – витками спирали. Каждый виток спирали – один каскадный или V-образный жизненный цикл. В конце каждого витка получается законченная версия системы, реализующая некоторый набор функций. Затем она предъявляется пользователю, на следующий виток переносится вся документация, разработанная на предыдущем витке, и процесс повторяется.
Таким образом, система разрабатывается постепенно, проходя постоянные согласования с заказчиком. На каждом витке спирали функциональность системы расширяется постепенно дорастая до полной.
Экстремальное программирование
Реалии последних лет показали, что для систем, требования к которым изменяются достаточно часто, необходимо еще больше уменьшить длительность витка спирального жизненного цикла. В связи с этим сейчас стали весьма популярными быстрые жизненные циклы разработки, например жизненный цикл в методологии eXtreme Programming (XP).
Основная идея жизненного цикла экстремального подхода – максимальное укорачивание длительности одного этапа жизненного цикла и тесное взаимодействие с заказчиком. По сути, на каждом этапе происходит реализация и тестирование одной функции системы, после завершения которых, система сразу передается заказчику на проверку или эксплуатацию.
Основная проблема данного подхода – интерфейсы между модулями, реализующими эту функцию. Если во всех предыдущих типах жизненного цикла интерфейсы достаточно четко определяются в самом начале разработки, поскольку заранее известны все модули, то при экстремальном подходе интерфейсы проектируются «на лету», вместе с разрабатываемыми модулями.
Сравнение различных типов жизненного цикла и вспомогательные процессы
Особенности рассмотренных выше типов жизненного цикла сведены в таблицу 1. Из нее можно видеть, что различные типы жизненных циклов применяются в зависимости от планируемой частоты внесения изменений в систему, сроков разработки и ее сложности. Жизненные циклы с более короткими фазами больше подходят для разработки систем, требования к которым еще не устоялись и вырабатываются во взаимодействии с заказчиком системы во время ее разработки.
Таблица 1 Сравнение различных типов жизненного цикла
Рис. 4 Жизненный цикл в MSF
При таком подходе от водопадной модели берется простота планирования, от классической спиральной – легкость модификаций. При этом благодаря промежуточным контрольным точкам и обратной спирали верификации облегчается взаимодействие с заказчиком.
При управлении проектом четко ставится цель, которую необходимо достичь в результате и учитываются ограничения, накладываемые на проект. Все виды ограничений могут быть отнесены к одному из трех видов: ограничения ресурсов, ограничения времени и ограничения возможностей. Эти три вида ограничений и приоритетность задач по их преодолению образую треугольник приоритетов в MSF (Рис. 5).
Рис. 5 Треугольник приоритетов в MSF
Треугольник приоритетов является основой для матрицы компромиссов – заранее утвержденных представлений о том, какие аспекты процесса разработки будут четко заданы, а какие будут согласовываться или приниматься как есть.
Microsoft выпустила среду разработки, в полной мере поддерживающей основные идеи MSF – Microsoft Visual Studio 2005 Team Edition. Это первый программный комплекс, представляющий собой не среду разработки для индивидуальных членов коллектива, а комплексное средство поддержки коллективной работы.
В состав Visual Studio Team Edition входит специальная редакция для тестировщиков – Team Edition for Software Testers (Рис. 6). Материалы семинарских занятий по данному курсу ориентированы на эту среду разработки, в то время как лекционные материалы ориентированы на изложение общих принципов и методик тестирования.
Рис. 6 Структура Microsoft Visual Studio 2005 Team System
Rational Unified Process
Rational Unified Process – это методология создания программного обеспечения, оформленная в виде размещаемой на Web базы знаний, которая снабжена поисковой системой.
Продукт Rational Unified Process (RUP) разработан и поддерживается Rational Software. Он регулярно обновляется с целью учета передового опыта и улучшается за счет проверенных на практике результатов.
RUP обеспечивает строгий подход к распределению задач и ответственности внутри рганизации-разработчика. Его предназначение заключается в том, чтобы гарантировать создание точно в срок и в рамках установленного бюджета качественного ПО, отвечающего нуждам конечных пользователей.
RUP способствует повышению производительности коллективной разработки и предоставляет лучшее из накопленного опыта по созданию ПО, посредством руководств, шаблонов и наставлений по пользованию инструментальными средствами для всех критически важных работ, в течение жизненного цикла создания и сопровождения ПО. Обеспечивая каждому члену группы доступ к той же самой базе знаний, вне зависимости от того, разрабатывает ли он требования, проектирует, выполняет тестирование или управляет проектом - RUP гарантирует, что все члены группы используют общий язык моделирования, процесс, имеют согласованное видение того, как создавать ПО. В качестве языка моделирования в общей базе знаний используется Unified Modeling Language (UML), являющийся международным стандартом.
Особенностью RUP является то, что в результате работы над проектом создаются и совершенствуются модели. Вместо создания громадного количества бумажных документов, RUP опирается на разработку и развитие семантически обогащенных моделей, всесторонне представляющих разрабатываемую систему. RUP – это руководство по тому, как эффективно использовать UML. Стандартный язык моделирования, используемый всеми членами группы, делает понятными для всех описания требований, проектирование и архитектуру системы.
RUP поддерживается инструментальными средствами, которые автоматизируют многие элементы процесса разработки. Они используются для создания и совершенствования различных промежуточных продуктов на различных этапах процесса создания ПО, например, при визуальном моделировании, программировании, тестировании и т.д.
RUP – это конфигурируемый процесс, поскольку, вполне понятно, что невозможно создать единого руководства на все случаи разработки ПО. RUP пригоден как для маленьких групп разработчиков, так и для больших организаций, занимающихся созданием ПО. В основе RUP лежит простая и понятная архитектура процесса, которая обеспечивает общность для целого семейства процессов. Более того, RUP может конфигурироваться для учета различных ситуаций. В его состав входит Development Kit, который обеспечивает поддержку процесса конфигурирования под нужды конкретных организаций.
RUP описывает, как эффективно применять коммерчески обоснованные и практически опробованные подходы к разработке ПО для коллективов разработчиков, где каждый из членов получает преимущества от использования передового опыта в:
· итерационной разработке ПО,
· управлении требованиями,
· использовании компонентной архитектуры,
· визуальном моделировании,
· тестировании качества ПО,
· контроле за изменениями в ПО.
RUP организует работу над проектом в терминах последовательности действий (workflows), продуктов деятельности, исполнителей и других статических аспектов процесса с одной стороны, и в терминах циклов, фаз, итераций и временных отметок завершения определенных этапов в создании ПО (milestones), т.е. в терминах динамических аспектов процесса, с другой.
eXtreme Programming
Экстремальное программирование – сравнительно молодая методология разработки программных систем, основанная на постепенном улучшении системы и разработки ее очень короткими итерациями. По своей сути экстремальное программирование (XP) - это одна из так называемых "гибких" методологий разработки ПО, представляющая собой небольшой набор конкретных правил, позволяющих максимально эффективно выполнять требования современной теории управления программными проектами.
XP ориентирована на:
· командную работу с тесными связями внутри команды и с заказчиком,
· разработку наиболее простых работающих решений,
· гибкое адаптивное планирование
· оперативную обратную связь (путем модульного и функционального тестирования).
Основными принципами XP является разработка небольшими итерациями на основании порции требований заказчика (т.н. пользовательских историй), написание функциональных тестов до написания программного кода, постоянное общение и постоянный рефакторинг кода.
Основными практиками XP являются
· Планирование процесса
· Частые релизы
· Метафора системы
· Простая архитектура
· Тестирование
· Рефакторинг
· Парное программирование
· Коллективное владение кодом
· Частая интеграция
· 40-часовая рабочая неделя
· Стандарты кодирования
· Тесное взаимодействие с заказчиком
Сравнение технологий MSF, RUP и XP
Основные особенности MSF, RUP и XP можно свести в небольшую таблицу (Таблица 2). По ней можно судить, что Rational Unified Process является хорошо сбалансированным решением для средних по размерам коллективов разработчиков, работающих с применением продуктов и технологий компании Rational. Сопровождение разработки системы и самой системы регламентируется самой методологией RUP, однако данная технология достаточно сильно ориентирована на внутрифирменные инструментальные средства.
Extreme Programming хорошо подходит для проектных групп малого размера и для небольших систем с часто изменяемыми требованиями. Основная проблема XP – сопровождаемость. В случае текучки кадров в коллективе разработчиков значительная часть проектной информации может быть утеряна из-за практически отсутствующей документации.
Таблица 2 Технологии MSF, RUP и XP
| <== предыдущая лекция | | | следующая лекция ==> |
| Определение времени сохранения работоспособности | | | Ролевой состав коллектива разработчиков, взаимодействие между ролями в различных технологических процессах |
Уроки php mysql Программирование
Онлайн система счисления Калькулятор онлайн обычный Инженерный калькулятор онлайн Замена русских букв на английские для вебмастеров Замена русских букв на английские
Аппаратное и программное обеспечение
Графика и компьютерная сфера
Интегрированная геоинформационная система
Интернет
Компьютер
Комплектующие компьютера
Лекции
Методы и средства измерений неэлектрических величин
Обслуживание компьютерных и периферийных устройств
Операционные системы
Параллельное программирование
Проектирование электронных средств
Периферийные устройства
Полезные ресурсы для программистов
Программы для программистов
Статьи для программистов
Cтруктура и организация данных