Руководство программным проектом это

1.

Руководство программным
проектом

2.

Цели
• Процесс руководства проектом
• Планирование проектных задач
• Размерно-ориентированные метрики
• Функционально-ориентированные метрики
• Конструктивная модель стоимости
2

3.

Процесс руководства проектом
3

4.

Процесс руководства проектом
Руководство программным проектом — первый слой
процесса конструирования ПО. Термин «слой»
подчеркивает, что руководство определяет сущность
процесса разработки от его начала до конца.

5.

Процесс руководства проектом
Для проведения успешного проекта нужно понять
• объем предстоящих работ,
• возможный риск,
• требуемые ресурсы,
• предстоящие задачи,
• прокладываемые вехи,
• необходимые усилия (стоимость),
• план работ, которому желательно следовать.
Руководство программным проектом обеспечивает такое
понимание. Оно начинается перед технической работой,
продолжается по мере развития ПО от идеи к реальности и
достигает наивысшего уровня к концу работ
5

6.

Начало проекта
Перед планированием проекта следует:
• установить цели и проблемную область
проекта;
• обсудить альтернативные решения;
• выявить технические и управленческие
ограничения.
6

7.

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

8.

Анализ риска
На этой стадии:
• Исследуется область неопределенности, имеющаяся
в наличии перед созданием программного продукта.
• Анализируется ее влияние на проект.
• Нет ли скрытых от внимания трудных технических
проблем?
• Не станут ли изменения, проявившиеся в ходе
проектирования, причиной недопустимого отставания
по срокам?
В результате принимается решение — выполнять
проект или нет.
8

9.

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

10.

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

11.

Планирование проектных задач
Основной задачей при планировании является определение
WBS — Work Breakdown Structure (структуры распределения
работ). Она составляется с помощью утилиты планирования
проекта. Типовая WBS приведена на рис.
11

12.

Системный анализ проводится
с целью:
1)
выяснения потребностей заказчика;
2)
оценки выполнимости системы;
3)
выполнения экономического и
технического анализа;
4)
распределения функций по элементам
компьютерной системы (аппаратуре,
программам, людям, базам данных и т. д.);
5)
определения стоимости и ограничений
планирования;
6)
создания системной спецификации.
12

13.

Вехи
• Вехи — процедуры контроля промежуточных результатов.
Очень важно, чтобы вехи были расставлены через
регулярные интервалы (вдоль всего процесса разработки
ПО). Это даст руководителю возможность регулярно
получать информацию о текущем положении дел. Вехи
распространяются и на документацию как на один из
результатов успешного решения задачи.
• Параллельность действий повышает требования к
планированию. Так как параллельные задачи
выполняются асинхронно, планировщик должен
определить межзадачные зависимости. Это гарантирует
«непрерывность движения к объединению». Кроме того,
руководитель проекта должен знать задачи, лежащие на
критическом пути. Для того чтобы весь проект был
выполнен в срок, необходимо выполнять в срок все
13
критические задачи.

14.

Затраты времени
Рекомендуемое правило распределения затрат
проекта — 40-20-40:
• на анализ и проектирование приходится 40%
затрат (из них на планирование и системный
анализ — 5%);
• на кодирование — 20%;
• на тестирование и отладку — 40%.
14

15.

Метрики
Программного проекта
15

16.

Размерно-ориентированные
метрики (1)
• Размерно-ориентированные метрики прямо измеряют
программный продукт и процесс его разработки.
Основываются размерно-ориентированные метрики на LOCоценках (Lines Of Code). LOC-оценка — это количество строк в
программном продукте.
• Исходные данные для расчета этих метрик сводятся в
таблицу (данные за последние несколько лет).
16

17.

Размерно-ориентированные
метрики (2)
• На основе таблицы вычисляются размерноориентированные метрики производительности и
качества (для каждого проекта):
17

18.

Размерно-ориентированные
метрики (3)
Общими особенностями гибких методологий3являются:
• Ориентированность на людей – как разработчиков, так и
заказчиков (согласие участвовать в разработке). Считается,
что умение собрать в проектной команде «правильных»
людей определяет успех или неудачу проекта в значительно
большей степени, чем любые процессы или технологии.
• Использование устных обсуждений вместо формальных
спецификаций везде, где это возможно.
• Итеративная разработка с возможно более короткой (в
разумных пределах) продолжительностью итерации, при
этом в результате каждой итерации выпускается
полноценная работающая версия продукта.
• Ожидание изменений – в гибком процессе проектная команда
не пытается зафиксировать требования в начале проекта и
затем следовать жестко определенному плану. Изменения 18

