Телефон: 8-800-350-22-65
WhatsApp: 8-800-350-22-65
Telegram: sibac
Прием заявок круглосуточно
График работы офиса: с 9.00 до 18.00 Нск (5.00 - 14.00 Мск)

Статья опубликована в рамках: LXI Международной научно-практической конференции «Научное сообщество студентов: МЕЖДИСЦИПЛИНАРНЫЕ ИССЛЕДОВАНИЯ» (Россия, г. Новосибирск, 24 января 2019 г.)

Наука: Информационные технологии

Скачать книгу(-и): Сборник статей конференции

Библиографическое описание:
Резвая А.П. ПЛАНИРОВАНИЕ РЕАЛИЗАЦИИ ПРОЕКТА В РАМКАХ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ // Научное сообщество студентов: МЕЖДИСЦИПЛИНАРНЫЕ ИССЛЕДОВАНИЯ: сб. ст. по мат. LXI междунар. студ. науч.-практ. конф. № 2(61). URL: https://sibac.info/archive/meghdis/2(61).pdf (дата обращения: 26.04.2024)
Проголосовать за статью
Конференция завершена
Эта статья набрала 0 голосов
Дипломы участников
У данной статьи нет
дипломов

ПЛАНИРОВАНИЕ РЕАЛИЗАЦИИ ПРОЕКТА В РАМКАХ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

Резвая Анна Павловна

студент, кафедра менеджмента САФУ им. М. В. Ломоносова,

РФ, г. Архангельск

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

При планировании должны учитываться следующие факторы:

1) цели, которые мы стремимся достигнуть:

- обеспечить функциональность проекта в соответствии с требованиями к полноте набора функций и к их реализации;

- выполнить нефункциональные требования;

- не нарушить сроки реализации;

- уложиться в бюджет проекта;

- разработать способы внедрения (продвижения).

2) ресурсы, которыми мы располагаем:

- специалисты, их компетентность, опыт и мотивация;

- процессы организации, процессы управления и технологические процессы.

3) действия, которые мы должны совершить, и события, которые должны случиться:

- последовательность действий;

- причинно-следственные связи между действиями и событиями;

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

4) прогнозируемое состояние внешнего окружения:

- состояние рынка на момент реализации проекта;

- влияние внешнего окружения на реализацию проекта.

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

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

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

2) организовать коллектив на достижение поставленной цели. Каждый участник должен знать:

- что, когда и в какой последовательности он должен делать для реализации проекта;

- с кем и при каких условиях он должен согласовывать свои решения и действия;

- к кому обратиться в случае невозможности выполнить порученную работу и т. д.;

3) составить план управления проектом. Руководитель должен определить методы, критерии и время контроля состояния реализации проекта; определить методы управления процессом реализации проекта.

Проведем классификацию методов планирования.

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

1) Новое все. Мы никогда не делали подобные проекты и пока не знаем, какими методами будем пользоваться.

2) Новый объект. Объект разработки должен обладать принципиально новыми свойствами и удовлетворять новым требованиям. Поэтому нам не удалось подыскать аналог среди ранее реализованных проектов.

3) Проект аналогичен ранее реализованному. Мы уже разрабатывали подобные проекты. У нас имеется сложившаяся процедура разработки подобных проектов. Специфика нового проекта нами осознана и мы, в принципе, понимаем, как ее реализовать.

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

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

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

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

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

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

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

Рассмотрим нормативные методы планирования.

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

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

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

Рассмотрим планирование на основе систематизации накопленного опыта.

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

 

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

 

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

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

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

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

В заключении рассмотрим адаптацию стандартного процесса разработки.

В таблице 1 сведены факторы, которые следует учитывать при выборе и адаптации стандартного процесса для разработки конкретного проекта.

Таблица 1.

Факторы, влияющие на выбор и адаптацию стандартного процесса разработки

Фактор

Градации значений фактора

1.Опыт и квалификация разработчиков и менеджеров

Высокий

Низкий

Большинство разработчиков имеет более чем двухлетний опыт разработки проектов с аналогичной технологией

Разработчиков с достаточным опытом меньшинство

2.Ясность требований

Высокая

Удовлетворительная

Низкая

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

Для интерпретации и уточнения части требований необходимы рабочие совещания

Ожидается, что многие требования будут добавлены или изменены в ходе реализации проекта

3.Численность команды

Большая

Средняя

Малая

>10 человек

4-10 человек

1-2 человека

4.Продолжительность разработки

Долгая

Средняя

Короткая

    >1 года

До года

< 3-х мес.

5.Критичность разработки

Критическая

Некритическая

Оказывает существенное влияние на пользователя или разработчика

Не оказывает существенного влияния

 

Список литературы:

  1. Информатика и программирование: программные средства реализации информационных процессов: учебник / А. А. Захарова, Е. В. Молнина, Т. Ю. Чернышева – 3-е изд. – Томск, 2013 – 318 с.
Проголосовать за статью
Конференция завершена
Эта статья набрала 0 голосов
Дипломы участников
У данной статьи нет
дипломов

Оставить комментарий

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