Подходы к разработке по. Общие принципы и подходы к разработке ПО

Информатика, кибернетика и программирование

Итерация N Унифицированный процесс разработки программного обеспечения USDP Модель вариантов использования описывает случаи в которых приложение будет использоваться. Аналитическая модель описывает базовые классы для приложения. Модель проектирования описывает связи и отношения между классами и выделенными объектами Модель развертывания описывает распределение программного обеспечения по компьютерам.

Занятие №20
Общие принципы и подходы к разработке ПО

Модели разработки ПО

  1. Водопадная
  2. Каскадная модель
  3. Спиральная
  4. Экстремальное программирование
  5. Инкрементальная
  6. Методология MSF

Водопадная модель

Спиральная модель

Инкрементальная разработка

Анализ требований

Проектирование

Реализация

Компонентное

тестирование

Интеграция

Тестирование

единого целого

Итерация 1 Итерация 2 …. Итерация N

Унифицированный процесс разработки программного обеспечения (USDP)

  1. Модель вариантов использования, описывает случаи, в которых приложение будет использоваться.
  2. Аналитическая модель описывает базовые классы для приложения.
  3. Модель проектирования описывает связи и отношения между классами и выделенными объектами
  4. Модель развертывания описывает распределение программного обеспечения по компьютерам.
  5. Модель реализации описывает внутреннюю организацию программного кода.
  6. Модель тестирования состоит из тестирующих компонентов, тестовых процедур и различных вариантов тестирования

Методология MSF

Типичные компоненты архитектуры программного продукта и типичные требования к ПО

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

Надежность – способность системы противостоять различным отказам и сбоям.

Отказ – это переход системы в результате ошибки в полностью неработоспособное состояние.

Сбой – ошибка в работе системы, которая не приводит к выходу системы из строя.

Чем меньше отказов и сбоев за какой-то определенный интервал времени, тем система считается надежнее.


А также другие работы, которые могут Вас заинтересовать
57355. Многообразие органических соединений, их классификация. Органические вещества живой природы 48.5 KB
Многообразие органических соединений определяется уникальной способностью атомов углерода соединяться друг с другом простыми и кратными связями образовывать соединения с практически неограниченным числом атомов связанных в цепи циклы бициклы трициклы полициклы каркасы и др.
57359. Обработка словесных информационных моделей 291 KB
Основные понятия: модель; информационная модель; словесная информационная модель; аннотация; конспект. Конспект Конспект от лат. Создайте конспект к 2. Сохраните документ в собственной папке под именем Конспект.
57361. Число і цифра 3. Порівняння чисел у межах 3. Написання цифри 3. Порівняння довжини й товщини предметів 35.5 KB
Скільки всього тварин Хто стоїть першим Хто стоїть останнім Хто стоїть під номером 1 Хто стоїть під номером 2 Назвіть сусідів їжачка. Хто сусід праворуч білочки Хто сусід ліворуч жирафа Хто є найвищим Хто є найнижчим Хто стоїть посеред тварин Гра Покажи не помились.

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

Презентацию к данной лекции Вы можете скачать .

Цель лекции:

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

Введение

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

При использовании гибких методологий минимизация рисков осуществляется путём сведения разработки к серии коротких циклов, называемых итерациями , продолжительностью 2 -3 недели. Итерация представляет собой набор задач, запланированных на выполнение в определенный период времени. В каждой итерации создается работоспособный вариант программной системы, в которой реализуются наиболее приоритетные (для данной итерации) требования заказчика . На каждой итерации выполняются все задачи, необходимые для создания работоспособного программного обеспечения: планирование, анализ требований, проектирование, кодирование , тестирование и документирование . Хотя отдельная итерация , как правило, недостаточна для выпуска новой версии продукта, подразумевается, что текущий программный продукт готов к выпуску в конце каждой итерации. По окончании каждой итерации команда выполняет переоценку приоритетов требований к программному продукту, возможно, вносит коррективы в разработку системы.

