Cрочняк нужно выполнить ответы на вопросы по информатике за 1 день, тема "Проектный практикум"

Проектный практикум Задание 1 Описание компании разработчика 1. Придумайте фирму, занимающуюся разработкой программного обеспечения. Определите: a. Название, количество персонала, b. Сферу деятельности, комплекс услуг, c. Миссию, d. Видение. 2. Разработайте организационную структуру фирмы: a. Создайте схему организационной структуры фирмы, b. Опишите бизнес - цели и задачи всех подразделений фирмы, c. Опишите состав персонала каждого подразделения и их функциональные обязанности, 3. Разработайте методологию создания программных продуктов в фирме: a. Выберите модель жизненного цикла и стандарт, в соответствие с которым будет проводиться разработка проекта по созданию ПО. b. Определите фазы жизненного цикла проекта. 4. Опишите технологию создания команды проекта по разработке ПО для заказчика: a. организационную структуру проекта b. состав команды проекта, c. создайте матрицу ответственности по проекту. Отчетный документ «Описание фирмы» оформить в Word, отчет должен быть понятным и наглядным. Проектный практикум Задание 2 Разработка концепции проекта 1. Выберите компанию, работающую в определенной сфере бизнеса (кроме сферы IT). 2. Опишите компанию (название, численность работников, сферу деятельности, цели, управляющий аппарат). 3. Сформулируйте проблемы, стоящие перед компанией и обоснуйте необходимость реализации проекта по разработке и внедрению ИС. 4. Разработайте концепцию проекта создания ИС. Для создания концепции используйте шаблон документа с пояснениями, а также материал лекций С.Архипенкова (Архипенков С. Лекции по управлению проектами// http://arkhipenkov.ru/index.files/publications.htm.- С.42-56) Шаблон Концепции проекта Итеративный подход к процессу разработки требует использования гибкого способа ведения документации. Живые документы должны изменяться по мере эволюции проекта. На фазе выработки концепции планы имеют форму описания высокоуровневых подходов и по мере подготовки распространяются среди членов проектной группы и других заинтересованных лиц для получения отзывов. После перехода к фазе планирования документы постепенно дорабатываются, возникающие детальные планы снова поступают на проверку всем заинтересованным сторонам, и описанный процесс повторяется итеративно. Типы планов и общее количество описывающих их документов могут варьироваться от проекта к проекту. 1. Необходимость проекта Обоснование необходимости Сформулируйте, на разрешение каких проблем и/или удовлетворение каких потребностей заинтересованных сторон направлен проект. Видение проекта Видение – это ничем не ограничиваемое представление о том, каким должно быть решение. Видение проекта направлено на формирование у всех вовлеченных в проект сторон единого понимания его концепции. Формулировка видения должна быть достаточно краткой для запоминания, достаточно ясной для понимания и достаточно сильной для мотивирования. Хорошая формулировка видения ориентируется на пять SMART характеристик:  Specific (определенность/конкретность) – видение четко указывает на то (идеальное) состояние, достижение которого является целью проекта.  Measurable (измеримость) – дает проектной группе четкий критерий успешности проекта и достижения поставленных целей.  Achievable (достижимость) – цели, сформулированные в видении, должны быть достижимы в рамках имеющихся ресурсов, времени и возможностей команды. Достижимость мотивирует команду на выполнение проекта.  Relevant (обоснованность) – цели, сформулированные в видении, должны иметь существенное значение для заинтересованных сторон и напрямую быть связанными с их проблемами и/или потребностями.  Time-based (ограниченность во времени) – видение должно четко указывать на ожидаемые временные рамки, в которые решение будет достигнуто. Сформулируйте (максимально кратко, в одной двух фразах) видение проекта. Анализ выгод Основываясь на сформулированном выше видении проекта, перечислите, какие выгоды получат заинтересованные стороны по завершении проекта (в результате внедрения и использования решения). 1. Концепция решения Концепция решения предоставляет общее описание подходов, которые проектная группа предполагает использовать для разрешения проблем и/или удовлетворения потребностей заинтересованных сторон. Цели и Задачи Формирование концепции решения начинается с выяснения у заинтересованных сторон, описания и фиксации проектной группой целей проекта. Далее каждая цель разбивается на измеримые компоненты – задачи. Во взаимодействии с заинтересованными сторонами проекта сформулируйте и утвердите цели решения, на достижение которых направлен проект. Определите задачи, из которых будет складываться достижение каждой цели. Предположения и Ограничения В процессе формирования концепции решения проектная группа постоянно взаимодействует с заинтересованными сторонами, собирая необходимую информацию о требованиях к функциональности будущего решения. Тем не менее, неизбежная неполнота информации приводит к тому, что относительно некоторых функциональных возможностей решения могут потребоваться предположения. Помимо функциональных требований заинтересованные стороны могут выдвигать качественные требования, задающие ограничения на создаваемое решение. Также ограничения могут порождаться средой, в которой должно будет функционировать решение после внедрения. Определите, имеются ли в проекте требования, нуждающиеся в предположениях, если да, сформулируйте их. Определите, имеются ли ограничения на будущее решение. Если да, сформулируйте их. Анализ использования Основой формулировки требований является анализ использования, включающий определение пользователей и описание того, как пользователи будут взаимодействовать с решением. Пользователи В разработке решения заинтересованы множество сторон, однако непосредственная работа с ним будет выполняться пользователями, поэтому прежде чем приступать к дизайну решения, необходимо определить, кто будет с ним взаимодействовать. В процессе анализа должны быть выделены группы пользователей (например, на основе областей их деятельности, в которых будет использоваться разрабатываемое решение). Сформируйте список групп пользователей, для которых предназначено решение. Сценарии использования Сценарии использования определяют последовательности действий, которые пользователи выполняют при взаимодействии с решением. Один из возможных (и достаточно распространенных) вариантов описания сценариев использования – язык UML. Для каждой выделенной на предыдущем шаге группы пользователей определите характерные способы их взаимодействия с решением и, используя необходимые диаграммы UML, опишите сценарии использования. Требования Требования определяют, что должно делать разрабатываемое решение. Требования могут выражаться в терминах функциональности или в виде правил и параметров, определяющих функциональность. Требования пользователей Сформулируйте требования к решению с точки зрения пользователей. Системные требования Сформулируйте требования к решению с точки зрения среды, в которой оно должно будет функционировать после внедрения. 1. Рамки Рамки определяют пространство параметров, в котором будет создаваться решение, детализируя функциональность, определяя, что останется за рамками решения и указывая критерии, по которым заинтересованные лица будут судить о готовности решения. Рамки создаются на основе единого видения, являются результатом компромисса между сформулированными целями и условиями реальности и отражают приоритезацию заказчиком имеющихся требований к создаваемому решению. Частью процесса определения рамок проекта является вынесение менее важной функциональности из текущего проекта в планы на будущее. Рамки решения определяют функциональность решения и его возможности (включая те, что не относятся к программному обеспечению). Возможность (функциональность, составляющая, feature) – это требуемый или желаемый аспект программного или аппаратного обеспечения. Например, предварительный просмотр перед печатью может быть возможностью текстового процессора. Сопроводительные руководства пользователей, интерактивные файлы помощи, операционные руководства и обучение также могут быть составляющими решения. Рамки проекта определяют объем работ, который должен быть выполнен проектной группой для поставки заказчику каждого из элементов, определенного рамками решения. Управление рамками проекта критично для его успеха. Советуют определять и фиксировать рамки решения и проекта, используя треугольник компромиссов и матрицу компромиссов проекта. Функциональность решения Укажите здесь функциональность в терминах возможностей (features) и функций (functions), которая будет реализована в разрабатываемом решении. За рамками решения Укажите здесь функциональность, которая имеется или предполагается в требованиях заинтересованных сторон, но не будет реализована в решении, и опишите причины вынесения данных возможностей и функций за рамки решения (используйте треугольник компромиссов). Критерии одобрения решения Сформулируйте здесь критерии, в соответствии с которыми заинтересованные стороны будут принимать готовность решения. 1. Стратегии дизайна решения Стратегия архитектурного дизайна На основе разработанного списка возможностей и функций формируется стратегия архитектурного дизайна, описывающая решение в целом. Она определяет компоненты решения и их взаимодействие. Отличный способ описания решения на этом этапе – использование иллюстрирующих диаграмм (например, UML). Сформируйте и опишите общий архитектурный проект решения. Стратегия технологического дизайна Разработка решения потребует использования определенных продуктов и технологий. Стратегия технологического дизайна описывает, какие технологии и продукты выбраны проектной группой в качестве средства реализации решения. Аргументировано опишите, какие технологические средства будут использованы в процессе работы над решением. Проектный практикум Задание 3 Разработка плана проекта 1. Создайте проект в программе Microsoft Project. При создании проекта руководствуйтесь выбранным стандартом разработки и моделью жизненного цикла ПО. 2. Разработайте календарный план проекта: a. определите состав решаемых задач на каждой фазе проекта, b. в каждой фазе определите конечную веху. Опишите артефакты, характеризующие каждую веху (документы, модели, схемы и т.п.). c. определите длительности задач, d. определите иерархическую структуру задач, e. установите связи между задачами, f. введите обобщающую (суммарную) задачу. Рекомендации к выполнению: Работа с Microsoft Project Создание нового проекта Начиная новый проект в Microsoft Project, можно ввести или начальную, или конечную дату проекта, но не обе. Рекомендуется вводить только начальную дату проекта, а конечная дата будет рассчитана в Microsoft Project после ввода и планирования задач. Если проект должен быть завершен к определенной дате, следует ввести только конечную дату проекта. В этом случае первоначальное планирование следует выполнять с конечной даты, чтобы определить дату, когда необходимо начать проект. Если известна наилучшая начальная дата и работа начата, более эффективно выполнять планирование с начальной даты. 1. Откройте Microsoft Project. 2. В меню Проект выберите команду Сведения о проекте. Введите или выберите начальную дату проекта и планирование от Даты начала проекта, нажмите кнопку OK. 3. Сохраните проект в своей папке, задав ему имя. Ввод ключевых сведений о проекте В каждом проекте содержится уникальный набор компонентов: цель проекта, определенные задачи, а также лица, их выполняющие. Чтобы помнить все важные сведения и их взаимосвязь, следует вводить данные о проекте и обращаться к ним при необходимости. 1. В меню Файл выберите команду Свойства и откройте вкладку Документ. 2. Введите сведения о проекте: имя, тему, автора, руководителя, учреждение – название учреждения. 3. Нажмите кнопку OK. Настройка календаря проекта Календарь проекта можно изменять, чтобы отражать рабочие дни и часы для каждого участника проекта. Стандартный календарь с понедельника по пятницу, с 9:00 до 18:00, с часовым обеденным перерывом. Можно определить и нерабочее время, например выходные или ночное время, а также специальные выходные дни, например праздники. 1. В меню Сервис выберите команду Изменить рабочее время 2. Выделите в календаре название дней с понедельника по четверг и установите для выбранных дат стандартное рабочее время (с 9.00 по.13.00 и с 14.00 по 18.00). Затем для пятницы выберите Нестандартное рабочее время и установите окончание работы в 17.00. 3. Выберите параметр нерабочее время для выходных дней (субботы и воскресенья), а также для рождественских праздников (с 30 декабря по 10 января следующего года) и остальных привычных праздников. 4. Нажмите кнопку OK. Ввод и организация списка задач Когда создан план проекта, его можно заполнить задачами. Сначала перечислите шаги (фазы), необходимые для достижения целей проекта. Проще всего начать с крупных частей работы, а затем поделить каждую часть на задачи с отдельными результатами. Обычный проект представляет собой набор связанных задач. Задача определяется объемом работы и конкретными результатами; она должна быть достаточно короткой, чтобы можно было регулярно отслеживать ее ход выполнения. Длительность задач обычно должна лежать в интервале от одного дня до двух недель. 1. В меню Вид выберите команду Диаграмма Ганта. 2. В поле Название задачи введите название задачи, нажмите Enter. При этом Microsoft Project вводит со знаком вопроса примерную длительность задачи, равную одному дню. 3. Введите все задачи плана проекта (в соответствие с п.7 технического задания – стадии и этапы разработки). Организация задач в логическую структуру Структурирование помогает организовать задачи в более удобные для управления компоненты. Создав иерархию, можно объединить связанные задачи в более общую задачу. Общие задачи называются суммарными задачами или фазами; задачи, объединенные под суммарной задачей, называются подзадачами. Начальная и конечная дата суммарной задачи определяется начальной и конечной датами первой и последней ее подзадачи. Чтобы организовать структуру, следует использовать кнопки структуры на панели инструментов. 1. Выберите задачу, которую требуется сделать подзадачей. 2. Нажмите на панели инструментов кнопку структуры На уровень ниже, чтобы расположить задачу с отступом. 3. Работать со структурой можно разными способами. Например: уровень задачи можно быстро изменить с помощью мыши. Выберите задачу, расположите курсор на первой букве названия задачи. Когда указатель примет вид двунаправленной стрелки, перетащите ее вправо, чтобы расположить задачу с отступом, или влево, чтобы расположить ее с выступом. 4. Создайте логическую структуру задач в соответствие с разработанным планом. Создание вехи Веха - это задача, используемая для обозначения значимых событий календарного плана, например завершения основного этапа работ. При вводе нулевой длительности для задачи в Microsoft Project на диаграмме Ганта в начале соответствующего дня отображается символ вехи. Задача с нулевой длительностью автоматически помечается как веха, но вехой может быть сделана любая задача. Чтобы пометить задачу как веху, выберите задачу в поле Название задачи. Нажмите на панели инструментов кнопку Сведения о задаче, выберите вкладку Дополнительно, а затем установите флажок Пометить задачу как веху. 1. Определите вехи для каждой фазы проекта. 2. Сформируйте полный план проекта. Определение длительности задач При создании задач MS Project автоматически устанавливает длительности задач в один день. Длительности фаз не вводятся, программа рассчитывает их сама. Программа также определяет дату окончания задачи. Если длительность задачи нельзя определить точно или она требует уточнения, то после значения длительности ставится знак вопроса. 1. Уточните длительности задач в соответствие с разработанным планом проекта. Создание взаимосвязей между задачами Одним из наиболее надежных способов планирования задач является установление взаимосвязей между ними, т.е. зависимостей задач. Зависимости задач отражают обусловленность последующих задач или последователей, более ранними задачами или предшественниками. Например, если задача «Покрасить стену» должна быть выполнена до задачи «Повесить часы», можно связать две задачи, чтобы задача «Покрасить стену» стала предшественником, а задача «Повесить часы» - последователем. После того как задачи связаны, изменение дат предшественника влияет на изменение дат последователей. В Microsoft Project по умолчанию создается зависимость задач типа «Окончание-начало». Однако, поскольку зависимость «Окончание-начало» подходит не для каждого случая, для реального моделирования проекта связь задач можно изменить на «Начало-начало», «Окончание-окончание» или «Начало-окончание». 1. В меню Вид выберите команду Диаграмма Ганта. 2. Чтобы связать две или более задач друг с другом, выберите их в поле Название задачи, причем в том же порядке, в котором они должны быть связаны. Нажмите кнопку Связать задачи. 3. Устанавливать связи можно непосредственно в таблице, вводя номер предшествующей задачи в колонку Предшественники. После нажатия ОК, связь отображается на диаграмме. 4. Чтобы изменить связь задач, дважды щелкните линию связи между задачами на диаграмме, которую требуется изменить. Будет открыто диалоговое окно Зависимость задач. В поле со списком Тип выберите нужный тип связи между задачами и нажмите кнопку OK. 5. Чтобы разорвать связь между задачами, выберите эти задачи в поле Название задачи и нажмите кнопку Разорвать связи задач. Все связи удаляются, а все задачи перепланируются на основании ограничений, например «Как можно раньше» или «Фактическое окончание». 6. Связи можно редактировать в диалоговом окне Сведения о задаче, которое выводится с помощью контекстного меню, на вкладке Предшественники. 7. Связи можно редактировать с помощью Формы описания задачи. Она выводиться на экран с помощью команды Окно – Разделить. 8. Свяжите все задачи проекта в соответствие с логикой планирования. Использование задержек и ограничений. После создания и структурирования списка задач следует проверить, как задачи соотносятся друг с другом и как они соответствуют важным датам. Можно связать задачи, чтобы отразить их зависимость, например, указав, что одна задача начинается по завершении другой. Эти связи называются зависимостями задач. Вместе с длительностью и другими факторами планирования зависимости задач играют в Microsoft Project важную роль при расчете начальной и конечной даты задач. Если изменился график связанной задачи, перепланирование связанных с ней задач производится автоматически. Уточнить календарные планы задач можно с помощью конкретных ограничений дат и крайних сроков. Иногда задача может начинаться не сразу после окончания предыдущей задачи. В этом случае используют задержки или запаздывание. Запаздывание вводится как длительность, например: 1 день или как процент от длительности предшествующей задачи, например 50%. Часто для начала выполнения следующей задачи не нужно дожидаться окончания предыдущей, т.е. имеет место опережение. Опережение вводиться, так же как и запаздывание, но с отрицательным знаком. Ограничения, которые привязывают задачи к определенным датам, называются жесткими ограничениями; наиболее жесткие ограничений задают даты начала или окончания. Поскольку в Microsoft Project ограничения учитываются при расчете календарного плана, жесткие ограничения следует вводить, только если задачу необходимо начать или завершить в определенную дату. 1. Введите необходимые ограничения для задач проекта. Для задачи, завершающей проект обязательно введите ограничение Окончание не позднее и укажите запланированную дату окончания проекта. Создание повторяющихся задач Повторяющиеся задачи - это задачи, которые регулярно повторяются, например еженедельные собрания. 1. Чтобы ввести такую задачу в меню Вставка выберите команду Повторяющаяся задача. 2. В открывшемся окне определите Название задачи, длительность одного экземпляра задачи, например: 1 час. 3. Укажите ее периодичность, пределы повторения (начало – окончание). Суммарная задача проекта Суммарная задача предназначена для объединения всех проектных активностей. Чтобы отобразить суммарную задачу: 1. откройте меню Сервис, возьмите команду Параметры и на вкладке Вид установите галочку в окошке Показывать суммарную задачу. Задача вставиться как нулевая (самая первая в списке задач). 2. В окне Сведения о задаче введите название проекта. Проектный практикум Задание 4 Планирование ресурсов проекта 1. Создайте список ресурсов в соответствие с функциональными обязанностями членов команды, задайте стоимость ресурсов. 2. Распределите ресурсы на задачи, учтя выбранную структуру проекта. 3. При необходимости оптимизируйте распределение ресурсов. 4. Определите общий срок выполнения проекта. 5. Определите стоимость проекта. 6. Создайте отчет. Для этого экспортируйте план проекта в Word, при этом должны четко просматриваться названия задач и диаграмма Ганта. Укажите длительность проекта, его стоимость. Поясните, каким образом при планировании учтены стандарт и модель жизненного цикла ПО. Отчет сдайте преподавателю. Рекомендации к выполнению: Работа с Microsoft Project Создание списка ресурсов Лист ресурсов Microsoft Project используется для создания списка лиц, оборудования и материалов, составляющих рабочую группу и выполняющих задачи проекта. Список ресурсов будет содержать рабочие ресурсы или материальные ресурсы. Рабочие ресурсы - это сотрудники или оборудование; материальные ресурсы - это расходные материалы или сырье, например бетон, древесина или гвозди. 1. В меню Вид выберите представление Лист ресурсов 2. Введите список трудовых ресурсов – членов команды, участвующих в реализации проекта. 3. Определите стоимость каждого ресурса (стандартную ставку и ставку сверхурочных). Назначение ресурсов задачам Без сведений о ресурсах календарный план в Microsoft Project рассчитывается на основе длительности задачи, зависимостей и ограничений даты. Если ресурсы назначены, график работы и доступность ресурсов используются при расчете календарного плана. Если задаче назначается ресурс, создается назначение. Любой задаче можно назначить любые ресурсы, а также изменить назначения в любой момент. Задаче можно назначить несколько ресурсов, а также определить, все или не все рабочее время ресурс работает над задачей. Если назначенная ресурсу работа превышает ежедневную полную занятость, указанную в календаре рабочего времени ресурса, в Microsoft Project в представлениях ресурсов название перегруженного ресурса выделяется красным цветом. 1. Выберите команду Сервис – Выравнивание загрузки ресурсов. В открывшемся окне установите флажок Выполнять в ручную. 2. Выделите задачу, для которой нужно назначить ресурс. 3. Откройте окно Сведения о задаче и на вкладке Ресурсы введите Название и загрузку ресурсов, например: Менеджер проекта - 100%, Архитектор - 50%. 4. Введите ресурсы для всех задач в соответствие с возможностью задействовать те или иные ресурсы. После того как назначения созданы программа определяет материальные затраты и трудозатраты каждого из ресурсов для выполнения задачи и планирует распределение этих затрат на каждый день на протяжении всей длительности задачи. Результаты можно просмотреть на листе Использование ресурсов (меню Вид). В поле «Трудозатраты» отображается суммарное время, запланированное на выполнение задачи для всех назначенных ресурсов, суммарное время, запланированное для ресурса по всем назначенным задачам, или суммарное время, запланированное для ресурса по задаче. При назначении ресурса на задачу его стоимость определяется автоматически путем умножения ставки ресурса на трудозатраты и прибавлением к результату затрат на использование ресурса. Чтобы просмотреть затраты откройте представление Использование ресурсов и добавьте в таблицу столбец Затраты. Анализ стоимости проекта При анализе стоимости проекта обычно анализируется его бюджет и соотношение составляющих бюджета. В общем случае при анализе структуры затрат рассматривается распределение затрат по фазам проекта. 1. Откройте диаграмму Ганта. 2. Откройте в меню Вид таблицу Затраты, сверните все фазы. 3. Добавьте в таблицу столбец Затраты 1, в поле Текст заголовка введите Общая стоимость. 4. Откройте окно Настройка полей и переименуйте поле Затраты 1 в Общая стоимость. 5. Скопируйте во все строки этого столбца общую стоимость проекта из строки суммарной задачи. 6. Добавьте новое поле Число 1, назовите его % от общей стоимости. 7. Откройте окно Настройка полей и переименуйте поле Число 1 в % от общей стоимости. 8. Введите во все строки этого столбца формулу: Затраты/Затраты 1. Для этого в окне Настройка полей поставьте флажок Формула и откройте окно для ввода формулы (кнопка Формула), введите формулу, выбрав аргументы из списка полей. 9. В настройках поля уточните, что для расчета строк суммарных задач и групп нужно использовать туже формулу (флажок Использовать формулу). 10. После нажатия ОК в столбце % от общей стоимости отобразится распределение затрат на разработку сайта.

Проектный практикум Задание 1 Описание компании разработчика 1. Придумайте фирму, занимающуюся разработкой программного обеспечения. Определите: a. Название, количество персонала, b. Сферу деятельности, комплекс услуг, c. Миссию, d. Видение. 2. Разработайте организационную структуру фирмы: a. Создайте схему организационной структуры фирмы, b. Подробнее

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

Критерии выбора

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

Механизмы разработки ПО

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

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

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

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

Цель организации разработки ПО

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

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

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

Разработка ПС обычно производится в организации, в которой одновременно могут вестись разработки ряда других программных средств. Для управления всеми этими программными проектами используется иерархическая структура управления. Традиционная структура такого рода обсуждена в работе . Она представлена на рис. 14.1.

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

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

Рис. 14.1. Структура управления разработкой программных средств.

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

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

Наиболее употребительны три подхода к организации бригад разработчиков :

обычные бригады,

неформальные демократические бригады,

бригады ведущего программиста.

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

В неформальной демократической бригаде поручаемая ей работа обсуждается совместно всеми ее членами, а задания между ее членами распределяются согласованно в зависимости от способностей и опыта этих членов. Один из членов этой бригады является лидером (руководителем) бригады , но он также выполняет и некоторые задания, распределяемые между членами бригады. Неформальные демократические бригады могут весьма успешно справляться с порученной им работой, если большинство членов бригады являются опытными и компетентными специалистами. Если же неформальная демократическая бригада состоит, в основном, из неопытных и некомпетентных членов, в деятельности бригады могут возникать большие трудности. Без наличия в бригаде хотя бы одного квалифицированного и авторитетного члена, способного координировать и направлять работу членов бригады, эти трудности могут привести к неудаче проекта.

В бригаде ведущего программиста за разработку порученной программной подсистемы несет полную ответственность один человек, называемый ведущим программистом (chief programmer) и являющийся лидером бригады : он сам конструирует эту подсистему, составляет и отлаживает необходимые программы, пишет документацию к подсистеме. Ведущий программист выбирается из числа опытных и одаренных программистов. Все остальные члены такой бригады, в основном, создают условия для наиболее продуктивной работы ведущего программиста. Организацию такой бригады обычно сравнивают с хирургической бригадой . Ядро бригады ведущего программиста составляют три члена бригады: помимо ведущего программиста в него входит дублер ведущего программиста и администратор базы данных разработки. Дублер ведущего программиста (backup programmer) также является квалифицированным и опытным программистом, способным выполнить любую работу ведущего программиста, но сам он эту работу не делает. Главная его обязанность – быть в курсе всего, что делает ведущий программист. Он выступает в роли оппонента ведущего программиста при обсуждении его идей и предложений, но решения по всем обсуждаемым вопросам принимает единолично ведущий программист. Администратор базы данных разработки (librarian) отвечает за сопровождение всей документации (включая версии программ), возникающей в процессе разработки программной подсистемы, и снабжает членов бригады информацией о текущем состоянии разработки. Эта работа выполняется с помощью соответствующей инструментальной компьютерной поддержки (см. лекцию 16). В зависимости от объема и характера порученной работы в бригаду могут быть включены дополнительные члены, такие как

распорядитель бригады, выполняющий административные функции;

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

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

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

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

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

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

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

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

Различают два вида таких стандартов:

стандарты ПС (программного продукта),

стандарты процесса создания и использования ПС.

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

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

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

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

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

Время - деньги. Создание команды разработчиков программного обеспечения Салливан Эд

Модель организационной структуры компании NuMega

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

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

Менеджеры проекта;

Программисты;

Тестировщики;

Разработчики документации;

Инженерные психологи;

Технологи по разработке ПО;

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

Группа менеджмента и маркетинга продукта;

Специалисты по технической поддержке ПО;

Администраторы бета-тестирования.

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

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

Из книги Стратегическое управление автора Ансофф Игорь

4.3.5. Характеристика проекта организационной структуры Как уже упоминалось в гл. 3.2, первые опыты создания действенной организационной структуры привели к образованию трёх функциональных групп материально-вещественной деятельности фирмы: производства, маркетинга

Из книги CIO новый лидер. Постановка задач и достижение целей автора Китцис Эллен

British Airways используют ИТ для смены структуры издержек в компании Компания British Airways (ВА) – крупнейший в мире международный авиаперевозчик – перевозит около 40 млн пассажиров в год, ее самолеты летают в 94 страны, в компании работает 46 тысяч человек. После трагических событий

Из книги Управление карточным бизнесом в коммерческом банке автора Пухов Антон Владимирович

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

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

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

Из книги Как преодолеть кризисы менеджмента. Диагностика и решение управленческих проблем автора Адизес Ицхак Калдерон

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

Из книги Настольная книга по внутреннему аудиту. Риски и бизнес-процессы автора Крышкин Олег

Ограничения классической пирамидальной организационной структуры Давайте посмотрим на типичную организацию и проанализируем ее с помощью модели PAEI.Типичная организация подобна пирамиде – она иерархична по природе. Иерархическая организация обладает определенными

Из книги Отличная компания. Как стать работодателем мечты автора Робин Дженнифер

Формирование организационной структуры ПВА «Незаменимых людей нет…» Но есть невосполнимые потери. Система организации и управления аудиторским процессом и организационная структура ПВА должны обеспечивать постоянное возобновление человеческого ресурса – хорошо

Из книги Как сэкономить на маркетинге и не потерять его автора Монин Антон Алексеевич

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

Из книги Как создавать инновации автора Пратер Чарльз

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

Из книги Практика управления человеческими ресурсами автора Армстронг Майкл

Модель «Три арены компании-инноватора» Проанализировав свои наблюдения, которые мы сделали в Центре креативности и инноваций (Center for Creativity and Innovation) компании DuPont в самые первые месяцы его работы в начале 1991 года, мы синтезировали модель “Три арены компании-инноватора»,

Из книги Хватит платить за все! Снижение издержек в компании автора Гагарский Владислав

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

Из книги Управление рисками, аудит и внутренний контроль автора Филатов Александр Александрович

Модель организационной эффективности работы – Mercer HR Consulting Налбантьян с соавторами (2004) описывают в своем труде модель организационной эффективности работы, созданную Mercer HR Consulting на основе следующих элементов: людей, рабочих процессов, структуры управления, информации и

Из книги Совершенная машина продаж. 12 проверенных стратегий эффективности бизнеса автора Холмс Чет

ОПРЕДЕЛЕНИЕ ОРГАНИЗАЦИОННОЙ СТРУКТУРЫ Все организации имеют некоторый тип более или менее формализованной структуры. Чайлд (1977) определял ее как содержащую «все случайные и закономерные приходящие в голову характеристики, которые помогают формировать поведение

Из книги автора

Организационно-функциональная модель компании Организационно-функциональная модель (ОФМ) компании – это документ, описывающий организационную структуру (с определенной детализацией) и функции, выполняемые подразделениями компании.Как правило, в ОФМ как документ

Из книги автора

3. Место внутреннего аудита в организационной структуре компании Решение об организации внутреннего аудита принимается советом директоров, который также несет ответственность за контроль качества работы внутреннего аудита компании.Функция внутреннего аудита может

Из книги автора

Модель для крупной компании В крупной компании, как правило, имеются учебники и руководства, хотя они не отличаются особой глубиной. Слишком много места остается для интерпретации. Не считая те компании, в которых обучение проводил лично я, мне нигде не приходилось видеть