Концепция средо-ориентированного программирования. Основные типы сред как системы программирования.
Средо-ориентированное программирование предполагает наличие некоторой среды обладающей некоторыми свойствами, позволяющими обеспечить хранение информации. Среда имеет внешний вид и обладает определенным поведением. Средо-ориентированный подход позволяет решать задачи компьютерной обработки информации без знаний о компьютерах.
Каждая среда со свойствами:
1. Позволяет обеспечить хранение информации
2. Обладает некоторым внешним видом: можно осмотреть сразу и понять, какую задачу можно решить с ее помощью
3. Определенное поведение: определяет как себя вести со средой и что именно нужно делать, какого результата добиваться
Решение задачи в среде:
1. Объективная настройка среды под задачу
2. В любой среде существует та часть, которая позволяет сделать программируемую настройку.
Каждая среда имеет язык (процедурный). Это язык высокого уровня – имеет более крупные блоки, чем классические языки высокого уровня. Этим языком может пользоваться только подготовленный пользователь с определенной культурой программирования. Обычно с помощью встроенного языка можно запрограммировать внешний вид и поведение среды
Типы сред:
Операционные системы
Операционные оболочки
Инструменты
Текстовые редакторы
Графические редакторы
Электронные таблицы
СУБД
Математические пакеты
Классические системы программирования
Игры
Информационные персональные системы
Интегрированные среды
За каждым типом сред стоит много реализаций, таким образом, в решении задач появляется возможность альтернативы. Решая некоторую задачу, нельзя абсолютизировать средства.
Краткая характеристика средств:
Операционные оболочки – призваны улучшать внешний вид системы, так как в некоторых системах внешний вид неразвит. Примеры- Norton Commander, Windows 3.1 для Dos, X-Window для Unix.
Современные операционные системы обычно включают в себя операционную оболочку (графическую):
Windows XP/98/NT, OS/2, System 7
Инструменты - позволяют быстро выполнить работы по обслуживанию и подготовке системы.
Примеры: Norton Utilites
Классические системы программирования – включают в себя редактор, трансляторы, отладчики, ассемблеры и кросс-ассемблеры и т.п.
Информационные персональные системы – позволяют выполнять рутинную работу по ведению дневников, собственных планов работы и т.п. Как разновидность включает в себя средства по планированию работ
Интегрированные среды – то же призваны на решение каких-то конкретных задач: Microsoft Office
Технологии программирования (Клюкин В.Э.)
Системный программный продукт (СПП). Основные составляющие успешной разработки СПП. Корпоративная разработка, модель зрелости возможностей компании (CMM), понятие о командном (TSP) и индивидуальном (PSP) процессах.
Системный программный продукт (СПП)
Под программным продуктом (ПП) мы понимаем программное обеспечение (ПО) как результат человеческой деятельности, выставленный на рынке массового покупателя в качестве товара и имеющий ненулевую потребительную стоимость.
Очень важно различать тиражный программный продукт и программное обеспечение проекта. Тиражный ПП производится для того, чтобы его могли использовать во многих местах различные пользователи. Поэтому у него нет заказчиков, а решение о начале разработки принимается исходя из предполагаемого рыночного спроса. Текстовые процессоры, электронные таблицы, системы управления базами данных, электронные словари, корректоры орфографии, русификаторы, переводчики, программы оптического распознавания символов — все это примеры тиражных ПП, во всем мире их используют миллионы людей.
Программное обеспечение проекта создается для одного, редко — для нескольких пользователей или разрабатывается как часть технологии, которая может быть продана другой организации с целью использования в качестве составной части аппаратно-программного комплекса. В этом направлении работает, например, часть коллектива ParaGraph International, занимающаяся проблемами распознавания символов. Имея не более десятка потенциальных заказчиков, тем не менее, эта фирма гигант в своей области.
Таким образом, если у проекта обычно один или несколько пользователей, то вопрос о продолжении разработки стоит не так остро, а конкурентная борьба идет за право вести разработку. Напротив, тиражный программный продукт предназначен сотням тысяч потенциальных пользователей, и при его появлении на рынке неизбежна конкуренция с другими продуктами того же класса. В момент принятия решения о начале разработки фирма идет на значительный финансовый риск. При этом производитель должен ясно сознавать, что выпуском одной версии дело не закончится, поскольку цикл жизни ПП предполагает его совершенствование.
Надо сказать, что ценность ПП для большинства потенциальных пользователей остается неясной до тех пор, пока кто-то (лично или посредством маркетинговых мероприятий) не показал ее клиенту. Отсюда, раз ПП является товаром с ненулевой потребительской стоимостью, то неотъемлемой частью создания ПП должен быть маркетинг. Впрочем, вопросы, связанные с маркетингом, требуют отдельного серьезного обсуждения.
Основные составляющие успешной разработки СПП.
1)Грамотное проектирование, для того чтобы не требовалось через какое то время переписывание всего проекта.
2)Постоянное тестирование кода, с целью своевременного выявления ошибок, потому что если эти ошибки всплывут позже, их сложнее будет устранить.
3)Разбиение всего цикла разработки на итерации, по завершению которых, можно увидеть работающий проект. Только с каждой итерацией будет повышаться функциональность и мелкие детали.
4)Документирование кода – для того, чтобы в случае остановки проекта, можно было вернуться и быстро разобраться, что там сделано.
5)Постоянное общения разработчиков с заказчиками – для того, чтобы сделать все как хочет заказчик сразу, а не переделывать потом.
6)Использование современных технологий – т.к. на каждой новой технологии разработка проходит быстрее.
Корпоративная разработка
Существуют различные способы разделения процесса разработки программного обеспечения на этапы. При некоторых из них выделяют большее количество этапов, при других меньшее. По-видимому, неизбежными являются шесть этапов. Разработка программного обеспечения:
1)Определение требований
2) Проектирование
3)Программирование
4)Компоновка
5)Тестирование
6)Документирование
Определение требований - этот шаг является важнейшим среди всех шести этапов процесса разработки. Он влияет на все остальные этапы. Увы, это наименее изученный и наименее понятный процесс.
Процесс определения требований разбивается, по крайней мере, на две части. Во-первых, нужно понять, что нужно сделать, а во-вторых, нужно документировать это. Без этой второй части большой проект останется неуправляемым. Если требования не записаны и не сделаны доступными разработчикам, они вроде бы и не существуют. То, что они существуют в голове какого-нибудь гения, все равно не спасает проект от неожиданной катастрофы.
Определение требований это проблема системного уровня, которая постепенно спускается на уровень программного обеспечения.
Проектирование - обычно состоит из трех ступеней: принятия решения (выбора алгоритма, процесса), структуризации (детализации метода) и описания системы.
Говоря о структурном анализе и проектировании, нельзя хотя бы не упомянуть о SADT — Structured Analysis & Design Technique (методология структурного анализа и проектирования). SADT — это подход к описанию систем и специальный графический язык, изобретенный для этой цели, которые более 20 лет назад ввел Дугласс Т. Росс (Douglas T. Ross). Впоследствии Министерство обороны США стандартизировало и опубликовало часть этой методологии, касающуюся описания функциональной структуры систем, как IDEF0, а также разработало специальный графический язык для описания структуры данных - IDEF1 и язык описания параллельных процессов (описания динамической структуры систем) - IDEF2. С тех пор технология IDEF применяется тысячами специалистов во всем мире. Причем универсальность оказалась столь велика, что сейчас IDEF используется для разработки и описания систем не только в технике, но и в экономике, управлении и даже техническом писательстве и многих других областях.
Третьим пунктом является написание команд, сведение проекта программного обеспечения или просто программы к последовательности машинных команд — программирование.
Компоновка представляет собой комбинирование, связывание отдельных частей программы, написанных разными людьми или группами, в одну большую систему программного обеспечения.
Тестирование – это проверка программы на наличие ошибок.
И документирование – это написание руководства для пользователя, чтобы пользователи знали, как использовать эту программу, и для разработчиков, чтобы они знали, в случае надобности, как исправить какой-то модуль.
В корпоративной разработке могут участвовать от одного до нескольких тысяч специалистов, разных профилей: руководителей, программистов, дизайнеров, менеджеров, тестировщиков, и многих других.
модель зрелости возможностей компании (CMM)
Capability Maturity Model — модель зрелости процессов создания ПО: эволюционная модель развития способности компании разрабатывать программное обеспечение.
История
В ноябре 1986 года американский институт Software Engineering Institute (SEI) совместно с Mitre Corporation начали разработку обзора зрелости процессов разработки программного обеспечения, который был предназначен для помощи в улучшении их внутренних процессов.
Разработка такого обзора была вызвана запросом американского федерального правительства на предоставление метода оценки субподрядчиков для разработки ПО. Реальная же проблема состояла в неспособности управлять большими проектами. Во многих компаниях проекты выполнялись со значительным опозданием и с превышением запланированного бюджета. Необходимо было найти решение данной проблемы.
В сентябре 1987 года SEI выпустил краткий обзор процессов разработки ПО с описанием их уровней зрелости, а также опросник, предназначавшийся для выявления областей в компании, в которых были необходимы улучшения. Однако, большинство компаний рассматривало данный опросник в качестве готовой модели, вследствие чего через 4 года вопросник был преобразован в реальную модель, Capability Maturity Model for Software (CMM). Первая версия СММ (Version 1.0), вышедшая в 1991 году, в 1992 году была пересмотрена участниками рабочей встречи, в которой принимали участие около 200 специалистов в области ПО, и членами общества разработчиков.
Уровни
Начальный. Самый примитивный статус организации. Организация способна разрабатывать ПО. Организация не имеет явно осознанного процесса, и качество продукта целиком определяется индивидуальными способностями разработчиков. Один проявляет инициативу и команда следует его указаниям. Успех одного проекта не гарантирует успех другого. При завершении проекта не фиксируются данные о трудозатратах, расписании и качестве.
Повторяемый. В некоторой степени отслеживается процесс. Делаются записи о трудозатратах и планах. Функциональность каждого проекта описана в письменной форме. В середине 99 лишь 20% организаций имели 2-й уровень или выше.
Установленный. Имеют определенный, документированный и установленный процесс работы, не зависящий от отдельных личностей. Т.е. Вводятся согласованные проф. Стандарты, а разработчики их выполняют. Такие организации в состоянии достаточно надежно предсказывать затраты на проекты, аналогичные выполненным ранее.
Управляемый. Могут точно предсказать сроки и стоимость работ. Есть база данных накопленных измерений. Но нет изменений при появления новых технологий и парадигм.
Оптимизированный. Есть постоянно действующая процедура поиска и освоения новых и улучшенных методов и инструментов.
Развитие
Использование модели на практике выявило неоднозначность в подходах к достижению более высоких уровней организации процессов разработки ПО. Поэтому к 2002 году разрабатываются рекомендации по улучшению процесса разработки, которые получаются название CMMI (Capability Maturity Model Integration). На текущий момент последняя версия CMMi - 1.3 (опубликована в ноябре 2010)
понятие о командном (TSP) и индивидуальном (PSP) процессах.
TSP (Team Software Process)
1)TSP - это формализованный процесс разработки программного обеспечения.
2)Команда, использующая TSP, обычно состоит из 3-15 человек. Не все участники команды должны быть программистами.
3) Большие проекты выполняются несколькими командами, работающими по процессу TSPm
(расширение процесса TSP для нескольких команд).
4)В соответствии с моделью CMM, предлагаемой SEI TSP процесс обеспечивает CMM Level 5 для
команды разработки.
5)Для успешного использования процесса TSP участники команды должны использовать
персональный процесс PSP.
(Personal Software Process)
1)PSP это формальный процесс разработки программного обеспечения, созданный для
индивидуального использования.
2)Реализация процесса PSP обеспечивает CMM 5го уровня для индивидуальных разработчиков.
Используя процесс PSP разработчики:
1)Сами управляют процессом и используют его.
2)Постоянно планируют свою работу.
3)Собирают данные для оценки качества планирования и улучшения процесса.
4)Управляют качеством конечного продукта на всех стадиях процесса разработки.
При TSP разработчики должны постоянно сверяться с планом, отслеживать свой прогресс и обсуждать с другими участниками.
Командная разработка программных проектов. Основные принципы управления проектами. Основные роли в команде, их обязанности. Инструментальные средства поддержки управления проектами для небольших команд разработчиков, средства общения внутри команды (MS Groove, Share Point, Google Groupe, Google Docs).
Командная разработка программных проектов — это разработка, какого либо проекта несколькими людьми. Специалисты (возможно разных специальностей) объединяются, чтобы закончить проект в срок. При этом происходит разделение труда, и каждый делает то, что умеет лучше всего. Например те кто лучше разбирается в серверной части, разрабатывают серверную часть программы (проекта), а те кто лучше разбирается в клиентской – разрабатывают клиентскую.
О разделении труда
Чаще всего в программистском коллективе нужны как проектировщики, настоящие архитекторы, понимающие, что надо строить, и знающие, какие методы и инструменты необходимо применить, так и люди, которые могут писать большие куски кодов, хорошие каменщики.
В российских фирмах очень редко группы проектирования доводят проекты до такой стадии, что людям, пишущим команды, нечего делать, кроме тривиального преобразования. Когда такая точка достигается, человек, пишущий команды, уже не выполняет никакого проектирования и становится кодировщиком. Во многих российских фирмах, в силу нескольких причин, программисты не подразделяются на разработчиков и кодировщиков. А легендарная программа ЛЕКСИКОН вообще создавалась одним человеком, ее автором, нынешним техническим директором Микроинформа Евгением Веселовым.
В некоторых фирмах, например, в INZER, делят программистов на три категории: ведущие, старшие и младшие. Из самых опытных, эрудированных и склонных к менеджменту ведущих программистов выбирается "совет старейшин", который контролирует ход работ по отдельным проектам. Каждый проект управляется менеджером проекта, распределяющим ресурсы и время выполнения отдельных работ. Младшие программисты обычно умеют только кодировать.
Чтобы быть кодировщиком, вовсе не обязательно иметь диплом выпускника факультета прикладной математики. Авторы книги представляют фирму, в которой все кодировщики - студенты. А вот руководить проектом может далеко не каждый. Тот единственный человек, который в фирме является подлинным руководителем проекта, обязательно весьма умен, спокоен и упорен, может воспринять множество конфликтующих идей, влияний и противоречий между людьми и разобраться в них.
Важный фактор - баланс между разными категориями программистов. Говорят, что устройство программы отражает устройство организации, в которой она создавалась. Например, IBM - огромная организация, и злые языки в 80-x годах утверждали, что коды ее программистов спиралеобразны, со множеством обратных связей и состоят из частей, своим стилем изобличающих мышление отдельных групп людей, которые их писали.
Наилучшие программы пишутся небольшими - в четыре-пять человек - командами тесно взаимодействующих между собой программистов, один (редко два) из которых делает проект. Чем больше команда, тем более тщательно приходится разбивать структуру на части и более строго определять интерфейсы между ними. При этом проектные решения верхнего уровня должен принимать руководитель разработки. Попытки же собрать комитет для решения проектных задач в любом случае окажутся фатальными для судьбы продукта. Компромиссы в бизнесе хороши, но не тогда, когда нужно твердой рукой отсечь все лишнее и постараться сделать систему как можно более совершенной, учитывая ограниченные сроки разработки и трудовые ресурсы.
Основные принципы управления проектами есть:
Целенаправленность, это выражение в целевых ориентирах проекта для обеспечения конечных целей команды исполнителя и заказчика.
Системность, которая предусматривает выполнение новых, расширяющих требований к проекту. Необходимо структурировать работу выполнения, чтобы четко и ясно реализовать заказ к обозначенному сроку, тем самым дать понять заказчику, что данная организация исполнителей профессиональна.
Комплексность - этот принцип нужен для рассмотрения и использования различных форм и методов управления при разработке и выполнении продукта для нахождения общего «языка» между исполнителем и заказчиком. А также комплексный подход необходим для того чтобы были рассмотрены все общие идеи управления по уровням исполнителей, для связи отдельных требований проекта между собой и с основной целью проекта, также рассмотрение отдельных обстоятельств и непредвиденных случаев с точки зрения часовых интервалов.
Обеспечение, определение этого принципа заключается в комплектации всех требований различными видами ресурсов, которые необходимы для выполнения проекта.
Приоритетность. Само значение говорит о многом. Главное в приоритетности – выполнение первостепенных, основных задач, исходя из общей структуры плана развития проекта.
Экономическое обеспечение выполнения, которые планируются. Любые потери и убытки, в результате невыполненных требований должны быть учтены на основе оценки вероятности.
Основные роли в команде, их обязанности.
К важным и ключевым участникам любого проекта относятся:
1)Менеджер проекта или управляющий проектом. Это человек, который берет ответственность по управлению проектом.
2)Заказчик или потребитель. Один человек или организация, которые будут использовать продукт проекта(это может быть услуга, программа и т.д.). Может существовать множество степеней заказчиков. Например, к числу заказчиков нового зернового продукта могут относиться заводы, перерабатывающие зерновую культуру, пекарни, которые принимают муку, покупатели, которые покупают хлеб и хлебобулочные изделия. Иногда заказчик является потребителем одного проекта, а иногда под потребителем подразумевается юридическое или физическое лицо, получающее продукты проекта, а под заказчиком – тех, кто будет непосредственно использовать продукт проекта.
3)Исполнители. Это юридические или физические лица, либо предприятие, чьи сотрудники выполняют проект.
4)Участники команды проекта. Группа людей, которая выполняет разнообразные работы по проекту. Это могут быть программисты (те, кто пишут код), дизайнеры (те, кто разрабатывают интерфейс программы), тестировщики (те, кто тестируют код). И у каждой из этих групп есть командный лидер, который является самым опытным в команде и на него ложится самый сложные задачи.
5)Команда управления проектом. Еще одни участники команды проекта, Которые управляют организацией проекта.
6)Спонсор. Это лицо или группа лиц, предоставляющая финансовые ресурсы (деньги), либо в натуральном предложении («бартер», - как говорят в народе) – для данного проекта.
7)Источники влияния. Это человек или организация, которая не связана напрямую с получением или использованием проекта, но которая, в связи с их положением в отношениях заказчика-исполнителя может хорошо или негативно повлиять на ход исполнения проекта.
8)Штаб управления проектом. Если в исполняющей организации имеется этот штаб, он может быть участником проекта, если он несет прямую или косвенную ответственность за исходы проекта. Помимо вышеперечисленных важных ключевых участников проекта существует множество различных участников, которые попадают под различные категории, в том числе внутренние и внешние категории, владельцы и инвесторы, продавцы и посредники, члены команд и их семей, правительство, средства массовой информации, отдельные лица, различные организации и общество в целом. Если перечислять или классифицировать участников – эта работа, которая помогает определить кто именно является участником проекта. Задания и ответственности участников проекта могут перекрываться, например, в том случае, когда проектная организация обеспечивает финансовый бюджет строительства, который сама же и проектирует.
Менеджеры проекта должны управлять настроем участников проекта, А это достаточно сложно, так как у участников проекта могут быть разные или противоположные цели и возможности.
Инструментальные средства поддержки управления проектами для небольших команд разработчиков, средства общения внутри команды (MS Groove, Share Point, Google Group, Google Docs).
Программное обеспечение для управления проектами — определение для комплексного программного обеспечения, включающее в себя приложения для планирования задач, составления расписания, контроля цены и управления бюджетом, распределения ресурсов, совместной работы, общения, быстрого управления, документирования и администрирования системы, которое используются совместно для управления крупными проектами.
Задачи программного обеспечения для управления проектами
Планирование
Одной из наиболее распространенных возможностей является возможность планирования событий и управления задачами. Требования могут различаться в зависимости от того, как используется инструмент. Наиболее распространенными являются:
1)Планирование различных событий зависящих друг от друга
2)Планирование расписания работы сотрудников и управление ресурсами
3)Расчет времени, необходимого на решение каждой из задач
4)Сортировка задач в зависимости от сроков их завершения
5)Управление нескольким проектами одновременно
Управление данными и предоставление информации
Программное обеспечение для управления проектами предоставляет большое количество требуемой информации, такой как:
1)Список задач для сотрудников и информацию распределения ресурсов
2)Обзор информации о сроках выполнения задач
3)Ранние предупреждения о возможных рисках, связанных с проектом
4)Информации о рабочей нагрузке
5)Информация о ходе проекта, показатели и их прогнозирование
Примеры ПО для управления проектами:
1)Microsoft Office Groove — приложение для поддержки совместной работы. Входит в состав Microsoft Office. Предлагает основные инструменты для управления проектами.
2) SharePoint, или Microsoft SharePoint Products and Technologies — это коллекция программных продуктов и компонентов, которая включает в себя следующие компоненты:
Набор веб-приложений для организации совместной работы
Функциональность для создания порталов
Модуль поиска информации в документах и информационных системах
Функциональность управления рабочими процессами и cистему управления содержимым масштаба предприятия
Модуль создания форм для ввода информации
Функциональность для бизнес-анализа
SharePoint может быть использован для создания сайтов, предоставляющих пользователям возможность для совместной работы. Создаваемые на платформе SharePoint сайты могут быть использованы в качестве хранилища информации, знаний и документов, а также использоваться для исполнения облегчающих взаимодействие веб-приложений, таких как вики и блоги. Пользователи могут управлять и взаимодействовать с информацией в списках и библиотеках документов используя контролы, называемые веб-части (SharePoint WebParts)
3) Google Groups (Гугл Группы) — веб-сервис Google.
Возможности —Google Группы предоставляет архивы групп новостей Usenet, начиная с 11 мая 1981 года, и даёт возможность поиска по этим архивам. В частности, Google Groups включает архив эхоконференций Фидонет, полученный через гейты Usenet—Fido. Это единственный архив Фидо с возможностью поиска.
Кроме того, пользователи Google Groups могут помещать сообщения в группы новостей Usenet, используя тем самым Google Groups как гейт Usenet—WWW.
Группы обсуждений — Google Groups позволяет пользователям создавать собственные группы обсуждений с более широкими возможностями, чем обычные Usenet-группы. В группах обсуждения можно создавать обсуждения, страницы, вставлять фотографии и картинки и загружать файлы суммарным объёмом до 100 Mb.
История — Google Groups является расширением сервиса Deja.com, приобретённого Google в феврале 2001 г. Все Usenet-сообщения, бывшие в архиве Deja.com, включены в состав архива Google Groups.
4) Google Docs
Документы Google (англ. Google Docs) — бесплатный онлайн-офис, включающий в себя текстовый, табличный процессор и сервис для создания презентаций, а также интернет-сервис облачного хранения файлов с функциями файлообмена[1], разрабатываемый Google. Образован в итоге слияния Writely и Google Spreadsheets.
Это веб-ориентированное программное обеспечение, то есть программа, работающая в рамках веб-браузера без инсталляции на компьютер пользователя. Документы и таблицы, создаваемые пользователем, сохраняются на специальном сервере Google, или могут быть экспортированы в файл. Это одно из ключевых преимуществ программы, так как доступ к введённым данным может осуществляться с любого компьютера, подключенного к интернету (при этом доступ защищён паролем).
Унифицированный процесс разработки программных продуктов. Разработка ПП по технологии RUP, основные артефакты на этапах разработки. Варианты использования и спецификации потоков событий. Основной и альтернативные потоки как средство повышения надежности ПП.
Унифицированный процесс есть процесс разработки программного обеспечения. Процесс разработки программного обеспечения - это сумма различных видов деятельности, необходимых для преобразования требований пользователей в программную систему. Однако Унифицированный процесс - это больше, чем единичный процесс, это обобщенный каркас процесса, который может быть специализирован для широкого круга программных систем, различных областей применения, уровней компетенции и размеров проекта.
Унифицированный процесс компонентно-ориентирован. Это означает, что создаваемая программная система строится на основе программных компонентов, связанных хорошо определенными интерфейсами.
Для разработки чертежей программной системы Унифицированный процесс использует Унифицированный язык моделирования.
Однако действительно специфичные аспекты Унифицированного процесса заключаются в трех словосочетаниях - управляемый вариантами использования, архитектурно-ориентированный, итеративный и инкрементный. Это то, что делает Унифицированный процесс уникальным.
1. Унифицированный процесс управляется вариантами использования
Программная система создается для обслуживания ее пользователей. Следовательно, для построения успешной системы мы должны знать, в чем нуждаются и чего хотят ее будущие пользователи.
Понятие пользователь относится не только к людям, работающим с системой, но и к другим системам. Таким образом, понятие пользователь относится к кому-либо или чему-либо, что взаимодействует с системой, которую мы разрабатываем. Пример взаимодействия - человек, использующий банкомат. Он вставляет в прорезь пластиковую карту, отвечает на вопрос, высвечиваемый машиной на экране, и получает деньги. В ответ на вставленную карту и ответы пользователя система осуществляет последовательность действий, которые обеспечивают пользователю ощутимый и значимый для него результат, а именно получение наличных.
Взаимодействие такого рода называется вариантом использования. Вариант использования - это часть функциональности системы, необходимая для получения пользователем значимого для него, ощутимого и измеримого результата. Варианты использования обеспечивают функциональные требования. Сумма всех вариантов использования составляет модель вариантов использования, которая описывает полную функциональность системы. Однако варианты использования - это не только средство описания требований к системе. Они также направляют ее проектирование, реализацию и тестирование, то есть они направляют процесс разработки. Основываясь на модели вариантов использования, разработчики создают серию моделей проектирования и реализации, которые осуществляют варианты использования. Тестеры тестируют реализацию для того, чтобы гарантировать, что компоненты модели реализации правильно выполняют варианты использования. Таким образом, варианты использования не только инициируют процесс разработки, но и служат для связи отдельных его частей. Управляемый вариантами использования означает, что процесс разработки проходит серии рабочих процессов, порожденных вариантами использования.
2. Унифицированный процесс ориентирован на архитектуру
Понятие архитектуры программы включает в себя наиболее важные статические и динамические аспекты системы. Архитектура вырастает из требований к результату в том виде, как их понимают пользователи и другие заинтересованные лица. Эти требования отражаются в вариантах использования. Однако они также зависят от множества других факторов, таких как выбор платформы для работы программы (то есть компьютерной архитектуры, операционной системы, СУБД, сетевых протоколов), доступность готовых блоков многократного использования, соображения развертывания, унаследованные системы и нефункциональные требования. Архитектура - это представление всего проекта с выделением важных характеристик и затушевыванием деталей. Процесс помогает архитектору сконцентрироваться на правильных целях, таких, как понятность, легкость внесения изменений и возможность повторного использования.
Каждый продукт имеет функции и форму. Одно без другого не существует. В удачном продукте эти две стороны должны быть уравновешены. В этом примере функции соответствуют вариантам использования, а форма - архитектуре. Мы нуждаемся во взаимодействии между вариантами использования и архитектурой. Это вариант традиционной проблемы "курицы и яйца". Реально архитектура и варианты использования разрабатываются параллельно.
Таким образом, архитектор придает системе форму. Это означает, что форма, архитектура, должна быть спроектирована так, чтобы позволить системе развиваться не только в момент начальной разработки, но и в будущих поколениях. Чтобы найти такую форму, архитектор должен работать, полностью понимая ключевые функции, то есть ключевые варианты использования системы. Эти ключевые варианты использования составляют от 5 до 10 % всех вариантов использования и крайне важны, поскольку содержат функции ядра системы. Проще говоря, архитектор совершает следующие шаги:
Создает грубый набросок архитектуры, начиная с той части архитектуры, которая не связана с вариантами использования.
Далее архитектор работает с подмножеством выделенных вариантов использования, каждый из которых соответствует одной из ключевых функций разрабатываемой системы. Каждый из выбранных вариантов использования детально описывается и реа-лизуется в понятиях подсистем, классов и компонентов.
После того как варианты использования описаны и полностью разработаны, большая часть архитектуры исследована, созданная архитектура, в свою очередь, будет базой для полной разработки других вариантов использования.
Этот процесс продолжается до тех пор, пока архитектура не будет признана стабильной.
3. Унифицированный процесс является итеративным и инкрементным
Разработка коммерческих программных продуктов - это серьезное предприятие, которое может продолжаться от нескольких месяцев до года и более. Практично было бы разделить работу на небольшие куски или мини-проекты. Каждый мини-проект является итерацией, результатом которой будет приращение. Итерации относятся к шагам рабочих процессов, а приращение - к выполнению проекта. Для максимальной эффективности итерации должны быть управляемыми, то есть они должны выбираться и выполняться по плану. Поэтому их можно считать минипроектами.
Разработчики выбирают задачи, которые должны быть решены в ходе итерации, под воздействием двух факторов. Во-первых, в ходе итерации следует работать с группой вариантов использования, которая повышает применимость продукта в ходе дальнейшей разработки. Во-вторых, в ходе итерации следует заниматься наиболее серьезными рисками. Последовательные итерации используют артефакты разработки в том виде, в котором они остались при окончании предыдущей итерации. Это минипроекты, по-скольку для выбранных вариантов использования проводится последовательная разработка - анализ, проектирование, реализация и тестирование, и в результате варианты использования, которые разрабатывались в ходе итерации, представляются в виде исполняемого кода.
На каждой итерации разработчики определяют и описывают уместные варианты использования, создают проект, использующий выбранную архитектуру в качестве направляющей, реализуют проект в компоненты и проверяют соответствие компонентов вариантам использования. Если итерация достигла своей цели, процесс разработки переходит на следующую итерацию. Если итерация не выполнила своей задачи, разработчики должны пересмотреть свои решения и попробовать другой подход.
Для получения максимальной экономии команда, работающая над проектом, должна выбирать только те итерации, которые требуются для выполнения цели проекта. Для этого следует расположить итерации в логической последовательности. Разумеется, до определенного предела; так, незамеченные ранее проблемы приведут к добавлению итераций или изменению их последовательности, и процесс разработки потребует больших усилий и времени. Минимизация незамеченных проблем является одной из целей снижения рисков.
Управляемый итеративный процесс имеет множество преимуществ.
Управляемая итерация ограничивает финансовые риски затратами на одно приращение. Если разработчикам нужно повторить итерацию, организация теряет только усилия, затраченные на одну итерацию, а не стоимость всего продукта.
Управляемая итерация снижает риск непоставки продукта на рынок в запланированные сроки. При раннем обнаружении соответствующего риска время, которое тратится на его нейтрализацию, вносится в план на ранних стадиях, когда сотрудники менее загружены, чем в конце планового периода.
Управляемая итерация ускоряет темпы процесса разработки в целом, поскольку для более эффективной работы разработчиков и быстрого получения ими хороших результатов короткий и четкий план предпочтительнее длинного и вечно сдвигающегося.
Управляемая итерация признает тот факт, что желания пользователей и связанные с ними требования не могут быть определены в начале разработки. Они обычно уточняются в последовательных итерациях.
Эти концепции - управляемая вариантами использования, архитектурно-ориентированная и итеративная и инкрементная разработка - одинаково важны. Архитектура предоставляет нам структуру, направляющую нашу работу в итерациях, в каждой из которых варианты использования определяют цели и направляют нашу работу.
Разработка ПП по технологии RUP
Rational Unified Process (RUP) — методология разработки программного обеспечения, созданная компанией Rational Software.
Принципы
В основе RUP лежат следующие принципы:
-Ранняя идентификация и непрерывное (до окончания проекта) устранение основных рисков.
-Концентрация на выполнении требований заказчиков к исполняемой программе (анализ и построение модели прецедентов (вариантов использования)).
-Ожидание изменений в требованиях, проектных решениях и реализации в процессе разработки.
-Компонентная архитектура, реализуемая и тестируемая на ранних стадиях проекта.
-Постоянное обеспечение качества на всех этапах разработки проекта (продукта).
-Работа над проектом в сплочённой команде, ключевая роль в которой принадлежит архитекторам.
Жизненный цикл разработки
RUP использует итеративную модель разработки. В конце каждой итерации (в идеале продолжающейся от 2 до 6 недель) проектная команда должна достичь запланированных на данную итерацию целей, создать или доработать проектные артефакты и получить промежуточную, но функциональную версию конечного продукта. Итеративная разработка позволяет быстро реагировать на меняющиеся требования, обнаруживать и устранять риски на ранних стадиях проекта, а также эффективно контролировать качество создаваемого продукта.
Полный жизненный цикл разработки продукта состоит из четырех фаз, каждая из которых включает в себя одну или несколько итераций:
