Планирование проекта и прослеживание. Отношения между людьми и усилием, страница 3

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

6.2.2. Эмпирические Отношения

Выбирая программное уравнение, мы можем демонстрировать очень нелинейные отношения между хронологическим временем, чтобы завершить проектное{строительное} и человеческое усилие, прикладное к проекту. Число{номер} поставленных линий кода (исходные утверждения{заявления}),L, связано с усилием и временем развития уравнением:

гдеE - усилие по развитию в месяцах человека,P - параметр производительности, который отражает разнообразие факторов, которые ведут к высококачественному программному обеспечению, проектируя работу (типичные значения для диапазонаP между 2 000 и 12 000), иt - проектная{строительная} продолжительность в календарных месяцах.

Перестраивая это программное уравнение, мы можем достигнуть выражения для усилия по развитиюE:

гдеE - израсходованное усилие (в годах человека) по полному циклу жизни для разработки программного обеспечения, и обслуживание иt - время развития в годах. Уравнение для усилия по развитию может быть связано с развитием, стоившимся включением обремененного трудового фактора нормы{разряда} ($/person-year).

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

6.2.3 Распределение Усилия

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

Это распределение усилия должно использоваться как директива только. Характеристики каждого проекта должны диктовать распределение усилия. Работа, израсходованная на проект, планирующий редко составляет{объясняет} больше чем 2-3 процента усилия, если план не передает{не совершает} организацию большим расходам с высоким риском. Анализ требований может включить 10-25 процентов проектного{строительного} усилия. Усилие, израсходованное на анализ или prototyping должно увеличиться в прямой пропорции с проектным{строительным} размером и сложностью. Диапазон 20 - 25 процентов усилия обычно применяется к программному дизайну. Время, израсходованное для обзора дизайна и последующей итерации нужно также рассмотреть{счесть}.

Из-за усилия, прикладного к программному дизайну, код должен следовать с относительно маленькой трудностью. Диапазон 15-20 процентов полного усилия может быть достигнут. Испытание и последующая отладка могут составлять{объяснять} 30-40 процентов усилия по разработке программного обеспечения. Критичность программного обеспечения часто диктует количество испытания, которое требуется. Если программное обеспечение человеческое номинальное (то есть, программный отказ{неудача} может кончиться потерей жизни), еще более высокие проценты типичны.

6.3 ОПРЕДЕЛЕНИЕ НАБОРА ЗАДАЧИ ДЛЯ ПРОГРАММНОГО ПРОЕКТА.

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