19.

Размерно-ориентированные
метрики (4)
Достоинства размерно-ориентированных метрик:
• 1) широко распространены;
• 2) просты и легко вычисляются.
Недостатки размерно-ориентированных метрик:
• 1) зависимы от языка программирования;
• 2) требуют исходных данных, которые трудно получить
на начальной стадии проекта;
• 3) не приспособлены к непроцедурным языкам
программирования.
19

20.

Функциональноориентированные метрики (1)
• Функционально-ориентированные метрики косвенно измеряют
программный продукт и процесс его разработки. Вместо
подсчета LOC-оценки при этом рассматривается не размер, а
функциональность или полезность продукта.
• Используется 5 информационных характеристик.
1. Количество внешних вводов. Подсчитываются все вводы
пользователя, по которым поступают разные прикладные
данные. Вводы должны быть отделены от запросов, которые
подсчитываются отдельно.
2. Количество внешних выводов. Подсчитываются все выводы,
по которым к пользователю поступают результаты, вычисленные
программным приложением. В этом контексте выводы означают
отчеты, экраны, распечатки, сообщения об ошибках.
Индивидуальные единицы данных внутри отчета отдельно не
подсчитываются.
20

21.

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

22.

Функциональноориентированные метрики (3)
• После сбора всей необходимой информации приступают к
расчету метрики — количества функциональных
указателей FP (Function Points). Автором этой метрики
является А. Албрехт (1979) [7].
• Исходные данные для расчета сводятся в табл.
22

23.

Функциональноориентированные метрики (4)
• В таблицу заносится количественное значение
характеристики каждого вида (по всем уровням сложности).
Места подстановки значений отмечены прямоугольниками
(прямоугольник играет роль метки-заполнителя).
Количественные значения характеристик умножаются на
числовые оценки сложности. Полученные в каждой строке
значения суммируются, давая полное значение для данной
характеристики. Эти полные значения затем суммируются по
вертикали, формируя общее количество.
• Количество функциональных указателей вычисляется по
формуле
где Fi — коэффициенты регулировки сложности.
23

24.

Функциональноориентированные метрики (5)
Каждый коэффициент может принимать следующие
значения: 0 — нет влияния, 1 — случайное, 2 — небольшое,
3 — среднее, 4 — важное, 5 — основное.
Значения выбираются эмпирически в результате ответа на
14 вопросов, которые характеризуют системные параметры
приложения:
24

25.

Определение системных
параметров приложения
25

26.

Определение системных
параметров приложения (прод.)
После вычисления FP на его основе формируются метрики
производительности, качества и т. д.:
26

27.

Функциональноориентированные метрики (6)
• Область применения метода функциональных указателей
— коммерческие информационные системы. Для
продуктов с высокой алгоритмической сложностью
используются метрики указателей свойств (Features
Points). Они применимы к системному и инженерному ПО,
ПО реального времени и встроенному ПО.
• Достоинства функционально-ориентированных метрик:
• 1. Не зависят от языка программирования.
• 2. Легко вычисляются на любой стадии проекта.
• Недостаток функционально-ориентированных метрик:
результаты основаны на субъективных данных,
используются не прямые, а косвенные измерения. FPоценки легко пересчитать в LOC-оценки.
27

28.

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

29.

Выполнение оценки проекта на
основе LOC- и FP-метрик
Цель этой деятельности — сформировать предварительные
оценки, которые позволят:
• предъявить заказчику корректные требования по стоимости и
затратам на разработку программного продукта;
• составить план программного проекта.
При выполнении оценки возможны два варианта использования
LOC- и FP-данных:
• в качестве оценочных переменных, определяющих размер
каждого элемента продукта;
• в качестве метрик, собранных за прошлые проекты и
входящих в метрический базис фирмы.
29

30.

Шаги процесса оценки (1)
•Шаг 1. Область назначения проектируемого продукта
разбивается на ряд функций, каждую из которых можно
оценить индивидуально: f1, f2,…,fn.
•Шаг 2. Для каждой функции fi, планировщик формирует
лучшую LOCлучшi (FРлучшi), худшую LOCхудшi (FРхудшi) и
вероятную оценку LOCвероятнi (FРвероятнi). Используются
опытные данные (из метрического базиса) или интуиция.
Диапазон значения оценок соответствует степени
предусмотренной неопределенности.
•Шаг 3. Для каждой функции в соответствии с распределением вычисляется ожидаемое значение LOC(или FP-) оценки:
•LOCожi =(LOCлучшi + LOCхудшi +4x LOCвероятнi )/ 6.
30

