- •Введение
- •1Основная часть
- •1.1Теоретическая часть
- •1.1.1Управление проектами
- •1.1.2Стандарты проектного управления
- •1.1.3Специфика it-проектов
- •1.1.3.1Методологии управления it-проектами
- •1.1.3.2Каскадная модель (Waterfall)
- •1.1.3.3Спиральная модель
- •1.1.3.4Итеративная разработка
- •1.1.3.5Гибкая методология разработки
- •1.1.4SaaS-приложения
- •1.1.4.1Основные понятия электронно-вычислительных сетей
- •1.1.4.2Топология локальных сетей
- •1.1.4.3Типы локальных сетей
- •1.1.4.4Компьютерная сеть Интернет
- •1.1.4.5Основные системы и понятия сети Интернет
- •1.1.4.6Уровни сетевой модели osi
- •1.1.5SaaS-приложения для управления проектами
- •1.1.5.1Мегаплан
- •1.1.5.2Битрикс24
- •1.2Вычислительная часть
- •1.2.1Постановка проблемы
- •1.2.2Способ решения
- •1.2.3Электронный проектный офис как система поддержки принятия решений
- •1.2.4Применимость и целевая аудитория
- •1.2.4.1Учебные проекты
- •1.2.4.2Ориентация на распределенные команды
- •1.2.4.3Ориентация на малый бизнес и небольшие команды
- •1.2.5Основные функции сервиса
- •1.2.6Методология
- •1.2.7.1Построение Burndown диаграммы
- •1.2.7.2Советы и упражнения
- •1.2.7.3Массовое добавление задач
- •1.2.7.4Ежедневный сбор статистики от участников
- •1.2.8Диаграмма базы данных
- •1.2.9Макеты пользовательских интерфейсов
- •1.2.10Математическая модель
- •2Экономическая часть
- •2.1Общие положения
- •2.2Определение затрат на создание продукта
- •2.2.1Материальные затраты
- •2.2.2Расходы на оплату труда
- •2.2.3Отчисления на социальные нужды
- •2.2.4Амортизационные отчисления.
- •2.2.5Прочие расходы
- •2.3Затраты на создание продукта.
- •2.3.1Цена разработанного продукта.
- •2.3.2Оценка экономической эффективности использования продукта.
- •3Охрана труда и окружающей среды
- •3.1Введение
- •3.2Факторы, воздействующие на оператора пк
- •3.3Освещение
- •3.4Требование к монитору
- •3.4.1Визуальная эргономика
- •3.4.2Геометрические характеристики изображения
- •3.4.3Яркость изображения
- •3.4.4Контрастность изображения
- •3.4.5Цветопередача
- •3.5Эргономика рабочего места
- •3.6Заключение
- •4Заключение и выводы
- •5Список источников
- •6Приложения
- •6.1Приложение а
- •6.2Приложение б
1.1.3.3Спиральная модель
Спиральная модель, предложенная Барри Боэмом в 1988 году, стала существенным прорывом в понимании природы разработки ПО. Она представляет собой процесс разработки программного обеспечения, сочетающий в себе как проектирование, так и постадийное прототипирование с целью сочетания преимуществ восходящей и нисходящей концепции, делающая упор на начальные этапы жизненного цикла: анализ и проектирование. Отличительной особенностью этой модели является специальное внимание рискам, влияющим на организацию жизненного цикла. Боэм формулирует десять наиболее распространённых (по приоритетам) рисков:
Дефицит специалистов.
Нереалистичные сроки и бюджет.
Реализация несоответствующей функциональности.
Разработка неправильного пользовательского интерфейса.
«Золотая сервировка», перфекционизм, ненужная оптимизация и оттачивание деталей.
Непрекращающийся поток изменений.
Нехватка информации о внешних компонентах, определяющих окружение системы или вовлечённых в интеграцию.
Недостатки в работах, выполняемых внешними (по отношению к проекту) ресурсами.
Недостаточная производительность получаемой системы.
«Разрыв» в квалификации специалистов разных областей знаний.
Большая часть этих рисков связана с организационными и процессными аспектами взаимодействия специалистов в проектной команде.
Каждый виток спирали соответствует созданию фрагмента или версии программного обеспечения, на нем уточняются цели и характеристики проекта, определяется его качество и планируются работы следующего витка спирали. Таким образом углубляются и последовательно конкретизируются детали проекта и в результате выбирается обоснованный вариант, который доводится до реализации. Каждый виток разбит на 4 сектора:
оценка и разрешение рисков,
определение целей,
разработка и тестирование,
планирование.
На каждом витке спирали могут применяться разные модели процесса разработки ПО. В конечном итоге на выходе получается готовый продукт. Модель сочетает в себе возможности модели прототипирования и водопадной модели. Разработка итерациями отражает объективно существующий спиральный цикл создания системы. Неполное завершение работ на каждом этапе позволяет переходить на следующий этап, не дожидаясь полного завершения работы на текущем. При итеративном способе разработки недостающую работу можно будет выполнить на следующей итерации. Главная задача — как можно быстрее показать пользователям системы работоспособный продукт, тем самым активизируя процесс уточнения и дополнения требований. Основная проблема спирального цикла — определение момента перехода на следующий этап. Для ее решения необходимо ввести временные ограничения на каждый из этапов жизненного цикла. Переход осуществляется в соответствии с планом, даже если не вся запланированная работа закончена. План составляется на основе статистических данных, полученных в предыдущих проектах, и личного опыта разработчиков. Одним из возможных подходов к разработке программного обеспечения в рамках спиральной модели жизненного цикла является получившая в последнее время широкое распространение методология быстрой разработки приложений RAD (Rapid Application Development). Под этим термином обычно понимается процесс разработки программного обеспечения, содержащий 3 элемента:
небольшую команду программистов (от 2 до 10 человек);
короткий, но тщательно проработанный производственный график (от 2 до 6 месяцев);
повторяющийся цикл, при котором разработчики, по мере того, как приложение начинает обретать форму, запрашивают и реализуют в продукте требования, полученные через взаимодействие с заказчиком.
Жизненный цикл программного обеспечения по методологии RAD состоит из четырёх фаз:
фаза определения требований и анализа;
фаза проектирования;
фаза реализации;
фаза внедрения.
Спиральная модель ориентирована на большие, дорогостоящие и сложные проекты. В условиях, когда бизнес цели таких проектов могут измениться, но требуется разработка стабильной архитектуры, удовлетворяющей высоким требованиям по нагрузке и устойчивости, имеет смысл применение Spiral Architecture Driven Development. Данная методология, включающая в себя лучшие идеи спиральной модели и некоторых других, позволяет существенно снизить архитектурные риски, что является немаловажным фактором успеха при разработке крупных систем.