Принципы и значение гибкой разработки

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

  • люди и их взаимодействие;
  • доставка работающего программного обеспечения;
  • сотрудничество с заказчиком;
  • реакция на изменение.

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

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

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

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

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

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

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

  1. Высшим приоритетом считать удовлетворение пожеланий заказчика посредством поставки полезного программного обеспечения в сжатые сроки с последующим непрерывным обновлением. Гибкие методики подразумевают быструю поставку начальной версии и частые обновления. Целью команды является поставка работоспособной версии с течение нескольких недель с момента начала проекта. В дальнейшем программные системы с постепенно расширяющейся функциональностью должны поставляться каждые несколько недель. Заказчик может начать промышленную эксплуатацию системы, если посчитает, она достаточно функциональна. Также заказчик может просто ознакомиться с текущей версией программного обеспечения, предоставить свой отзыв с замечаниями.
  2. Не игнорировать изменение требований, пусть даже на поздних этапах разработки. Гибкие процессы позволяют учитывать изменения для обеспечения конкурентных преимуществ заказчика. Команды, использующие гибкие методики, стремятся сделать структуру программы качественной, с минимальным влиянием изменений на систему в целом.
  3. Поставлять новые работающие версии ПО часто, с интервалом от одной недели до двух месяцев, отдавая предпочтение меньшим срокам. При этом ставится цель поставить программу, удовлетворяющую потребностям пользователя, с минимумом сопроводительной документации.
  4. Заказчики и разработчики должны работать совместно на протяжении всего проекта. Считается, что для успешного проекта заказчики, разработчики и все заинтересованные лица должны общаться часто и по многу для целенаправленного совершенствования программного продукта.
  5. Проекты должны воплощать в жизнь целеустремленные люди. Создавайте команде проекта нормальные условия работы, обеспечьте необходимую поддержку и верьте, что члены команды доведут дело до конца.
  6. Самый эффективный и продуктивный метод передачи информации команде разработчиков и обмена мнениями внутри неё - разговор лицом к лицу. В гибких проектах основной способ коммуникации - простое человеческое общение. Письменные документы создаются и обновляются постепенно по мере разработки ПО и только в случае необходимости.
  7. Работающая программа - основной показатель прогресса в проекте. О приближении гибкого проекта к завершению судят по тому, насколько имеющаяся в данный момент программа отвечает требованиям заказчика.
  8. Гибкие процессы способствуют долгосрочной разработке. Заказчики, разработчики и пользователи должны быть в состоянии поддерживать неизменный темп сколь угодно долго.
  9. Непрестанное внимание к техническому совершенству и качественному проектированию повышает отдачу от гибких технологий. Члены гибкой команды стремятся создавать качественный код, регулярно проводя рефакторинг.
  10. Простота - искусство достигать большего, делая меньше. Члены команды решают текущие задачи максимально просто и качественно. Если в будущем возникнет какая-либо проблема, то в качественный код имеется возможность внести изменения без больших затрат.
  11. Самые лучшие архитектуры, требования и проекты выдают самоорганизующиеся команды. В гибких командах задачи поручаются не отдельным членам, а команде в целом. Команда сама решает, как лучше всего реализовать требования заказчика. Члены команды совместно работают над всеми аспектами проекта. Каждому участнику разрешено вносить свой вклад в общее дело. Нет такого члена команды, который единолично отвечал бы за архитектуру, требования или тесты.
  12. Команда должна регулярно задумываться над тем, как стать ещё более эффективной, а затем соответственно корректировать и подстраивать свое поведение. Гибкая команда постоянно корректирует свою организацию, правила, соглашения и взаимоотношения.

Вышеприведенным принципам, в определенной степени, соответствуют ряд методологий разработки программного обеспечения:

