Реферат: Программное обеспечение

Методы и инструментальные средства выполнения работ.

Методы и средства контроля результатов работ.

Норма расхода ресурсов по отдельным работам.

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

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

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

В качестве технологической схемы в программостроении выступают клмандные планы и наборы заданий.

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

Техническое задание (ТЗ);

Нормативно-методическая документация (стандарты, методические материалы);

Архив технологических процессов по предыдущим резработкам;

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

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

Производится диспетчерское обслуживание разработки (контроля хожа выполнения задания);

В случае получения результатов об отклонении принимаются решения по корректировке процесса разработки;

Позволяют наращивать архив разработки и используются в дальнейшем.

Организация коллектива разработчиков.

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

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

При определении результата работы бригады может быть сформулировано частичное техническое задание.

Существуют два варианта бригад:

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

предметная область ПИ определяется в терминах того языка, который используется в предметной области (функционально и математическо ориентированные ППП);

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

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

При разработках второго вида распределение специалистов по бригадам может быть:

Формирование бригады.

…

Разрабатываются 2-3 программных изделия одной бригадой, параллельно, но с некоторым сдвигом по времени.

I		ТЗ	ТП	РП	ВН
II			ТЗ	ТП	РП
III				ТЗ	ТП

Формирование специализированных бригад (из специалистов одного профиля). Результат работы отдельной бригады не всегда представляет собой конечный результат разработки.

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

Если из-за сложности и масштабности разработки требуется большое число исполнителей и организация нескольких бригад, то рекомендуется:

Рассмотреть вопрос о специализации бригад по функциональному признаку;

Желательно внедрить ведущую, главную бригаду. Эта бригада выполняет наиболее существенное задание и как можно больше участвует в жизненном цикле. Бригаде даются другие бригады соисполнители (которые могут быть со своим ТЗ).

Профессиональный состав исполнителей.

Удобно увязать с этапами разработки (стадиями):

ТЗ - формируется 1 бригада (на предпроектной стадии). Руководитель разработки, высококвалифицированных постановщиков-аналитиков.

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

ТП (техническое проектирование) - ведущие постановщики с их подчиненными соисполнителями постановщиками. Ведущий постановщик выделяется по функциональному признаку. Каждому ведущему постановщику и его коллективу полезно придать консультанта-программиста.

РП (рабочее проектирование) - формируется коллективы программистов во главе с ведущим (программистом-консультантом) в случае необходимости постановщики становятся консультантами. … и специалисты по документированию.

ВН (внедрение) - ведущим становится постановщик, желательно включить в состав исполнителей представителей от заказчика.

Полезно выделить несколько лиц, стоящих вне бригад:

руководитель : не включается в состав никаких бригад :

“+” руководитель объективен ко всем бригадам и с точки зрения самих исполнителей;

“-“ руководитель теряет технологическую квалификацию и становится администратором.

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

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

Численный состав разработчиков:

Т - трудоемкость, t - срок разработки.

Если расчетная величина Т значительно отклоняется от технического задания, то можно вернуться к пересмотру численности или подобрать объем работ под срок и под численность.

T-tN, значит мы пересматриваем техническое задание.

Попутно решается вопрос о финансировании разработки. Сумма затрат в задании на разработку (S) выводится из численности (N), продолжительности работы (t) суммы фонда ЗП на одного разработчика (F). К - доля ЗП и затрат на труд в общих затратах на разработку:

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

Для крупных фирм специализирующихся на разработке К»0,3¸0,4;

Малые организационные формы в виде малых предприятий (20-30 чел.) К»0,5¸0,7;

Во временных коллективах К>0,8 ближе к 1.

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

а) специалисты разработки (службы разработки);

б) специалисты по обслуживанию (в том числе мат.-техн. обслуживание разработки, информационное обслуживание: получение сведений о других разработках и инструментах, методические материалы, патентная работа: обслуживание авторского права);

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

Работы по испытанию могут переходить в работы по сертификации (исследование чужого программного продукта с целью предоставления сертификата). Для этого необходимо выработать стандарты и выпустить документ с требованиями стандарта.

г) Работы по подготовке и выпуску документации. Документация в большей степени поддается стандартизации, чем работы по программированию. Желательна разработка стандартов в рамках отрасли …

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

е) Специалисты по сопровождению. Получает сведения об ошибках, пожеланиях, исправляет ошибка или ведет доработку ПИ.

ж) Специалисты технологического профиля.

В крупных специализированных организациях соотношение объемов работ разработки, испытаний, документирования (в чел.):

10 – 3 – 2

Во временных организациях:

10 – 5 – 3

Для координации работы связанной с деятельностью различных подразделений выпускающих ПП и сопутствующие материалы требуются работы по управлению такого рода организациями. Необходима координация планов :

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

Стратегические планы. Определяют какой продукт в какое время должен быть выпущен в свет для того, чтобы выполнить (1).

Текущие планы (тактические). Как, кто, когда, с помощью каких средств реализует перспективные планы, этапы и комплексные работы.

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

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

Специалисты связанные с управленческой деятельностью:

Определяют последовательность разработки продуктов;