31.

Шаги процесса оценки (2)
•Шаг 4. Определяется значение LOC- или FPпроизводительности разработки функции.
•Используется один из трех подходов:
•1)для всех функций принимается одна и та же метрика средней
производительности ПРОИЗВср, взятая из метрического базиса;
•2)для i-й функции на основе метрики средней
производительности вычисляется настраиваемая величина
производительности: ПРОИЗВi =ПРОИЗВсрх(LOCср /LOCожi),
где LOCcp — средняя LOC-оценка, взятая из метрического
базиса (соответствует средней производительности);
3) для i-й функции настраиваемая величина
производительности вычисляется по аналогу, взятому из
метрического базиса: ПРОИЗВi =ПРОИЗВанiх(LOCанi /LOCожi).
•Первый подход обеспечивает минимальную точность), а третий
31
подход — максимальную точность.

32.

Шаги процесса оценки (3)
Шаг 5. Вычисляется общая оценка затрат на проект: для первого
подхода
• для второго и третьего подходов
Шаг 6. Вычисляется общая оценка стоимости проекта: для
первого и второго подходов
где УД_СТОИМОСТЬср — метрика средней стоимости одной
строки, взятая из метрического базиса.
• для третьего подхода
где УД_СТОИМОСТЬанi — метрика стоимости одной строки
аналога, взятая из метрического базиса.
32

33.

Конструктивная модель стоимости
• В данной модели для вывода формул использовался
статистический подход — учитывались реальные результаты
огромного количества проектов. Автор оригинальной модели
— Барри Боэм (1981) —дал ей название СОСОМО 81
(Constructive Cost Model) и ввел в ее состав три разные по
сложности статистические подмодели.
Иерархию подмоделей Боэма (версии 1981 года) образуют:
• базисная СОСОМО — статическая модель, вычисляет затраты
разработки и ее стоимость как функцию размера программы;
• промежуточная СОСОМО — дополнительно учитывает
атрибуты стоимости, включающие основные оценки продукта,
аппаратуры, персонала и проектной среды;
• усовершенствованная СОСОМО — объединяет все
характеристики промежуточной модели, дополнительно
учитывает влияние всех атрибутов стоимости на каждый этап
процесса разработки ПО (анализ, проектирование и т.д.) 33

34.

Конструктивная модель
стоимости
• Подмодели СОСОМО 81 могут применяться к трем типам
программных проектов. По терминологии Боэма, их
образуют:
• распространенный тип — небольшие программные
проекты, над которыми работает небольшая группа
разработчиков с хорошим стажем работы,
устанавливаются мягкие требования к проекту;
• полунезависимый тип — средний по размеру проект,
выполняется группой разработчиков с разным опытом,
устанавливаются как мягкие, так и жесткие требования к
проекту;
• встроенный тип — программный проект
разрабатывается в условиях жестких аппаратных,
программных и вычислительных ограничений.
34

35.

Уравнения базовой подмодели
Уравнения базовой подмодели имеют вид
• Е=аbx(KLOC) [чел-мес];
• D = cbx (E) [мес],
где Е — затраты в человеко-месяцах, D — время
разработки, KLOC — количество строк в программном
продукте.
Коэффициенты аb, bb, сb, db берутся из табл.
35

36.

Модель СОСОМО II
• В 1995 году Боэм ввел более совершенную модель
СОСОМО II, ориентированную на применение в
программной инженерии XXI века.
В состав СОСОМО II входят:
• модель композиции приложения;
• модель раннего этапа проектирования;
• модель этапа пост-архитектуры.
Для описания моделей СОСОМО II требуется информация о
размере программного продукта. Возможно использование
LOC-оценок, объектных указателей, функциональных
указателей.
36

37.

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

38.

Модель композиции
приложения (2)
• Проектные затраты оцениваются по формуле
ЗАТРАТЫ = NOP /PROD [чел.-мес],
где PROD — производительность разработки, выраженная в
терминах объектных указателей;
NOP — количество новых объектных указателей:
NOP = (Объектные указатели) х [(100 — %REUSE) /100],
%REUSE — процент повторного использования
программных компонентов.
38

39.

