Реферат Разработка и применение пакетов прикладных программ
Работа добавлена на сайт bukvasha.net: 2015-10-28Поможем написать учебную работу
Если у вас возникли сложности с курсовой, контрольной, дипломной, рефератом, отчетом по практике, научно-исследовательской и любой другой работой - мы готовы помочь.
Предоплата всего
от 25%
Подписываем
договор
Тема 1: Программное обеспечение, его классификация состояние и перспективы развития.
Программное обеспечение – совокупность программ, ЭВМ, процедур и правил вместе со всей, связанной с этими компонентами, документацией позволяющей использовать ВТ для решения конкретных задач.
Доля заработной платы в доходах фирмы – 46-56%.
1–вый этап : Разработка ПО для собственных нужд;
2–ой этап : Становление товарного производства программной продукции. Появление и распространение отчуждаемого и тиражируемого продукта;
3–ий этап : Экстенсивное производство ПО;
4–ый этап : Переход к интенсивному производству ПО. Появляется технологическая обработка ПО. Использование автоматизированных и типовых средств обработки (исходных прототипов).
Основные термины определяются: во–первых, стандартом ЕСПД (19.004) и ряд терминов определяется законом “О правовой охране программ для ЭВМ и баз данных” 1992 год.
Программное изделие (ПИ) – программа на носителе данных, являющаяся продуктом программного производства.
Программа – объективная форма представления совокупности данных и команд, предназначенных для функционирования ЭВМ и других компьютерных устройств с целью получения определенного результата. Программа для ЭВМ – подготовительные материалы полученные в ходе ее разработки и порождаемые ею аудио–визуальные изображения.
ПИ – универсальное изделие, предназначенное для широкого круга пользователей.
ПИ – изделие, предназначенное для широкого употребления, оно должно быть тщательно документировано, чтобы его могли использовать не только разработчики.
Программный продукт – любая программная разработка, которая может быть получена не только как результат промышленного производства.
Программное средство (ПС) – программа, предназначенная для многократного применения на различных объектах и разработанная любым способом (чаще всего имеют ввиду – средства производства ПИ, и инструментарий для разработки ПИ).
Классификация ПО (по областям применения)
АП – средства контроля аппаратуры, диагностика работы аппаратуры.
ОС – управление ресурсами ЭВМ (иногда объединяются с с/с программирования)
Система программирования – совокупность средств разработки программ. Обеспечивает автоматизацию составления, отладки и испытания программ (языковые средства, трансляторы, редакторы, отладчики, сервисные программы).
Прикладные программы частного применения – эксплуатируются на одном объекте, для которого и были созданы.
ППП – отчуждаемое, тиражируемое ПО. Предназначено для групп объектов с общими свойствами в отношении решаемой задачи. Тираж пакета зависит от его разновидности.
Обстановка на европейском рынке
| № п/п | ПО в Европе | » 85 год | начало 90–х |
| 1 | ППП и ОС | 34 | 51 |
| 2 | Заказное ПО и консультации | 29 | 28 |
| 3 | Обучение | 5 | 5 |
| 4 | Вычислительные услуги | 32 | 16 |
На системное По приходится » 30% общего объема продаж, а на прикладное » 70%.
ППП – комплекс программных средств и документов, предназначенных для реализации функционально завершенного алгоритма обработки данных. Он обеспечивает автоматизацию создания рабочих программ, автоматизацию процесса решения задач.
Характерные черты (3 свойства) :
1. Содержит набор готовых алгоритмических решений доводимых до конкретной машинной реализации;
2. Содержит механизм настройки на параметры конкретного объекта применения;
3. Пакет ПП должен предусматривать возможность дополнения его программами, привязывающими к специфике конкретного объекта, а также к изменившимся во времени условиям эксплуатации.
Классификация ППП (по области применения)
Проблемно–ориентированное ППП предназначено для обработки данных в рамках решения определенной задачи, ориентированной на обеспечение потребностей конечного пользователя.
Методо–ориентированное ППП реализуют тот или иной метод (математический) обработки информации.
Функциональные ППП обеспечивают максимальную автоматизацию программирования при решении конкретной задачи, от входного документа, включая метод решения задачи и до выдачи выходного документа.
Методо–ориентированный пакет реализует лишь часть решения, связанную с данным методом.
ППП общего назначения повышают уровень автоматизации работ при создании ПО.
Процедурные ППП – автоматизируют создание ПО по реализации типовых процедур обработки информации (ввод, хранение, вывод, корректирование, обновление, упорядочивание, поиск, фильтрация файлов и т.д.)
Инструментальные средства программирования – генераторы программ, документаторы программ, дополнительные средства для отладки и проверки программ. Например, генераторы вывода табличных форм, генератор ввода–вывода (ГВВ), генератор экранных форм, генератор документации (FOXDOC) : создание программного документа – текст и описание программы.
Сервисные – ориентированны на поддержку технологических процессов обработки программ, дополнение ОС.
Достоинства ППП.
1) Сокращение затрат на разработку; (до нескольких десятков процентов, в среднем 20–30%)
2) По сравнению с элементарными средствами, более высокая комплексная увязка решений;
3) Более высокое качество документирования ПИ;
4) Более высокая функциональная надежность;
5) Наличие развитой системы сопровождения (набор сервисных услуг, которые поддерживают эксплуатацию у пользователя);
6) ППП – средство передачи и обмена опытом между разработчиками и между конечными пользователями;
Недостатки ППП.
1) Сложность освоения ППП;
2) Большое разнообразие ППП по распространенным задачам затрудняет выбор. На сегодня отсутствуют объективные методы оценки ППП;
3) Низкая степень системной увязки существующих ППП (в случае увязки нескольких конкретных программ по входам–выходам);
4) Проблема наращивания и модификации;
5) Малая функциональная полнота.
Тема 2: Жизненный цикл ПИ (ЖЦПИ).
ЖЦПИ по стадиям совпадает с ЖЦ любого изделия производственно–технического назначения и традиционно принято изображать :
| эксплуатация |
| |
| сопровождение |
Продолжительность (общая) – 3–5 лет.
Разработка – стадия от момента исследования потребностей в ПИ до момента получения головного (эталонного) образца. Продолжительность: в среднем от 0,3 до 0,5 года.
Производство – получение экземпляра изделия, предназначенного для применения на конкретном объекте (экземпляр поставки). Сводится к тиражированию (копированию) эталонного экземпляра и адаптации под конкретного пользователя. Если единичный продукт то стадии разработки и производства объединяются.
Эксплуатация – процесс применения экземпляра пользователем для решения его конкретных задач.
Сопровождение ПИ – действия, связанные с обеспечением работоспособности изделия в процессе эксплуатации.
Особенности ЖЦПИ (по сравнению с другими изделиями).
1. В ЖЦПИ значительно велик удельный вес стадии разработки;
2. Процесс производства прост: краток и в значительной степени сводится к копированию;
3. Сопровождение играет все большую роль.
Разработка ПИ.
Составляющие процесса разработки ПИ:
1) подход – от задачи; (1)
2) подход стандартный ЕСПД. (2)
Какой бы подход не применялся набор действий, выполняемых создателем ПИ практически одинаков. Вариации связанны лишь с выделением отдельных действий в этапы.
(1)
1) Системный анализ (анализ требований) предметной области. Сначала анализ потребностей пользователя, затем разработка целей, формулировка задачи. Задачи ставятся перед отдельными производителями. Выбор методов реализации задачи. Формирование задания разработки. (Имеется ввиду спецификация ПИ).
2) Наз. (???) проектирование ПИ (внешнее).
Результатом внешнего проектирования является подготовка внешней спецификации.
3) Внутреннее (детальное, структурное) проектирование. (выработка программных решений раскрывающих внутреннюю часть ПИ). Определение структуры программного комплекса, состава и структуры БД, из каких файлов и какова их структура, связь с модулями, составление алгоритма.
4) Подготовка (кодирование) программных текстов, параллельно с этим подготовка программной документации.
5) Автономная отладка (отладка в статике), отладка модулей, их связей ...
6) Комплексирование компонент и комплексная отладка;
7) Испытание. Проверка работоспособности изделия в реальных условиях эксплуатации.
(2)
Делится на 5 стадий :
1) Стадия технического задания (предпроектная стадия). Почти полностью совпадает с этапом системного анализа. Этапы :
* сбор сведений (обследование);
* обработка сведений обследования и подготовка ТЭО;
* техническое задание (завершающий этап).
Формирует заказчик, потребитель разработчику.
2) Эскизное проектирование (принципиальная разработка ПИ, разработка общих принципов). Эскизный проект нужен для согласования между разработчиком и заказчиком основных технологических элементов.
3) Техническое проектирование (технический проект). Объединение всех материалов внешнего и внутреннего проектирования, которые будут доводиться до машинной реализации.
4) Рабочее проектирование:
n подготовка программных текстов (адаптация программных компонент);
n отладка во всех разновидностях;
n подготовка программной документации.
5) Внедрение. (Испытания в реальных условиях).
В процессе ведется подготовка объекта к эксплуатации. ПИ – приведение информационной базы, связанной с ПИ, к тому виду, который требуется эксплуатацией.
Обучение персонала.
Ключевым понятием процесса разработки ПИ является работа. Как правило, при планировании процесса разработки не доходят до уровня программных операторов, операций. … Работа – совокупность действий, выполняемых одним или несколькими исполнителями с целью получения конкретного контролируемого результата.
Тема 3: Учет и анализ затрат в ЖЦПО.
При группировке затрат на разработку программного продукта следует исходить из общего положения в определении статей расходов для традиционной продукции.
Статьи расходов:
1. Затраты по заработной плате (основной, дополнительной и все отчисления);
2. Затраты на технологию (на инструментальные средства, используемые при создании ПИ), в основном затраты на приобретение и освоение ППП, используемых как инструментальные средства. Затраты на ПИ, которые используются как эталон.
3. Расходы на содержание и эксплуатацию технических средств разработки, эксплуатации и сопровождения (затраты на машинное время).
4. Затраты на материалы (информационные носители).
5. Затраты на энергию, на использование каналов связи (для отдельных видов).
6. Общепроизводственные расходы (затраты на управленческий персонал, на содержание помещений).
7. Непроизводственные расходы (затраты связанные с рекламой, поиском заказчиков, поставками конкретных экземпляров).
Классификация затрат
1) Выделяют расходы основные (непосредственно связанные с процессом разработки и эксплуатации ПО) и накладные расходы, которые носят обеспечивающий характер.
2) По способу отнесения на конкретный продукт:
n прямые (могут быть учтены при создании конкретного экземпляра продукта);
n косвенные (связанные с созданием нескольких продуктов).
Основные отличия в расчете затрат на программную продукцию от традиционных продуктов :
1. Большая динамичность и большая неопределенность результата в заданные сроки, особенно на ранних стадиях разработки.
2. Отсутствует сложившаяся технологическая база для создания программной продукции, что приводит к разнообразию приемов и методов разработки при создании схожей продукции различными разработчиками.
3. Разнообразие предметной области.
Методы нормирования затрат на программную продукцию отличаются от затрат, сложившихся в традиционных отраслях. Метод – анализ статистических данных о фактически завершенных разработках, выявление факторов, определяющих разнообразие затрат, классификация этих факторов и предоставление пользователю нормативных материалов, возможности выбора наиболее близкого ему аналога и корректировки затрат, которые произошли при разработке аналога с помощью набора коэффициентов, учитывающих факторы разнообразия.
Особенно это существенно для затрат живого труда.
| Стадии ЖЦПИ | Стоимостные затраты, % | Временные затраты |
| Разработка требований | 10 | 6 |
| Проектирование | 10 | 5 |
| Программирование | 10 | 7 |
| Отладка | 20 | 15 |
| Эксплуатация и сопровождение | 50 | 67 |
С = Ср+Сэ+Сс ; Ср – разработка, Сэ – эксплуатация, Сс – сопровождение.
Ср = С1р+С2р+С3р+С4р+С5р+С6р, где
С1р – затраты труда на создание программного продукта;
С2р – затраты на изготовление эталонного экземпляра;
С3р – затраты на технологию (затраты на приобретение ПС, использованных при разработке ПИ, инструментарий ПС);
С4р – затраты на ВТ, использованную при разработке;
С5р – затраты на обеспечение должной квалификации персонала разработки;
С6р – различного рода затраты накладные, косвенные, необходимые для разработки.
Основную роль играют затраты на труд, на технологию и на технику (согласно статистическим данным).
Необходимо предложить методику для расчета С1р, С3р и С4р, так как величина С2р и С5р в %–ом выражении сравнительно устойчива и после определения суммы С1р+С3р+С4р может быть получена с использованием коэффициента. С2р » 0,05, С5р » 0,07. С1р зависит от объема разработки.
Перечень коэффициентов Сi может быть очень разнообразен применительно к конкретным разработкам. Для каждой разработки автору расчетов С1р необходимо определить свой перечень коэффициентов, если нужно использовать различные источники.
Перечень первоочередных Сi :
1. Сложность комплекса программ (С1) проводится классификация программ по группам сложности (3–4 группы) и определяются признаки, позволяющие отнести разоаботку к конкретной группе сложности. С1 – 1¸4 (увеличение затрат труда в несколько раз, по сравнению с простейшей).
2. Надежность функционирования (защита от ошибок, возможность дополнительного контроля, обеспечение сохранности и восстановления информации, обеспечение ограничения доступа). С2 ¸ 1–5.
3. Ограничения реализующей ЭВМ (дополнительные требования производительности, насколько нас сдерживает та ЭВМ, которая будет связана с эксплуатацией). С3 – 1¸1,2–3.
Если в результате разработки задействовано было до 50% мощности реализующей ЭВМ, то влияние этого фактора не учитывается. Если же мы превосходим эту величину, то появляется необходимость учета этого фактора. Если наша величина составляет более 70%, то возрастает на несколько десятков процентов.
4. Необходимость использования компонент создаваемого ПО для других разработок, то есть ведется разработка типового ПО. С4 – 1¸1,1–1,4 (10–20%)
5. Использование типовых проектных решений (ТПР) и ППП при разработке ПИ. С5 – 1¸0,7–0,3 (0,3 – предельное решение)
6. Использование передовых методов организации разработки. С6 – 1¸0,8–0,5. (Сттруктурное программирование, использование формализованных методов при распределении ресурсов, нисходящее проектирование).
7. Уровень автоматизации разработки (использование достаточно современных инструментальных средств, например систем программирования, проблемно–ориентированных систем программирования, генераторы программ, использование удачного текстового редактора для подготовки текстов и документации, средства автоматизации для отладки программ). С7 – 1¸0,5–0,25.
8. Относительное быстродействие машин. С8 – 1¸0,7–0,5, возможность использования ресурсов ЭВМ.
9. Относительное число доступов к машине (число дисплеев). С9 – 1¸0,7–0,5.
10. Тематическая квалификация разработчика. С10 – 1¸0,8–0,4
11. Технологическая квалификация разработчика (опыт использования технических и технологических средств, которые применяются в данной разработке, например: язык программирования, ППП, ОС). С11 – 1¸0,8–0,6.
12. Квалификация заказчика (опыт заказчика в формулировании технического задания на аналогичные программноы продукты и опыт в эксплуатации). С12 – 1¸1,5 вплоть до 5.
1 – Предпроектная стадия;
2 – Проектирование;
3 – Технологическая подготовка;
4 – Программирование;
5 – Автономная отладка;
6 – Комлексная отладка;
7 – Выпуск документации, подготовка носителей;
8 – Испытания.
В определении конкретной величины С1р используют подход “от аналога”. Ищутся близкие к нашим, но уже завершенные разработки.
Книги:
УНВ (укрупненные нормы времени) – позволяют подобрать аналог исходя из особенностей технологического процесса обработки информации на объекте.
ТНВ (типовые нормы времени) – позволяют подобрать аналог исходя из функциональных особенностей решаемой задачи.
УНВ – базируются на подборе аналога, исходя из технологии обработки информации. По каждой типовой процедуре (ввод, генерация отчетов, поиск в БД). Для прогнозируемого объема разработки предлагаются базовые трудоемкости. В дальнейшем базовые трудоемкости корректируется исходя из технологических факторов, которые связаны с условиями реального объекта.
Учитываются следующие факторы, определяющие трудоемкость:
1. Объем разработки (количество операторов);
2. Сложность разработки;
3. Степень новизны;
4. Степень использования типовых проектных решений, стндартных модулей и т.д. при разработке;
Этапы определения трудоемкости:
1. Определяется тип процедуры;
По каталогу аналогов определяется сколько потребовала реализация этой типовой процедуры в тестовых условиях (количество строк исходного текста):
2. Определяется степень сложности разработки;
3–4 группы сложности, по каждой из групп сложности заданы характеристики, которые позволяют отнести разработку к той или иной группе :
1 группа : (высшая) интеллект и языковой интерфейс, работа в режиме реального времени (процесс обработки сопоставим по времени с требованиями), режим работы телекоммуникационный, машинная графика (разработка элементов), реализация комплекса разработок.
2 группа : оптимизационные расчеты, применение сложных математических методов, настройка на изменяющиеся внешние условия, предусмотрение переносимости создаваемого продукта.
3 группа : (не встречается ничего из вышеперечисленного).
3. По группе сложности из таблиц определяется трудоемкость:
| V | Группа сложности | ||
| тыс. усл. ед. | 1 | 2 | 3 |
| 1 | | | 229 |
| 2 | | | 244 |
| 10 | 3905 | 2425 | 445 |
| 20 | 4700 | 2858 | 812 |
| 100 | 15598 | 8700 | 5800 |
| 200 | 35000 | 20000 | 15000 |
| 500 | 110000 | 65000 | 54000 |
После получения базового значения необходимо откорректировать это значение с учетом всех возможных коэффициентов, учитывающих вляние факторов связанных с прогрессивными технологическими разработками (С6¸С9)
4. По степени новизны классификация по трем группам.
Кн – коэффициент новизны.
А – принципиально новые разработки.
Б – развитие параметрического ряда ПС (в известной предметной области использовалась либо новая техника, либо новые программные средства).
В – Использование знакомых средств разработки в известной предметной области.
| | А | Б | В |
| Кн | 1¸1,75 | 1¸0,8 | 0,7 |
5. Использование типовых элементов в разработке.
Кт – коэффициент типовости.
| Кт | Степень применения типовых практических решений |
| 0,6 | >60% |
| 0,7 | 40–60% |
| 0,8 | 20–40% |
| 0,9 | <20% |
| 1,0 | не использовались |
6. Коэффицент сложности.
Ксл = 1 +
| | Ксл |
| 1. Связь с другими программными изделями | 0,08 |
| 2. Интерактивный режим | 0,06 |
| 3. Ведение сложной структуры данных | 0,07 |
| 4. Наличие нескольких характеристик сложности : | |
| – двух | 0,12 |
| – трех | 0,18 |
| – более трех | 0,26 |
Разнесение трудоемкости по отдельным этапам разработки:
Используются коэффициенты Тэ=То Кэ
Таблица: ориентировочные коэффициенты удельного веса от этапов во всей разработке.
| Кэ | Степень новизны | Стадии | ||
| | 1 | 2 | 3 | |
| Ктз | 0,11 | 0,10 | 0,09 | техническое задание |
| Кэп | 0,09 | 0,08 | 0,07 | эскизное проектирование |
| Ктп | 0,11 | 0,09 | 0,07 | технического проектир. |
| Крп | 0,55 | 0,58 | 0,61 | рабочего проектирования |
| Квн | 0,14 | 0,15 | 0,16 | внедрения |
Срок разработки :
Методические материалы типа УНВ требуют в качестве исходных данных (использование) знание технологических особенностей обработки информации, что не всегда бывает известно на ранних этапах создания ПИ. При составлении технического задания известны лишь задачи, которые будут решаться с помощью создаваемого ПИ и перечень форм входной и выходной информации, которая связана с решаемой задачей. В таком случае применение УНВ затруднительно. Иной подход к определению методик определения затарат связан с перечнем решаемых задач (подход “от задачи”): ТНВ – типовые нормы времени.
Исходные данные для определения трудоемкости связанных с типовой классической классификацией задач, решаемых на экономико–организационных объектах. Сбором статистической информации получают сведения, позволяющие определить трудоемкость в зависимости от объема.
ТНВ состоит из таблиц, например :
| | Вых\Вх | Количество форм | ||||
| | | 1 | 2 | 3 | … | 42 |
| Кол–во | 1 | 17 | 22 | … | … | 72 |
| форм | 2 | … | ТП | подсистемы | БУ | … |
| | … | … | | | | … |
| | 20 | 91 | … | … | … | 385 |
После определенного базового значения Тр производится его корректировка с помощью коэффициентов, учитывающих влияние факторов, отличающих конкретную разработку от типовой (степень новизны, сложность алгоритма, язык программирования и т.д.)
Затраты на технологию и ПС автоматизации разработки: Сзр.
Технические средства разработки определяемые в процессе технологической подготовки разработки : Сзр=Сзр1+Сзр2+Сзр3.
Затраты на технологию связаны:
1. Затраты на приобретение технических средств (прейскурантная цена приобретаемого средства) – Сзр1;
2. Затраты на освоение и внедрение принятой технологии подготовки (затраты труда на освоение – ЗП, затраты на машинное время, связанное с оснвоением, затраты на обучение персонала) – Сзр2;
3. Затраты на эксплуатацию технологических средств (затраты на сопровождение технологического средства на тот период времени, на который приходится разработка) – Сзр3.
Чаще всего приобретенные инструментальные средства используются в нескольких разработках, тогда Сзр1 разнесена на все разработки, в которых используется данное инструментальное средство. На конкретную разработку списывается лишь часть затрат, которая определяется амортизационным периодом инструментального средства = продолжительности разработки. Если в этот амортизационный период проводится несколько разработок с применением этого инструментального средства, то затраты амортизационнго периода распределяются по всем разработкам, пропорционально затратам машинного времени.
Затраты на технические средства (С4р)
Как правило технические средства применяемые для разработки (ВТ) не связаны с одной конкретной разработкой и по отношению к ним могут применять все теже правила разнесения затрат пропорционально амортизационному периоду, тогда затраты на технические средства сводятся к затратам на машинного времени на разработку.
Определение затрат машинного времени на разработку связано с технологической ЭВМ, то есть с той машиной, которая используется для разработки. Помимо технол. ЭВМ в ЖЦПИ появляется реализующая ЭВМ, но кторой ведется эксплуатация и затраты на эту машину не связаны с разработкой. Моделирующая ЭВМ в случае, когда велики различия между технологической и реализующей ЭВМ. В основном машинное время затрачивается на:
1. Формирование программного текста;
2. Формирование программной документации;
3. Отладку и испытания;
4. Технологическую подготовку.
Может использоваться два подхода в определении затрат на машинное время.
1) Исходя из затрат труда (С1з–>С4р). При определении затрат машинного времени исходят из нормативной для данного объекта велечины обеспечения одного раработчика машинным временем 2¸6 часов в сутки на одного работника (в среднем 4 часа).
Нормативная величина, как правило сопровождается затратами времени при типовых нагрузках на разработчика (этап ???). Для остальных периодов используются законы распределения машинного времени.
2) Методически схож с определением величины С1р (т.е. исходить из величины типового аналога). Тогда накапливаются статистические данные по затратам машинного времени во множестве выполненных разработок, полученная статистика классифицируется по условиям, в которых велись конкретные разработки и тогда при определении величины С4р для одного частного случая разработчик выбирает аналог, ту типовую разработку, которая наиболее близка к его условиям, принимает в качстве базового среднюю величину затрат и потом корректирует эту величину с помощью всех доступных коэффициентов.
Типовые ситуации классифицируются по функционально решаемым задачам. По каждой задаче указывается количество форм входной и выходной информации.
| Вх\Вых | 1 | … | 42 |
| 1 | 6 | … | 51 |
| … | … | … | … |
| 20 | 95 | … | 755 |
(Пример для задач БУ)
Далее эта норма уточняется в связи с новизной, сложностью, применением языков программирования (0,69¸1,58).
С1р+С3р+С4р, С1з–>Ср1–>С2р С5р С6р, С2р–>Ср
Затраты на эксплуатацию
С = Ср + Сэ +Сс
Сэ = С1э + С2э +С3э, где
С1э – затраты на непосредственно эксплуатацию ПИ;
С2э – потери эффективности функционирования ПИ вследствие задержки и потерь информации, подлежащей обработке;
С3э – потери эффективности функционирования ПИ, возникшие из–за сбоя или ошибок в работе программы.
С2э, С3э – зависит от потребительских свойств информации, обрабатываемой ПИ. Если удается установить связь между эффектом, полученным от решения задачи в в тех случаях когда это решение происходит вовремя и недополучения эффекта (а может быть штрафом или явно выраженными потерями) при задержке решения на определенное время, то разность между этими двумя величинами может составить сумму С2э и С3э.
С1э
Lмtм + Lмtп+ЗП+(ЗП)/Кз, где
Lм – затраты машинного времени (стоимость единицы машинного времени);
tм – время затраченное на решение задачи;
tп – затраты машинного времени, необходимого для поддержания программм в работоспособном состоянии.
Плюс затраты на персонал связанный с эксплуатацией ПИ и прочими расходами, которые можно считать косвенными по отношению к ЗП.
Сс – затраты по сопровождению.
Сс = С1с+С2с+С3с
С1с – затраты на обнаружение и исправление программных ошибок в процессе сопровождения;
С2с – затраты на доработку и совершенствование программы (модификацию);
С3с – затарты на тиражирование и внедрение новых версий.
С1с=L1с*Пк*tc/n0, где
L1с – нормированная величина трудоемкости исправления ошибок;
Пк – объем производственного комплекса;
tс – время сопровождения;
n0 – количество ошибок.
L2с – коэффициент учитывающий повышение трудоемкости работ, связанных с внесением изменений в программу (изменяется от 1 до 3);
Ср – затраты на разработку;
Pi – доля программного в комлекса переработанного при подготовке новой версии.
С3с измеряется в % от С2с.
Затраты по ЖЦПИ нужны, когда:
1) Оценивается эффективность (качество) создаваемого ПИ;
2) Определяется цена.
Показатели эффективности и качества ПИ.
1) Оценка потребителя для выбора ПИ;
2) Оценка эффективности ПИ.
Выделяют два вида показателей :
1) обобщенный;
2) часный.
(1) – хорош с точки зрения оценки результатов ПИ (в эксплуатации).
(2) – проще в получении и конкретном назначении но поскольку они работают в совокупности, то возможно появление противоречивых оценок по множеству ??? показателей.
Обобщенные поазатели.
Должны иметь стоимостной характер.
Э = В – С
Э – эффект;
В – суммарная выгода, экономия от эксплуатации ПИ;
Величина эффекта для конкретного ПИ чаще всего бывает связана с эффектом эксплуатации информационной системы, частью которой и является данное ПИ. В этом случае методически определение эффекта должно быть согласовано, сопоставимо с определением эффекта от эксплуатации информационной системы на объекте.
Где индекс б – относится к базовому варианту, а п – к предлагаемому.
С – текущие затраты на эксплуатацию ПИ сопоставления вариантов.
К – единовременные затраты на сопоставление вариантов.
Различают виды эффекта:
n предварительный (определенный до начала разработки или на предпроектной стадии);
n потенциальный (рассчитанный по завершении разработки, связан с максимально возможным применением на всех возможных объектах, допускающих его использование);
n гарантированный (связан с одним конкретным потребителем);
n фактический (рассчитанный по результатам эксплуатации ПИ на конкретном объекте за определенный период).
При определении величины эффекта проводится сопоставление затрат по вариантам реализации ПО на конкретном объекте. Можно в определении эффекта учитывать не все статьи затрат, а только те, по которым сопоставляемые варианты существенно различаются.
Если по каким–то статьям затрат варианты сопоставимы (незначительно отличаются друг от друга), то нет необходимости определять значения затрат по этим статьям.
При выборе базового варианта следует:
1) При разработке ПИ для конкретного объекта в качестве базового принимается тот вариант обработки данных, который заменяется предлагаемым (обычно существующий, действующий);
2) При определении величины эффекта для тиражируемого ПИ, выпускаемого на рынке в качестве базового варианта принимается конкурентный ППП, обладающий наилучшими характеристиками, как эксплуатационными, так и затратными.
Основные затруднения в определении частных показателей связаны с тем, что они носят качественный характер и должны оценивать различные свойства сопоставляемых программных изделий. А эти свойства присущи не самому программному изделию, а связаны с объектом применения ПИ.
Таким образом качество ПИ относительное понятие, которое имеет смысл только лишб в связи с реальными условиями применения. Совокупность свойств программного продукта, котрые обуславливают возможность удовлетворить определенные потребности пользователя в соответствии с назначением – качство ПИ.
Возможна классификаци характеристик качества ПИ по различным направлениям:
1) Оценка надежности создаваемого изделия.
n Защита от ошибок в работе ПИ;
n обеспечение возможности ПИ сохранения информации в случае потери какой–либо части хранимых данных (например хранение копий);
n обеспечение защиты от несанкционированного доступа.
2) Модифицируемость ПИ (модернизированность).
n наличие ресурсов, которые позволяют разрабатывать новые версии при изменении условий эксплуатации;
n мобильность (портативность, переносимость) – возможность ПИ к адаптации при переносе его на новый объект;
n отношение изменения объема при переносе программного текста к общему объему программного текста.
Эффективность использования ресурсов.
1. Качество документирования сведения об ошибках :
n множество способов передачи информации потребителю (бумажная документация, файл текстовый, наличие справочного интерфейса, возможность контекстной подсказки);
n обучающие версии программ, их представление;
n наличие автоматизированной системы обучения;
n наличие инструкций в эксплуатационной документации.
2. Доступность (легкость освоения). Требования к квалификации пользователя.
3. Корректность (степень адекватности реализованных в ППП методов требованиям предметной области).
Набор функциональных показателей ППП (сопоставление фактически полученных значений эксплуатационных показателей с требованиями предметной области).
По набору показателей качества ППП возможно применение экспертных оценок (баллы) и получение суммарной оценки (баллы), связанной с валовым коэффициентом, который учитывает значимость каждой характеристики.
Пример:
| | производительность | многосторонность | обработка ошибок | сложность обучения | сложность использования | общая пользовательская оценка | мощность |
| dBase | Ä | Æ | Æ | Ä | Ä | 7.0 | 6.7 |
| Paradox | Å | Æ | Ä | Ä | Ä | 6.8 | 5.1 |
| FoxPro | Ä | Å | Æ | Æ | Æ | 6.8 | 7.1 |
| R:Base | Å | Æ | Æ | Ä | Ä | 5.8 | 3.6 |
| Clarion | Ä | Å | Æ | Æ | Æ | 5.7 | 6.0 |
Ä - 7¸10; Æ - 5¸6,9; Å - <5.
Характеристики ППП:
1) мощность пакета ( сравнительное определение двух характеристик: производительности и многосторонности);
2) общая потребительская оценка:
((3*ЛЕГКОСВ)+(6*удобств.исп.)+(2*обр.ошиб.)+оценка испыт.)/12
Тема 4: Ценообразование программной продукции.
Объектом расчета цен являются:
1) ПИ, изготовленные по индивидуальному заказу (договору);
2) ПИ, тиражируемое и поставляемое потребителю с помощью торгующих посредников;
3) Промышленные услуги, оказываемые при внедрении ПИ.
Основой формирования цены является:
1) Определение экономически обоснованных затрат на создание ПИ. Обоснование затрат на разработку ПИ возможно с привлечением нормативных материалов (УНВ, ТНВ) с обязательными уточнениями с помощью учета всех влияния всех дополнительных факторов, приближенность материалов к источнику и условиями конкретной разработки;
2) Потребительские свойства ПИ в их сопоставлении на рынке программной продукции.
Различают два вида цен: договорные и прейскурантные, связанные с поставкой тиражируемого программного продукта (преимущественно через посредника).
Договорные (оптовые) цены - определяются сторонами, исходя из договора (технического задания, условий договора), с учетом экономически обоснованных затрат и согласованного сторонами размера прибыли. Материалы, связанные с формированием договорной цены оформляются в виде калькуляции цены, которые представлены как отдельные составляющие затрат по разработке.
Предложение по П обосновывается, исходя из расчета уровня прибыли, которая складывается в отрасли, связанной с разработкой и применением программной продукции.
Заказчик исходит из уровня прибыли, который сложился в отрасли, где будет применяться ПИ (в своей области).
Эти два уровня могут не совпадать (конфликт между разработчиком и заказчиком).
При определении договорной цены на программную продукцию, поставляемую нескольким заказчикам (или в нескольких экземплярах) в цену экземпляра поставки включаются затраты на разработку разнесенные на общее количество экземпляров поставки.
В случае выполнения новых заказов на эту же продукцию из системы разработки должны исключиться затраты, связанный с созданием и изготовлением первой партии, то есть затраты компенсируются предыдущими партиями.
При формировании договорной цены сначала определяют предварительную договорную цену (ПДЦ), которая складывается из составляющих:
ПДЦ = С + П + Н
С - себестоимость, П - прибыль, Н - налоги.
После того как подготовлено предложение о ПДЦ возможна и корректировка:
ДЦ = ПДЦ + ПП
ПП - предложения по прибыли.
Аналогично определяются цены на услуги по сопровождению программной продукции, с той лишь разницей, что цена на услуги может быть связана не с самим фактором проведения работ, а с периодом в течение которого оказываются эти услуги.
количество интервалов выплаты - 12 или 4 (месяц или квартал).
Если затраты за период собираются не на конкретного потребителя услуг, а на всех потребителей, то включают в знаменатель количество потребителей.
Прейскурантные цены (ПЦ).
Не предполагается согласование размера цены между поставщиком и потребителем. Они фиксированы в прейскурантах, обычно не сопровождаются калькуляциями (то есть расчет идет по принципу “нравится или нет”).
ПЦ часто используются при работе фондов программ, которые поддерживаются организациями - посредниками. Разработчики и поставщики не одно и то же лицо.
СИ - себестоимость изготовления;
Н - налоги;
ПИ - прибыль изготовителя;
В себестоимость изготовления конкретного экземпляра поставки включают:
n затраты на приобретение эталонного экземпляра, эти затраты чаще определяют ЦД;
n затраты изготовления экземпляра поставки (затраты на тиражирование, некоторые затраты по инсталляции экземпляра в условиях конкретного объекта);
n затраты на производство.
ПИ - прибыль изготовителя зависит от конъюнктуры рынка.
Для того чтобы стимулировать разработчика на создание программной продукции, ориентированной на максимально большой тираж, в ПЦ можно включить коэффициент % авторского вознаграждения.
По отношению к ПЦ возможно применение всех тех соображений, связанных с компенсацией затрат.
Цены первой ступени обычно связаны с компенсацией затрат на приобретение эталонного образца;
Цены второй и последующих ступеней исключают эти затраты и предполагаемые затраты на производство.
Тема 6: Управление разработкой программной продукции.
1) Управление осуществляется для обеспечения требуемого качества изделия (в техническом задании);
2) Соблюдение сроков разработки (ТЗ);
3) Эффективное использование ресурсов разработки.
Управление осуществляется на основе последовательной реализации работ и этапов ЖЦПО:
1. В первую очередь надо весь процесс разработки разбить на отдельные этапы и работы. Для каждого этапа (работы) формируется задание, имеющее реальный, контролируемый результат.
2. Осуществляется учет выполнения этапов и работ.
3. На основании контроля принимаются управленческие действия по ликвидации отклонений фактических результатов от запланированных.
Особенности разработки программной продукции.
1. Крупномасштабность планирования. Планирование ведется на уровне этапов и работ.
2. номенклатура работ, выполняемых во время создания ПП, во многом зависит от требований конкретной реализации.
3. Плохая сбалансированность планов работ по ресурсам. отсутствие достоверных методов распределения ресурсов по работам приводит к перераспределению ресурсов.
Для того чтобы осуществить качественное управление разработкой осуществляется технологическая подготовка разработки.
1. Определить состав и последовательность выполнения работ.
2. Определить состав и квалификацию исполнителей по выполнению работ.
3. Определить оборудование, необходимое для выполнения работ.
4. Методы и инструментальные средства выполнения работ.
5. Методы и средства контроля результатов работ.
6. Норма расхода ресурсов по отдельным работам.
7. Состав библиотеки проекта, то есть какими внутренними документами оформляется ход разработки, фиксирующий промежуточные результаты.
Технологическая подготовка может проводиться как специальной службой, это обычно происходит в крупных организациях-разработчиках, либо технологическая подготовка проводится руководителем разработки проекта или ответственным исполнителем в рамках нескольких бригад.
В результате технологической подготовки получают технологическую схему разработки ПП, в которой представлен перечень работ, в той последовательности, в которой они должны быть проведены, и по каждой работе указанны все ресурсы и средства необходимые для ее выполнения.
В качестве технологической схемы в программостроении выступают клмандные планы и наборы заданий.
Отсутствие достоверных методических материалов облегчающих определение перечня работ, проводимых на поздних этапах создания ПП, тогда, когда его разработка только начинается, приводит к тому, что при переходе от этапа к этапу перечень работ приходится пересматривать. Отсюда и технологическая подготовка может быть рассредоточена во времени. Для технологической подготовки необходимо:
1. Техническое задание (ТЗ);
2. Нормативно-методическая документация (стандарты, методические материалы);
3. Архив технологических процессов по предыдущим резработкам;
4. Набор инструментальных средств (систем программирования, документации).
Результаты технологической подготовки используются для того чтобы сформулировать задание разработчикам.
n Производится диспетчерское обслуживание разработки (контроля хожа выполнения задания);
n В случае получения результатов об отклонении принимаются решения по корректировке процесса разработки;
n Позволяют наращивать архив разработки и используются в дальнейшем.
Организация коллектива разработчиков.
Преобладающим методом организации является организация бригад. Метод предметных связей используется реже, тогда когда ведется разработка не тиражируемого продукта силами организации, которая будети вести его эксплуатацию.
С точки зрения административной, бригада - структурная производственная единица, которая может быть образована в рамках существующего структурного подразделения для выполнения определенной работы, имеющей конкретный результат.
При определении результата работы бригады может быть сформулировано частичное техническое задание.
Существуют два варианта бригад:
1) предметная область ПИ определяется в терминах программирования, то есть задание представляется собой результат работы относящийся к программированию;
2) предметная область ПИ определяется в терминах того языка, который используется в предметной области (функционально и математическо ориентированные ППП);
В первом случае предметная область имеет вид хорошо знакомый и понятный программисту и работа предполагает техническое проектирование может выполнить программист. Бригада может быть сформирована из специалистов одного профиля (в основном программисты).
Во втором случае работы по техническому проектированию могут быть выполнены специалистом в предметной области. Принятое им проектное решение, вплоть до технического проекта в дальнейшем доводится до машинной реализации специалистом-программистом. параллельно эксплуатируется документация, по возможности, должна разрабатываться специалистом из предметной области. В процессе внедрения, проверка работоспособности ППП тоже проводится специалистом из предметной области.
При разработках второго вида распределение специалистов по бригадам может быть:
Формирование бригады.
…
Разрабатываются 2-3 программных изделия одной бригадой, параллельно, но с некоторым сдвигом по времени.
| I | | ТЗ | ТП | РП | ВН |
| II | | | ТЗ | ТП | РП |
| III | | | | ТЗ | ТП |
2. Формирование специализированных бригад (из специалистов одного профиля). Результат работы отдельной бригады не всегда представляет собой конечный результат разработки.
Сложнее вести управление разработкой, требуется строгая формализация работ каждой бригады. На поздних этапах разработки результаты могут отклоняться от ТЗ.
Если из-за сложности и масштабности разработки требуется большое число исполнителей и организация нескольких бригад, то рекомендуется:
1) Рассмотреть вопрос о специализации бригад по функциональному признаку;
2) Желательно внедрить ведущую, главную бригаду. Эта бригада выполняет наиболее существенное задание и как можно больше участвует в жизненном цикле. Бригаде даются другие бригады соисполнители (которые могут быть со своим ТЗ).
Профессиональный состав исполнителей.
Удобно увязать с этапами разработки (стадиями):
ТЗ - формируется 1 бригада (на предпроектной стадии). Руководитель разработки, высококвалифицированных постановщиков-аналитиков.
При переходе на следующие этапы, члены бригады, проводящие предпроектные исследования, чаще всего становятся руководителями коллектива разработчиков.
ТП (техническое проектирование) - ведущие постановщики с их подчиненными соисполнителями постановщиками. Ведущий постановщик выделяется по функциональному признаку. Каждому ведущему постановщику и его коллективу полезно придать консультанта-программиста.
РП (рабочее проектирование) - формируется коллективы программистов во главе с ведущим (программистом-консультантом) в случае необходимости постановщики становятся консультантами. … и специалисты по документированию.
ВН (внедрение) - ведущим становится постановщик, желательно включить в состав исполнителей представителей от заказчика.
Полезно выделить несколько лиц, стоящих вне бригад:
n руководитель : не включается в состав никаких бригад :
n “+” руководитель объективен ко всем бригадам и с точки зрения самих исполнителей;
n “-“ руководитель теряет технологическую квалификацию и становится администратором.
n системный программист - консультационная работа, но в то же время работой он не так загружен, чтобы входить в состав бригады. Специалист технического характера, со знанием инструментария.
n лицо, которое ведет работу с заказчиками, работа на рынке по подбору заказчиков.
Численный состав разработчиков:
Т - трудоемкость, t - срок разработки.
Если расчетная величина Т значительно отклоняется от технического задания, то можно вернуться к пересмотру численности или подобрать объем работ под срок и под численность.
T-tN, значит мы пересматриваем техническое задание.
Попутно решается вопрос о финансировании разработки. Сумма затрат в задании на разработку (S) выводится из численности (N), продолжительности работы (t) суммы фонда ЗП на одного разработчика (F). К - доля ЗП и затрат на труд в общих затратах на разработку:
Последняя дробь в скобках - выработка одного разработчика.
1) Для крупных фирм специализирующихся на разработке К»0,3¸0,4;
2) Малые организационные формы в виде малых предприятий (20-30 чел.) К»0,5¸0,7;
3) Во временных коллективах К>0,8 ближе к 1.
Помимо специализации исполнителей по основным работам, связанным с созданием программного продукта (постановщики и программисты) можно специализировать исполнителей по наиболее распространенным , типичным работам, связанным с созданием программного продукта. Такие исполнители как могут входить в состав бригад служб разработки, так могут быть организованны в собственные коллективы (специальная бригада).
а) специалисты разработки (службы разработки);
б) специалисты по обслуживанию (в том числе мат.-техн. обслуживание разработки, информационное обслуживание: получение сведений о других разработках и инструментах, методические материалы, патентная работа: обслуживание авторского права);
в) специалисты по испытанию изделий. Соответствие результатов разработки ТЗ. (Сами работы по испытаниям требуют других навыков);
Работы по испытанию могут переходить в работы по сертификации (исследование чужого программного продукта с целью предоставления сертификата). Для этого необходимо выработать стандарты и выпустить документ с требованиями стандарта.
г) Работы по подготовке и выпуску документации. Документация в большей степени поддается стандартизации, чем работы по программированию. Желательна разработка стандартов в рамках отрасли …
д) Специалисты по поддержке ПИ. Изучение требований потребителей, реклама, консультации, обучение, установка ПИ у пользователей.
е) Специалисты по сопровождению. Получает сведения об ошибках, пожеланиях, исправляет ошибка или ведет доработку ПИ.
ж) Специалисты технологического профиля.
В крупных специализированных организациях соотношение объемов работ разработки, испытаний, документирования (в чел.):
10 – 3 – 2
Во временных организациях:
10 – 5 – 3
Для координации работы связанной с деятельностью различных подразделений выпускающих ПП и сопутствующие материалы требуются работы по управлению такого рода организациями. Необходима координация планов :
1) Целевые программы, позволяет определить место и роль организации на рынке ПП; связывают с предметной областью, с ПП определенной классификационной группы. Ориентация на определенный класс инструментальных средств.
2) Стратегические планы. Определяют какой продукт в какое время должен быть выпущен в свет для того, чтобы выполнить (1).
3) Текущие планы (тактические). Как, кто, когда, с помощью каких средств реализует перспективные планы, этапы и комплексные работы.
4) Календарные планы, где комплексы работ могут разбиваться на работы частного характера и по ним предлагаются конкретные исполнители.
5) Индивидуальный план (задания) для конкретного исполнителя указывают те работы которые он должен выполнить к определенному моменту, необходимо уточнить форму получаемого документа (результата) и метод.
Специалисты связанные с управленческой деятельностью:
1. Определяют последовательность разработки продуктов;
2. Взаимосвязь плановых показателей в работе тематических и функциональных подразделений (осуществление координации работ этих подразделений);
3. Определение таких значений плановых показателей в работе тематических служб, которые стимулировали бы на работы, не входя в противодействие с интересами организации в целом;
4. Оценка потребности в ресурсах для выполнения работ и распределение имеющихся ресурсов по исполнителям;
5. Контроль за ходом выполнения работ (не только конечного результата) но и текущий контроль по промежуточным действиям и параметрам, предвосхитить возможные отклонения фактического результата от требуемого;
6. Выработка действий управления, связанных с ликвидацией отклонения фактического состояния от планового.
Эти работы могут выполнятся в двух разрезах:
1) тематический;
2) организационно-временной.
В (1) все планы связаны с конкретным ПИ. Указываются все исполнители, ресурсы необходимые для разработки этого конкретного изделия (горизонтальный разрез матрицы ((*) см. выше).
ТЕМА … ППП …
ИНФОРМАЦИЯ ПО ТЕМЕ (руководитель, сроки, ресурсы …)
| Этап (работа) | Срок выполнения | Исполнитель (служба) | Затраты ресурсов 1 | Затраты ресурсов 2 | Форма результата | |
| | начало | конец | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
Во (2) случае все сведения приводятся по отдельному исполнителю (вертикальный разрез).
ИСПОЛНИТЕЛЬ (бригада, человек)
ПЛАН ПЕРИОД
| Тема ПИ | Этап | Ответственный исполнитель | Затраты ресурса 1 | … | Форма результата |
| | | | | | |
| | | | | | |
Методы управления процессом разработки
1. Управление разработкой ПП на основе нелинейной модели планирования ресурсов разработки (с помощью изучения статистики различных разработок, которая показывает, что производительность труда разработчика на связана линейной зависимостью с временем разработки, а объем выполненных работ не прямо пропорционален объему выходного продукта).
| | |
Это соотношение характерно и для отдельных стадий этапов разработки и кривые потребления на отдельных с. и э. пересекаются, и накладываемые части кривой, связанной с конкретным этапом могут переходить на следующие этапы.
t - время, затраченное с начала разработки;
ta - момент появления изделия в состоянии операционной готовности (может функционировать как единое целое)
К - объем ресурсов, выделяемых на разработку.
Если значение а брать достаточно большим и наклон кривой на участке 0-ta становится большим (крутым), то руководство разработкой усложняется. Руководитель не всегда может достаточно эффективно загрузить исполнителей работой. Это вызвано тем, что не все работы можно выполнять параллельно. Помимо функционально сложности разработки можно ввести понятие организационной сложности (оно вытекает из вопросов руководства).
(**)
Анализ эмпирической зависимости позволяет вывести соотношение связывающее производительность труда разработчика со сложностью.
Р - производительность труда:
(***)
С - зависит от применяемого инструментария (коэффициент пропорциональности). Например: С = 10 000 - язык высокого уровня исходящего из структурного программирования: С = 1, Д = 1, Р = 1; Д = 2, Р = 1,6)
S - объем программного изделия:
Своего рода производственная функция. Если ориентироваться на S=const, то найти выражение определенное количество ресурсов, необходимое для замещений, для обеспечения продолжительности разработки на единицу времени (как правило уменьшение).
(*)
По мере увеличения размера создаваемого ПИ приходится увеличивать время разработки, независимо от того, какими ресурсами мы располагаем (слабая зависимость - 4 степень).
Соотношение (*) используется как основа для управления разработкой. Из соотношений (**) и (***) по значениям задаваемых параметров разрабатывается определенное значение выбираемых параметров разработки.
S,t0 - задаваемые значения (S - не явная характеристика, задана через функциональную нагрузку).
С - выбираемое значение разработчиком исходя из наиболее предпочтительного варианта технологии.
Результатные параметры (трудоемкость разработки) и исходя из срока разработки определяется количество исполнителей:
N=F/ta
В процессе разработки могут меняться некоторые характеристики:
n меняются функциональные требования к ПИ;
n вводятся новые дополнительные функции, либо заменяются.
В любом случае часть функций разрабатывается за время меньше, чем ta, при этом может не меняться S.
Для реализации таких функций понадобятся дополнительные ресурсы из-за возрастания организационной сложности.
S = (d+4m+b)/6
d - минимально возможный объем разработки по мнению экспертов;
b - максимально возможный объем разработки по мнению экспертов;
m - среднее значение.
Тема 7: Стадии разработки ПИ. Содержание и методы выполнения работ.
1. Стадия ТЗ (предпроектная стадия). В настоящее время преобладающий объект разработки ПИ является программная реализация комплекса информационно и функционально взаимосвязанных задач.
n разработка ПО по подсистемам;
n разработка ПО для объекта в целом (реже встречается).
Основные альтернативы:
1) Существует ли возможная реализация ПИ современными средствами. Если “да”, то была ли эта реализация эффективна. Рассматривается совокупность частных показателей.
2) Следует ли проводить оригинальную разработку или возможна адаптация существующего ПО.
3) Если проводится оригинальная разработка, то ориентировать ли ее на изготовление локального ПИ, или же вести разработку тиражируемого ПП (например в виде ППП).
Так как ответ на (1) вопрос может быть отрицательным, то материалы связанные с решением основных альтернатив могут оформляться отдельным документом, например ТЭО. Если есть возможность, то рекомендуется для оригинальных разработок работы предпроектной стадии оформлять отдельным договором.
При планировании работ предпроектной стадии ориентировочно длительности его от 1 месяца, реже нескольких недель, и до 1 квартала.
Трудоемкость работ предпроектной стадии: от 15 чел./дней до 150 чел./дней. Чаще всего 30-50. Это означает, что на один комплекс задач выделяется 1-2 человека.
Примерно сложившаяся величина 10%, и если имеется дело с оригинальной разработкой, то эта доля уменьшается до 7-8%, или если с ППП то возрастает до 13-15%.
2) Работы по обследованию предметной области и технологических средств.
Начиная с определения организационной структуры обследуемого объекта. Каждому из символов необходимо сопоставить функциональные обязанности и подчинения. Это делается для:
n знания кому делается;
n возможности проникнуть в отдел.
Выявляются функции управления, подлежащие автоматизации, или те по которым пересматриваются ранее действующие решения. Решаются задачи методами иерархической декомпозиции: разбиения некоторой сложной проблемы функции управления на ряд ее частных составляющих (подпроблем), до тех пор, пока по каждой составляющей полученной на очередном шаге не будет детально определены информационные входы и выходы.
Обследование ведется не по функциональному признаку, а по информационному.
Обследование существующих методов реализации функций управления объектами, оно не должно носить описательный характер (дать анализ и разработать предложения по совершенствованию этих функций).
HIPO - после того как определились Сн взаимосвязью отдельных задач, проводится обследование информационной схемы решаемых задач. Сначала выходная информация (пожелания заказчика), входная информация (оперативная, нормативно-справочная) Р процесс-метод реализации перехода от входа к выходу.
При выявлении информационной схемы реализации функции необходимо рассмотреть все 3 аспекта, в которых определяется количество информации:
n синтаксическом (символьным);
n семантическим (как отдельные данные увязываются в документы, смысловая нагрузка информационных единиц);
n прагматический (полезность для потребителя).
3) Формулируется ТЗ.