Взаимосвязь плановых показателей в работе тематических и функциональных подразделений (осуществление координации работ этих подразделений);

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

Оценка потребности в ресурсах для выполнения работ и распределение имеющихся ресурсов по исполнителям;

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

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

Эти работы могут выполнятся в двух разрезах:

тематический;

организационно-временной.

В (1) все планы связаны с конкретным ПИ. Указываются все исполнители, ресурсы необходимые для разработки этого конкретного изделия (горизонтальный разрез матрицы ((*) см. выше).

ТЕМА … ППП …

ИНФОРМАЦИЯ ПО ТЕМЕ (руководитель, сроки, ресурсы …)

Этап (работа)	Срок выполнения		Исполнитель (служба)	Затраты ресурсов 1	Затраты ресурсов 2	Форма результата
	начало	конец

Во (2) случае все сведения приводятся по отдельному исполнителю (вертикальный разрез).

ИСПОЛНИТЕЛЬ (бригада, человек)

ПЛАН ПЕРИОД

Тема ПИ	Этап	Ответственный исполнитель	Затраты ресурса 1	…	Форма результата

Методы управления процессом разработки

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

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

t - время, затраченное с начала разработки;

ta - момент появления изделия в состоянии операционной готовности (может функционировать как единое целое)

К - объем ресурсов, выделяемых на разработку.

Если значение а брать достаточно большим и наклон кривой на участке 0-ta становится большим (крутым), то руководство разработкой усложняется. Руководитель не всегда может достаточно эффективно загрузить исполнителей работой. Это вызвано тем, что не все работы можно выполнять параллельно. Помимо функционально сложности разработки можно ввести понятие организационной сложности (оно вытекает из вопросов руководства).

(**) , где чем меньше значение t0, тем проще разработка.

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

Р - производительность труда:

(***)

С - зависит от применяемого инструментария (коэффициент пропорциональности). Например: С = 10 000 - язык высокого уровня исходящего из структурного программирования: С = 1, Д = 1, Р = 1; Д = 2, Р = 1,6)

S - объем программного изделия:

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

(*) , следовательно сокращение времени разработки требует увеличение затрат ресурсов (в степенной зависимости). Желание резко увеличить задействование ресурсов не дает линейного увеличения производительности требуется и пропорциональное этому сокращение затрат времени на разработку. При концентрации ресурсов во много раз увеличивается сложность, теряется эффективность взаимодействия множества программистов => не рекомендуется увеличивать затраты ресурсов более чем на 30% за полгода.

По мере увеличения размера создаваемого ПИ приходится увеличивать время разработки, независимо от того, какими ресурсами мы располагаем (слабая зависимость - 4 степень).

Соотношение (*) используется как основа для управления разработкой. Из соотношений (**) и (***) по значениям задаваемых параметров разрабатывается определенное значение выбираемых параметров разработки.

S,t0 - задаваемые значения (S - не явная характеристика, задана через функциональную нагрузку).

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

Результатные параметры (трудоемкость разработки) и исходя из срока разработки определяется количество исполнителей:

N=F/ta

В процессе разработки могут меняться некоторые характеристики:

меняются функциональные требования к ПИ;

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

В любом случае часть функций разрабатывается за время меньше, чем ta, при этом может не меняться S.

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

S = (d+4m+b)/6

d - минимально возможный объем разработки по мнению экспертов;

b - максимально возможный объем разработки по мнению экспертов;

m - среднее значение.

Тема 7: Стадии разработки ПИ. Содержание и методы выполнения работ.

Стадия ТЗ (предпроектная стадия). В настоящее время преобладающий объект разработки ПИ является программная реализация комплекса информационно и функционально взаимосвязанных задач.

разработка ПО по подсистемам;

разработка ПО для объекта в целом (реже встречается).

Основные альтернативы:

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

Следует ли проводить оригинальную разработку или возможна адаптация существующего ПО.

Если проводится оригинальная разработка, то ориентировать ли ее на изготовление локального ПИ, или же вести разработку тиражируемого ПП (например в виде ППП).

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

При планировании работ предпроектной стадии ориентировочно длительности его от 1 месяца, реже нескольких недель, и до 1 квартала.

Трудоемкость работ предпроектной стадии: от 15 чел./дней до 150 чел./дней. Чаще всего 30-50. Это означает, что на один комплекс задач выделяется 1-2 человека.

Примерно сложившаяся величина 10%, и если имеется дело с оригинальной разработкой, то эта доля уменьшается до 7-8%, или если с ППП то возрастает до 13-15%.

Работы по обследованию предметной области и технологических средств.

Начиная с определения организационной структуры обследуемого объекта. Каждому из символов необходимо сопоставить функциональные обязанности и подчинения. Это делается для:

знания кому делается;

возможности проникнуть в отдел.

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

Обследование ведется не по функциональному признаку, а по информационному.

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

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

При выявлении информационной схемы реализации функции необходимо рассмотреть все 3 аспекта, в которых определяется количество информации:

синтаксическом (символьным);

семантическим (как отдельные данные увязываются в документы, смысловая нагрузка информационных единиц);

прагматический (полезность для потребителя).