Модель раннего этапа
проектирования
• Модель раннего этапа проектирования используется в период,
когда стабилизируются требования и определяется базисная
программная архитектура.
• Основное уравнение этой модели имеет следующий вид:
где:
• масштабный коэффициент А = 2,5;
• показатель В отражает нелинейную зависимость затрат от
размера проекта (размер системы РАЗМЕР выражается в
тысячах LOC);
• множитель поправки Мe зависит от 7 формирователей затрат,
характеризующих продукт, процесс и персонал;
• слагаемое 3ATPATЫauto отражает затраты на автоматически
генерируемый программный код.
39

40.

Модель этапа постархитектуры
• Модель этапа постархитектуры используется в период, когда
уже сформирована архитектура и выполняется дальнейшая
разработка программного продукта.
• Основное уравнение постархитектурной модели является
развитием уравнения предыдущей модели и имеет следующий
вид:
ЗАТРАТЫ = А х К~req х РАЗМЕРB х Мр +3ATPATЫauto [чел.-мес], где
• коэффициент К~req учитывает возможные изменения в
требованиях;
• показатель В отражает нелинейную зависимость затрат от
размера проекта (размер выражается в KLOC), вычисляется
так же, как и в предыдущей модели;
• в размере проекта различают две составляющие — новый код
и повторно используемый код;
• множитель поправки Мр зависит от 17 факторов затрат,
характеризующих продукт, аппаратуру, персонал и проект. 40

41.

Стоимость проекта
• От оценки затрат легко перейти к стоимости проекта. Переход
выполняют по формуле:
СТОИМОСТЬ = ЗАТРАТЫ х РАБ_ КОЭФ,
где среднее значение рабочего коэффициента составляет
$15000 за человеко-месяц.
• После определения затрат и стоимости можно оценить
длительность разработки.
• Модель СОСОМО II содержит уравнение для оценки
календарного времени TDEV, требуемого для выполнения
проекта. Для моделей всех уровней справедливо:
41

42.

Оценка календарного времени
• Длительность (TDEV) = [3,0 х (ЗАТРАТЫ)(0,33+0,2(B-1,01))] х
SCEDPercentage/100 [мес],
где
• В — ранее рассчитанный показатель степени;
• SCEDPercentage — процент увеличения (уменьшения)
номинального графика.
• Если нужно определить номинальный график, то
принимается SCEDPercentage =100 и правый сомножитель
в уравнении обращается в единицу. Следует отметить, что
СОСОМО II ограничивает диапазон
уплотнения/растягивания графика (от 75 до 160%). Причина
проста — если планируемый график существенно
отличается от номинального, это означает внесение в
проект высокого риска.
42

43.

Модель СОСОМО II
• Модель СОСОМО II явно утверждает, что длительность
проекта является функцией требуемых затрат, прямой
зависимости от количества сотрудников нет. Другими
словами, она устраняет миф нерадивых менеджеров в том,
что добавление людей поможет ликвидировать отставание в
проекте.
• СОСОМО II предостерегает от определения потребного
количества сотрудников путем деления затрат на
длительность проекта. Такой упрощенный подход часто
приводит к срыву работ. Реальная картина имеет другой
характер. Количество людей, требуемых на этапе
планирования и формирования требований, достаточно
мало. На этапах проектирования и кодирования потребность
в увеличении команды возрастает, после окончания
кодирования и тестирования численность необходимых
43
сотрудников достигает минимума.

From Wikipedia, the free encyclopedia

Software project management is the process of planning and leading software projects.^[1] It is a sub-discipline of project management in which software projects are planned, implemented, monitored and controlled.

History[edit]

In the 1970s and 1980s, the software industry grew very quickly, as computer companies quickly recognized the relatively low cost of software production compared to hardware production and circuitry. To manage new development efforts, companies applied the established project management methods, but project schedules slipped during test runs, especially when confusion occurred in the gray zone between the user specifications and the delivered software. To be able to avoid these problems, software project management methods focused on matching user requirements to delivered products, in a method known now as the waterfall model.

As the industry has matured, analysis of software project management failures has shown that the following are the most common causes:^[2][3][4]

1. Insufficient end-user involvement
2. Poor communication among customers, developers, users and project managers
3. Unrealistic or unarticulated project goals
4. Inaccurate estimates of needed resources
5. Badly defined or incomplete system requirements and specifications
6. Poor reporting of the project’s status
7. Poorly managed risks
8. Use of immature technology
9. Inability to handle the project’s complexity
10. Sloppy development practices
11. Stakeholder politics (e.g. absence of executive support, or politics between the customer and end-users)
12. Commercial pressures