AgileModeling набор понятий, принципов и приёмов (практик), позволяющих быстро и просто выполнять моделирование и документирование в проектах разработки программного обеспечения ;
AgileUnifiedProcess(AUP) упрощенная версия IBM RationalUnifiedProcess(RUP), которая описывает простое и понятное приближение (модель) для создания программного обеспечения для бизнес-приложений ;
OpenUP это итеративно-инкрементальный метод разработки программного обеспечения. Позиционируется как лёгкий и гибкий вариантRUP ;
AgileDataMethod группа итеративных методов разработки программного обеспечения, в которых требования и решения достигаются в рамках сотрудничества разных кросс-функциональных команд ;
DSDM методика разработки динамических систем, основанная на концепции быстрой разработки приложений (RapidApplicationDevelopment, RAD). Представляет собой итеративный и инкрементный подход, который придаёт особое значение продолжительному участию в процессе пользователя/потребителя ;
Extremeprogramming (XP) экстремальное программирование;
Adaptive software development (ADD) адаптивная разработка программ ;
Featuredrivendevelopment (FDD) разработка ориентированная на постепенное добавление функциональности ;
GettingReal итеративный подход без функциональных спецификаций, использующийся для веб-приложений ;
MSFfogAgileSoftwareDevelopment гибкая методология разработки ПО компании Microsoft ;
Scrum устанавливает правила управления процессом разработки и позволяет использовать уже существующие практики кодирования, корректируя требования или внося тактические изменения [

1. Назначение технологии программирования. История развития технологии программирования. Типы программных проектов. Составные части технологии программирования. Проект, продукт, процесс и персонал

2. Жизненный цикл программы. Циклический характер разработки. Основные понятия технологии программирования. Процессы и модели. Фазы и витки. Вехи и артефакты. Заинтересованные лица и работники.

3. Выявление и анализ требований. Требования к программному обеспечению . Схема разработки требований. Управление требованиями.

4. Архитектурное и детальное проектирование. Реализация и кодирование. Тестирование и верификация . Процесс контроля качества. Методы «белого ящика» и «чёрного ящика». Инспектирование и обзоры. Цели тестирования. Верификация, валидация и системное тестирование. Сопровождение и продолжающаяся разработка.

5. Модели процесса разработки. Водопадные и конвейерные модели. Спиральные и инкрементные модели. Гибкие модели процесса разработки.

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

7. Модели команды разработчиков. Коллективный характер разработки. Оптимальный размер команды. Подчиненность участников проекта. Развитие команды и развитие персонала. Специализация, кооперация и взаимодействие.

8. Модели команды разработчиков. Иерархическая модель команды. Метод хирургической бригады. Модель команды равных.

9. Природа программирования. Наука программирования. Искусство программирования. Ремесло программирования. Парадигмы программирования. Структурное программирование. Логическое программирование. Объектно-ориентированное программирование.

10. Программная архитектура. Событийное управление. Архитектура клиент/сервер. Службы. Трёхслойная архитектура. Проектирование программ. Концептуальное проектирование. Логическое проектирование. Детальное проектирование.

1. Новиков подходы к разработке ПО» http://window. /window_catalog/files/r60368/itmo307.pdf.

2. Экстремальное программирование. – Спб.: Питер, 2002.

3. Технология разработки программного обеспечения. – СПб. : Питер, 2004.

4. Брукс-мл. проектируются и создаются программные комплексы. М.: Наука, 1975; новое издание перевода: Мифический человеко-месяц. СПб.: СИМВОЛ+, 1999.

5. Алгоритмы + структуры данных = программы. М., Мир, 1978.

6. Систематическое программирование. Введение. М.: Мир, 1977.

7. Структурное программирование. М.: Мир, 1975.

8. Дисциплина программирования. М.: Мир, 1978.

9. Технологии разработки программного обеспечения. – СПб.: Питер, 2002.

10. Терехов программирования. М.: БИНОМ, 2006.

11. Рамбо Дж. Унифицированный процесс разработки программного обеспечения. СПб: Питер, 2002.

Экономическая теория для менеджеров

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

Курс экономической теории : учебник для вузов / Под ред. . –Киров: «АСА», 2004. Колемаев -математическое моделирование. Моделирование макроэкономических процессов и систем: учебник. М.:ЮНИТИ-ДАНА, 2005. Бажин кибернетика. Харьков: Консул, 2004. Леушин практикум по методам математического моделирования: учебное пособие . Нижегородский гос. техн. унив.- Н. Новород, 2007. Политикам об экономике: Лекции нобелевских лауреатов по экономике. М.: Современная экономика и право, 2005. Черемных. Продвинутый уровень: Учебник.-М.:ИНФРА-М, 2008. Эволюция институтов миниэкономики. Институт экономики УРО РАН,- М.: Наука, 2007.

Технологии разработки и принятия управленческих решений [ Н]

Принятие решений как основа деятельности менеджера. Введение в теорию принятия решений. Основные понятия теории принятия решений. Модели управления бизнесом и их влияние на принятие решений. Различные способы классификации решений. Классификации: по степени формальности, по степени рутинности, по периодичности, по срочности, по степени достижения целей, по способу выбора альтернативы. Основные методы принятия решений. Волевые методы принятия решений. Цели принятия решений. Время при поиске решений. Основные ошибки Математические методы принятия решений. Математические аспекты теории принятия решений. Исследование операций. Математический подход к принятию решений. Дерево решений. Модели разработки и принятия решений. Теория игр. Математические методы принятия решений. Математические аспекты теории принятия решений. Модели теории очередей. Модели управления запасами. Модель линейного программирования. Транспортные задачи. Имитационное моделирование. Сетевой анализ. Экономический анализ. Ограниченность рациональных моделей. Особенности разработки и принятия решений в группе. Метод определения групповой сплоченности на основе степени связности множеств. Методики принятия коллективного решения. Метод консенсуса. Методы голосования. Творческие методы принятия решений. Мозговой штурм. Конференция идей. Корабельный совет. Метод «Мысленных шляп» по де-Боно. Теория решения изобретательских задач (ТРИЗ). Идеальное конечное решение. Примеры задач и их решения при помощи ТРИЗ. Применение методов ТРИЗ при принятии уникальных и творческих решений. Методы разработки идей решений и их адаптация к ситуации. Модель дерева целей . Стратегия согласования интересов. Формирование решений по согласованию интересов. Методы определения интересов контрагентов . Системы поддержки принятия решений (экспертные системы). История создания систем принятия решений. Классификация систем принятия решений. Типовая структура экспертной системы. Способы представления знаний. Способы логического вывода. Применение экспертных систем на практике.

И. Теория принятия решений: учебник. - М.: Экзамен, 2006. - 573 с. И. Принятие решений. Теория и методы разработки управленческих решений. Учебное пособие. - М.: МарТ, 2005. - 496 с Г. Разработка управленческого решения - М.: Издательство «Дело», 2004 г. - 392 с. Г. Экспертные оценки и принятие решений.- М.: Патент, 1996. - 271 с. Таха // Введение в исследование операций = Operations Research: An Introduction. - 7-е изд. - М.: «Вильямс», 2007. - С. 549-594. Г. Тейл. Экономические прогнозы и принятие решений. М.: «Прогресс» 1970. К. Д. Льюис. Методы прогнозирования экономических показателей. М.: «Финансы и статистика» 1986. Г. С. Кильдишев, А. А. Френкель. Анализ временных рядов и прогнозирование. М.: «Статистика» 1973. О. Ким, Ч. У. Мьюллер, У. Р. Клекка и др. Факторный, дискриминантный и кластерный анализ. М.: «Финансы и статистика» 1989. Эффективный менеджер. Книга 3. Принятие решений. – МИМ ЛИНК, 1999 Туревский и управление автотранспортным предприятием. - М.: Высшая школа, 2005. , ; под ред. . Системный анализ в управлении: учебное пособие. – М.: Финансы и статистика, 2006. , Тиньков: учебное пособие. – М.: КНОРУС, 2006.

Моделирование бизнес-процессов в интегрированных системах менеджмента

По каким принципам выделяют бизнес-процессы? В чем заключается проблема целостного описания бизнес-процессов. Что такое система, какими свойствами она обладает? Роль системного анализа в моделировании бизнес-процессов? Процесс, как объект управления. Окружение процесса. Основные элементы бизнес-процесса. Достоинства и недостатки функционального и процессного менеджмента. Управленческий цикл PDCA. Этапы цикла управления процессами. Цикл PDCA и реализация требований стандарта ISO 9001:2008. Методология SADT (Structured Analysis and Design Technique – метод структурного анализа и проектирования). Сущность. Основные положения. Как представляется функциональная модель деятельности в методологии IDEF0? Что обозначают работы в диаграммах функциональной модели, как они отображаются по методологии IDEF0? Для чего предназначены стрелки в диаграммах функциональной модели, каковы их типы и виды? Методология DFD. Сущность. Основные компоненты диаграмм DFD. В чем особенности DFD-диаграмм, что в них описывается? В чем особенности объектов DFD-диаграмм? Что обозначают стрелки на диаграмме DFD? Методология IDEF3. Сущность. Средства документирования и моделирования. В чем особенности IDEF3-диаграмм, что в них описывается? В чем особенности объектов IDEF3-диаграмм? И стрелок? Классификация процессов. Типовые бизнес-процессы. Реинжиниринг и его технология. Когда целесообразно применять реинжиниринг при управлении компанией? Мониторинг и измерение процессов. Показатели процессов организации. Численная и рейтинговые оценки процессов.

"Моделирование бизнес-процессов с AllFusion Process Modeler (BPwin 4.1)Диалог-МИФИ" 2003 "Создание информационных систем с AllFusion Modeling Suite" изд. "Диалог-МИФИ" 2003 "Практика функционального моделирования с AllFusion Process Modeler 4.1. (BPwin) Где? Зачем? Как?" изд. "Диалог-МИФИ" 2004 Дубейковский моделирование с AllFusion Process Modeler (BPwin). изд. "Диалог-МИФИ" 2007 Д. Марка, К. МакГоуэн "Методология структурного анализа и проектирования SADT" 1993 г. классический труд по методологии SADT. Черемных анализ систем: IDEF-технологиис, Моделирование и анализ систем. IDEF-технологии. Практикум. M.: Финансы и статистика, 2001. , “Структурные модели бизнеса: DFD-технологии” http://www. /Level4.asp? ItemId=5810 "Теория и практика реорганизации бизнес-процессов"2003/ P50.1.. Методология функционального моделирования. М.: Госстандарт России, 2000. http://www. IDEF0, IDEF3, DFD http://www. Моделирование бизнес-процессов средствами BPwin http://www. /department/se/devis/7/ IDEF0 в моделировании бизнес-процессов управления http:///content/view/21/27/ http://www. /dir/cat32/subj45/file1411/view1411.html http://www. http://www.

Оценка эффективности программных продуктов

1. Архитектура ИТ

2. Домены процессов управления.

3. Перечень процессов домена Планирование и Организация

4. Перечень процессов домена Приобретение и Внедрение

5. Перечень процессов домена Эксплуатация и Сопровождение

6. Перечень процессов домена Мониторинг и Оценка

7. Характеристика уровней модели зрелости процессов

9. KPI и KGI их взаимосвязь и назначение

1. 10.Общие меры контроля в ИТ и меры контроля приложений. Зоны ответственности и обязанности бизнеса и ИТ.

Cobit 4.1 российское издание.

Правовое регулирование создания и использования интеллектуальной собственности

1. Перечислите интеллектуальные права на результаты интеллектуальной деятельности и раскройте их содержание.

2. Перечислите виды договоров по распоряжению исключительным правом. Охарактеризуйте каждый из указанных договоров по распоряжению исключительным правом.

4. Охарактеризуйте основные положения правовой охраны Программы для ЭВМ как объекта авторского права .

5. Сравните основные положения правовой охраны Базы данных как объекта авторского права и как объекта смежных прав.

6. Охарактеризуйте условия патентоспособности объектов патентных прав: изобретений; полезных моделей; промышленных образцов.

7. Раскройте содержание критериев патентоспособности изобретения: новизна; изобретательский уровень; промышленная применимость.

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

9. Дайте определение «ноу-хау» и перечислите условия, при создании которых возникает и осуществляется правовая охрана секретов производства.

10. Перечислите охраняемые средства индивидуализации и дайте их сравнительную характеристику.

1. , Право интеллектуальной собственности в Российской Федерации, учебник // М, Проспект, 2007 г.

2. , Право интеллектуальной собственности, учебное пособие // М, РИОР, 2009 г.

Управление проектами и разработкой ПО [ И]

Что такое методология, зачем она нужна. Общая структура методологии, основные элементы методологии. Принципы конструирования собственной методологии. Примеры различных артефактов, ролей, компетенций, граничных условий. Структура методологии по Коуберну, метрики методологии. Критерии проекта по Коуберну. Критерии выбора методологии, матрица Коуберна. Жизненный цикл проекта. Водопадная и итерационные модели жизненного цикла. Границы применимости для водопадной и итерационной моделей. RUP как пример итерационной методологии. Основные концепции RUP, границы применимости. Роль человека в разработке ПО. Гибкие методологии, основные принципы гибких методологий. Причина возникновения гибких методологий. Scrum как пример гибкой методологии. Роли, артефакты, деятельности в Scrum. Границы применимости Scrum. Экстремальное программирование (XP) Идеи, ценности, основные практики, границы применимости. Сходства и различия между Scrum и XP. Сбор и управление требованиями. Основные практики, термины, принципы. Подходы к документированию проекта и продукта, основные виды документов. Примеры практик по управлению требованиями из рассмотренных в курсе методологий. Планирование разработки ПО. Типы планов, управление риском, популярные риски. Примеры практик по планированию разработки из рассмотренных в курсе методологий. Тестирование при разработке ПО. Понятие сборки (билда) программного продукта. Основные методы тестирования, термины. Примеры практик по тестированию из рассмотренных в курсе методологий. Понятие сборки (билда), способы хранения кода, инструменты. Два принципа организации работы с системой контроля версий. Особенности процесса выпуска/выкладки продукта для разных категорий продуктов, примеры практик. Современные концепции архитектуры ПО, многоуровневые архитектуры, критерии архитектуры. Список необходимых решений при проектировании ПО, подходы к выбору системы хранения данных.

Кент Бек - Экстремальное программирование Фредерик Брукс - Мифический человеко-месяц или как создаются программные системы. Том де Марко - Deadline. Роман об управлении проектами. Том де Марко, Тимоти Листер - Вальсируя с медведями. Том де Марко, Тимоти Листер - Человеческий фактор_ успешные проекты и команды. Алистер Коуберн - Каждому проекту своя методология. Алистер Коуберн - Люди как нелинейные и наиболее важные компоненты в создании программного обеспечения. Андрий Орлов - Записки автоматизатора. Профессиональная исповедь. Филипп Крачтен - Введение в Rational Unified Process. Хенрик Книберг - Scrum и XP: заметки с передовой. Презентации лекций по курсу

1. Каскадная (англ. waterfall) - стандартная модель разработки

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

Такая модель включает следующие этапы процесса разработки ПО:

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

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

Основные плюсы каскадной разработки:

2. Гибкая методология разработки программного обеспечения (Agile software development)

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

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

Методов гибкой разработки несколько, из наиболее известных - Scrum, экстремальное программирование, DSDM.

Основные плюсы гибкой разработки:

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

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

Agile-манифест разработки программного обеспечения

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

Люди и взаимодействие важнее процессов и инструментов

Работающий продукт важнее исчерпывающей документации

Сотрудничество с заказчиком важнее согласования условий контракта

Готовность к изменениям важнее следования первоначальному плану

То есть, не отрицая важности того, что справа, мы всё-таки больше ценим то, что слева.

Принципы гибкой разработки:

Удовлетворение клиента за счёт быстрой и бесперебойной поставки необходимого программного обеспечения;
приветствие изменений требований даже в конце разработки (это может повысить конкурентоспособность полученного продукта);
частая поставка рабочего программного обеспечения (каждый месяц или неделю или ещё чаще);
тесное, ежедневное общение заказчика с разработчиками на протяжении всего проекта;
проектом занимаются мотивированные личности, которые обеспечены нужными условиями работы, поддержкой и доверием;
рекомендуемый метод передачи информации — личный разговор (лицом к лицу);
работающее программное обеспечение — лучший измеритель прогресса;
спонсоры, разработчики и пользователи должны иметь возможность поддерживать постоянный темп на неопределённый срок;
постоянное внимание улучшению технического мастерства и удобному дизайну;
простота — искусство не делать лишней работы;
лучшие технические требования, дизайн и архитектура получаются у самоорганизованной команды;
​постоянная адаптация к изменяющимся обстоятельствам.

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

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

Базовыми принципами структурного подхода являются:

o принцип "разделяй и властвуй";

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

Основными из этих принципов являются:

o абстрагирование - выделение существенных аспектов системы;

o непротиворечивости - обоснованность и согласованность элементов системы;

o структурирование данных - данные должны быть структуро-ване и иерархически организованы.

Методические основы технологий создания программного обеспечения

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

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

o трудностей проектируемой системы;

o необходимой полноты ее описания;

o знаний и навыков участников проекта;

o времени, отведенного на проектирование.

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

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

Похожие публикации