The first five items in the list above show the difficulties articulating the needs of the client in such a way that proper resources can deliver the proper project goals. Specific software project management tools are useful and often necessary, but the true art in software project management is applying the correct method and then using tools to support the method. Without a method, tools are worthless. Since the 1960s, several proprietary software project management methods have been developed by software manufacturers for their own use, while computer consulting firms have also developed similar methods for their clients. Today software project management methods are still evolving, but the current trend leads away from the waterfall model to a more cyclic project delivery model that imitates a software development process.

Software development process[edit]

A software development process is concerned primarily with the production aspect of software development, as opposed to the technical aspect, such as software tools. These processes exist primarily for supporting the management of software development, and are generally skewed toward addressing business concerns. Many software development processes can be run in a similar way to general project management processes. Examples are:

• Interpersonal communication and conflict management and resolution. Active, frequent and honest communication is the most important factor in increasing the likelihood of project success and mitigating problematic projects. The development team should seek end-user involvement and encourage user input in the development process. Not having users involved can lead to misinterpretation of requirements, insensitivity to changing customer needs, and unrealistic expectations on the part of the client. Software developers, users, project managers, customers and project sponsors need to communicate regularly and frequently. The information gained from these discussions allows the project team to analyze the strengths, weaknesses, opportunities and threats (SWOT) and to act on that information to benefit from opportunities and to minimize threats. Even bad news may be good if it is communicated relatively early, because problems can be mitigated if they are not discovered too late. For example, casual conversation with users, team members, and other stakeholders may often surface potential problems sooner than formal meetings. All communications need to be intellectually honest and authentic, and regular, frequent, high quality criticism of development work is necessary, as long as it is provided in a calm, respectful, constructive, non-accusatory, non-angry fashion. Frequent casual communications between developers and end-users, and between project managers and clients, are necessary to keep the project relevant, useful and effective for the end-users, and within the bounds of what can be completed. Effective interpersonal communication and conflict management and resolution are the key to software project management. No methodology or process improvement strategy can overcome serious problems in communication or mismanagement of interpersonal conflict. Moreover, outcomes associated with such methodologies and process improvement strategies are enhanced with better communication. The communication must focus on whether the team understands the project charter and whether the team is making progress towards that goal. End-users, software developers and project managers must frequently ask the elementary, simple questions that help identify problems before they fester into near-disasters. While end-user participation, effective communication and teamwork are not sufficient, they are necessary to ensure a good outcome, and their absence will almost surely lead to a bad outcome.^[3][4][5]
• Risk management is the process of measuring or assessing risk and then developing strategies to manage the risk. In general, the strategies employed include transferring the risk to another party, avoiding the risk, reducing the negative effect of the risk, and accepting some or all of the consequences of a particular risk. Risk management in software project management begins with the business case for starting the project, which includes a cost-benefit analysis as well as a list of fallback options for project failure, called a contingency plan.
  • A subset of risk management is Opportunity Management, which means the same thing, except that the potential risk outcome will have a positive, rather than a negative impact. Though theoretically handled in the same way, using the term «opportunity» rather than the somewhat negative term «risk» helps to keep a team focused on possible positive outcomes of any given risk register in their projects, such as spin-off projects, windfalls, and free extra resources.
• Requirements management is the process of identifying, eliciting, documenting, analyzing, tracing, prioritizing and agreeing on requirements and then controlling change and communicating to relevant stakeholders. New or altered computer system^[1] Requirements management, which includes Requirements analysis, is an important part of the software engineering process; whereby business analysts or software developers identify the needs or requirements of a client; having identified these requirements they are then in a position to design a solution.
• Change management is the process of identifying, documenting, analyzing, prioritizing and agreeing on changes to scope (project management) and then controlling changes and communicating to relevant stakeholders. Change impact analysis of new or altered scope, which includes Requirements analysis at the change level, is an important part of the software engineering process; whereby business analysts or software developers identify the altered needs or requirements of a client; having identified these requirements they are then in a position to re-design or modify a solution. Theoretically, each change can impact the timeline and budget of a software project, and therefore by definition must include risk-benefit analysis before approval.
• Software configuration management is the process of identifying, and documenting the scope itself, which is the software product underway, including all sub-products and changes and enabling communication of these to relevant stakeholders. In general, the processes employed include version control, naming convention (programming), and software archival agreements.
• Release management is the process of identifying, documenting, prioritizing and agreeing on releases of software and then controlling the release schedule and communicating to relevant stakeholders. Most software projects have access to three software environments to which software can be released; Development, Test, and Production. In very large projects, where distributed teams need to integrate their work before releasing to users, there will often be more environments for testing, called unit testing, system testing, or integration testing, before release to User acceptance testing (UAT).
  • A subset of release management that is gaining attention is Data Management, as obviously the users can only test based on data that they know, and «real» data is only in the software environment called «production». In order to test their work, programmers must therefore also often create «dummy data» or «data stubs». Traditionally, older versions of a production system were once used for this purpose, but as companies rely more and more on outside contributors for software development, company data may not be released to development teams. In complex environments, datasets may be created that are then migrated across test environments according to a test release schedule, much like the overall software release schedule.
• Maintenance and update is the process where Requirements and customer needs are always involving. They will undoubtedly find bugs, may request new features and ask for different functionality and more updates. So, all of these requests need to check and fulfill the customer’s requirements and satisfaction.

Project planning, execution, monitoring and control[edit]

The purpose of project planning is to identify the scope of the project, estimate the work involved, and create a project schedule. Project planning begins with requirements that define the software to be developed. The project plan is then developed to describe the tasks that will lead to completion. The project execution is the process of completing the tasks defined in the project plan.

The purpose of project monitoring and control is to keep the team and management up to date on the project’s progress. If the project deviates from the plan, then the project manager can take action to correct the problem. Project monitoring and control involves status meetings to gather status from the team. When changes need to be made, change control is used to keep the products up to date.

Issue[edit]

In computing, the term «issue» is a unit of work to accomplish an improvement in a system.^{[citation needed]} An issue could be a bug, a requested feature, task, missing documentation, and so forth.

For example, OpenOffice.org used to call their modified version of Bugzilla IssueZilla. As of September 2010, they call their system Issue Tracker.^{[needs update]}

Severity levels[edit]

Issues are often categorized in terms of severity levels. Different companies have different definitions of severities, but some of the most common ones are:

High

The bug or issue affects a crucial part of a system, and must be fixed in order for it to resume normal operation.

Medium

The bug or issue affects a minor part of a system, but has some impact on its operation. This severity level is assigned when a non-central requirement of a system is affected.

Low / Fixed

The bug or issue affects a minor part of a system, and has very little impact on its operation. This severity level is assigned when a non-central requirement of a system (and with lower importance) is affected.

Trivial (cosmetic, aesthetic)

The system works correctly, but the appearance does not match the expected one. For example: wrong colors, too much or too little spacing between contents, incorrect font sizes, typos, etc. This is the lowest severity issue.

Issue management[edit]

In some implementations of software development processes, issues are investigated by quality assurance analysts a system is verified for correctness, and then assigned back to a member of the development team to resolve the identified issue. They can also be identified by system users during the User Acceptance Testing (UAT) phase.

Issues can be recorded and communicated using Issue or Defect Tracking Systems. In the absence of a formal Issue or Defect Tracking system, it is commonplace to simply use any form of written communication such as emails or instant messages to communicate the existence of a found issue.

Philosophy[edit]

As a subdiscipline of project management, some regard the management of software development akin to the management of manufacturing, which can be performed by someone with management skills, but no programming skills. John C. Reynolds rebuts this view, and argues that software development is entirely design work, and compares a manager who cannot program to the managing editor of a newspaper who cannot write.^[6]

References[edit]

General

• 16326:2019(E) — ISO/IEC/IEEE International Standard — Systems and software engineering — Life cycle processes — Project management. 2019. doi:10.1109/IEEESTD.2019.8932690. ISBN 978-1-5044-6299-0.
• 1058-1998 — IEEE Standard for Software Project Management Plans. 1998. doi:10.1109/IEEESTD.1998.88822. ISBN 978-0-7381-1448-4.
• Jalote, Pankaj (2002). Software project management in practice. Addison-Wesley. ISBN 0-201-73721-3.
• Murali Chemuturi, Thomas M. Cagley Jr. & (2010). Software Project Management: Best Practices, Tools and Techniques. J.Ross Publishing. ISBN 978-1-60427-034-1.

External links[edit]

• Media related to Software project management at Wikimedia Commons

Project failure[edit]

• Robert Frese (2003-12-16). «PROJECT SUCCESS AND FAILURE: WHAT IS SUCCESS, WHAT IS FAILURE, AND HOW CAN YOU IMPROVE YOUR ODDS FOR SUCCESS?». University of Missouri-St. Louis. Retrieved 2015-05-13.