Графика
<<  Стадии проектирования и реализации ИС Базовая графика  >>
Алгоритм метода функциональных точек
Алгоритм метода функциональных точек
Границы продукта
Границы продукта
Функциональные точки, связанные с данными
Функциональные точки, связанные с данными
Матрица сложности данных
Матрица сложности данных
Пример оценки сложности транзакции
Пример оценки сложности транзакции
Оценка трудоемкости проекта
Оценка трудоемкости проекта
Оценка длительности проекта
Оценка длительности проекта
Картинки из презентации «Стадии проектирования и реализации ИС» к уроку черчения на тему «Графика»

Автор: Alex. Чтобы познакомиться с картинкой полного размера, нажмите на её эскиз. Чтобы можно было использовать все картинки для урока черчения, скачайте бесплатно презентацию «Стадии проектирования и реализации ИС.ppt» со всеми картинками в zip-архиве размером 607 КБ.

Стадии проектирования и реализации ИС

содержание презентации «Стадии проектирования и реализации ИС.ppt»
Сл Текст Сл Текст
1ТЕМА 5. Стадии проектирования и 27Function Point User Group — IFPUG). 27.
реализации ИС. Лекция 23. Этап рабочего 28Алгоритм метода функциональных точек.
проектирования. 28.
2Стадии ЖЦ. по ГОСТ 34.601-90 29Алгоритм метода функциональных точек.
Формирование требований к АС Разработка Определение типа оценки. Определение
концепции АС. Техническое задание. области оценки и границ продукта. Подсчет
Эскизный проект. Технический проект. функциональных точек, связанных с данными.
Рабочая документация. Ввод в действие. Подсчет функциональных точек, связанных с
Сопровождение АС. по ISO/IEC 15288:2002 транзакциями. Определение суммарного
Формирование концепции Разработка количества не выровненных функциональных
Реализация Эксплуатация Поддержка Снятие с точек (UFP). Определение значения фактора
эксплуатации. Анализ требований. выравнивания (FAV). Расчет количества
Проектирование. Реализация. Внедрение. выровненных функциональных точек (AFP).
Эксплуатация. 2. 30Тип оценки. Тип оценки. Область
3Стадии ЖЦ по ГОСТ 34.601-90. Стадия. оценки. Проект разработки. Проект развития
Этапы. 4. Эскизный проект. 4.1. Разработка (поддержки). Готовый продукт. Оценивается
предварительных проектных решений по количество функциональности, поставляемой
системе и её частям. 4.2. Разработка пользователям в первом релизе продукта.
документации на АС и её части. 5. Все разрабатываемые функции. Оценивается
Технический проект. 5.1. Разработка проект доработки: добавление, изменение и
проектных решений по системе и её частям. удаление функционала. Все добавляемые,
5.2. Разработка документации на АС и её изменяемые и удаляемые функции.
части. 5.3. Разработка и оформление Оценивается объем уже существующего и
документации на поставку изделий для установленного продукта. Только функции,
комплектования АС и (или) технических реально используемые. 30.
требований (технических заданий) на их 31Границы продукта. Что является
разработку. 5.4. Разработка заданий на «внешним» по отношению к продукту. Где
проектирование в смежных частях проекта располагается «граница системы», через
объекта автоматизации. 6. Рабочая которую проходят транзакции, передаваемые
документация. 6.1. Разработка рабочей или принимаемые приложением, с точки
документации на систему и её части. 6.2. зрения пользователя. Какие данные
Разработка и/или адаптация программ. 3. поддерживаются приложением, а какие —
4Проектирование ИС. Эскизное внешние. 31.
проектирование. Техническое 32Внутренние логические файлы (ILFs) —
проектирование. Техно-рабочее выделяемые пользователем логически
проектирование. Рабочее проектирование. связанные группы данных или блоки
Результаты анализа предметной области. управляющей информации, которые
Готовая к внедрению ИС. Эскизный проект поддерживаются внутри продукта. Внешние
(мнемосхемы, диаграммы процессов верхнего интерфейсные файлы (EIFs) — выделяемые
уровня). Технический проект (системный пользователем логически связанные группы
проект в виде комплекса моделей работы данных или блоки управляющей информации,
ИС). Рабочий проект (комплекс программ с на которые ссылается продукт, но которые
эксплуатационной документацией). 4. поддерживаются вне продукта. 32.
5Рабочее проектирование. Рабочее 33Функциональные точки, связанные с
проектирование – детальное проектирование, данными. Объект данных «Клиент». DET (data
включающее: разработку программ ИС, выбор element type) — неповторяемое уникальное
и адаптацию приобретаемых программных поле данных, например, Имя Клиента — 1
средств, разработку спецификаций каждого DET; Адрес Клиента (индекс, страна,
компонента, разработку интерфейсов между область, район, город, улица, дом, корпус,
компонентами, разработку требований к квартира) — 9 DET's RET (record element
тестам, разработку плана интеграции type) — логическая группа данных,
компонентов. 5. например, адрес, паспорт, ФИО. 33.
6Связь между этапами проектирования. 6. 34Матрица сложности данных. 1-19 DET.
7Документация этапа рабочего 20-50 DET. 50+ DET. 1 RET. Низкая. Низкая.
проектирования. Рабочий проект – комплекс Средняя. 2-5 RET. Низкая. Средняя.
документации, содержащий все необходимые и Высокая. 6+ RET. Средняя. Высокая.
достаточные сведения для обеспечения Высокая. Оценка в функциональных точках
выполнения работ по вводу ИС в действие и объекта данных «Клиент». 34.
её эксплуатации, а также для поддержания 35FP, связанные с транзакциями. Виды FP.
уровня эксплуатационных характеристик Назначение. Пример. EI (external inputs).
(качества) системы в соответствии с Внешние входные транзакции, элементарная
принятыми проектными решениями. Источником операция по обработке данных или
разработки рабочего проекта служит управляющей информации, поступающих в
технический проект. Рабочий проект систему из вне. Поле ввода, кнопка. EO
оформляется в соответствии с ГОСТ (external outputs). внешние выходные
34.201-90 «Виды, комплектность и транзакции, элементарная операция по
обозначение документов при создании генерации данных или управляющей
автоматизированных систем». В комплекс информации, которые выходят за пределы
рабочего проекта входит также программная системы. Предполагает определенную логику
документация в соответствии с ГОСТ обработки или вычислений информации из
19.701-90. 7. одного или более ILF. Поле данных отчета,
8Каталог базы данных Состав выходных сообщение об ошибке. EQ (external
данных (сообщений) Инструкция по inquiries). Внешние запросы, элементарная
формированию и ведению базы данных Чертеж операция, которая в ответ на внешний
формы документа (видеокадра) Ведомость запрос извлекает данные или управляющую
машинных носителей информации Массив информацию из внутренних логических файлов
входных данных Методика (технология) (ILF) или внешних интерфейсных файлов
автоматизированного проектирования (EIF). Поле ввода для поиска, поле вывода
Технологическая инструкция Руководство результата поиска. 35.
пользователя Описание технологического 36Оценка сложности транзакций. Матрица
процесса обработки данных Инструкция по сложности внешних выходных транзакций и
эксплуатации КТС Схема соединений внешних внешних запросов (EO & EQ). Матрица
проводок Схема подключения внешних сложности внешних входных транзакций (EI).
проводок Таблица соединений и подключений. Оценка в функциональных точках сложности
Схема деления системы (структурная) Чертеж транзакций. FTR (file type referenced) —
общего вида Чертеж установки технических позволяет подсчитать количество различных
средств Схема принципиальная Схема файлов типа ILF и/или EIF, модифицируемых
структурная комплекса технических средств или считываемых в транзакции. 1-4 DET.
План расположения оборудования и проводок 5-15 DET. 16+ DET. 1-5 DET. 6-19 DET. 20+
Спецификация оборудования Ведомость DET. 0-1 FTR. Низкая. Низкая. Средняя. 0-1
потребности в материалах Локальная смета FTR. Низкая. Низкая. Средняя. 2 FTR.
Общее описание системы Программа и Низкая. Средняя. Высокая. 2-3 FTR. Низкая.
методика испытаний (компонентов, Средняя. Высокая. 3+ FTR. Средняя.
комплексов средств автоматизации, Высокая. Высокая. 4+ FTR. Средняя.
подсистемы, систем) Проектная оценка Высокая. Высокая. Сложность. Количество FP
надежности системы Ведомость держателей (EI). Количество FP (EO). Количество FP
подлинников Ведомость эксплуатационных (EQ). Низкая. 3. 4. 3. Средняя. 4. 5. 4.
документов. 8. Высокая. 6. 7. 6. 36.
9Разработка спецификаций модулей ИС. 37Пример оценки сложности транзакции. 17
Разработка спецификаций, которые выражают DET, 1 FTR. Средняя сложность. 4 UFP. 1
функциональные возможности каждого модуля DET. 1 DET. 1 DET. 1 FTR. 37.
в физических категориях; определение 38Определение суммарного количества не
средств разработки для каждого модуля (или выровненных функциональных точек. Общий
выделенных групп модулей), если объем продукта в не выровненных
используются несколько средств разработки функциональных точках (UFP) определяется
в одном проекте; определение путем суммирования по всем информационным
последовательности реализации модулей и объектам (ILF, EIF) и элементарным
зависимостей модулей. 9. операциям (транзакциям EI, EO, EQ). 38.
10Предназначение спецификаций. 39Расчет количества выровненных
Разрабатывается для заказчика с целью функциональных точек. Учет общесистемных
получения санкции на завершение требований осуществляется путем применения
проектирования и начало реализации. фактора выравнивания (VAF – Value
Создается для разработчиков модулей и Adjustment Factor) . Значение фактора
групп тестирования, содержит описание выравнивания зависит от 14 параметров (DI
деталей проекта, а также ряд отчетов из - degree of influence), каждый из которых
репозитария CASE-средств. Основанием для оценивается по 5-балльной шкале. TDI = ?
разработки служит постановка задачи. 10. DI – суммарный эффект параметров VAF =
11Содержание технической спецификации. (TDI *0.01) + 0.65 AFP = UFP * VAF.
Описание назначения формы или функции 40Общесистемные параметры. Обмен данными
модуля; данные навигации; формат вызова 0 — продукт представляет собой автономное
формы (модуля); список входных параметров приложение; 5 — продукт обменивается
и параметров по умолчанию; список выходных данными по более, чем одному
параметров и правила их обработки; телекоммуникационному протоколу.
описание обработки (события внутри модуля Распределенная обработка данных. 0 —
и их обработка); список ошибок, которые продукт не перемещает данные; 5 —
генерируются в процессе обработки и распределенная обработка данных
реакция на них; ограничения доступа к выполняется несколькими компонентами
форме (модулю); вероятные блокировки системы. Производительность. 0 —
(потенциальные конфликты и обработка пользовательские требования по
ожидания); ожидаемое состояние базы данных производительности не установлены; 5 —
после выполнения модуля; способ проверки время отклика критично для всех
целостности данных. 11. бизнес-операций, для удовлетворения
12Отсутствие спецификаций. Ошибки. требованиям необходимы специальные
Последствия. Неконтролируемый рост объемов проектные решения и инструменты анализа.
данных. Резкое снижение производительности Ограничения по аппаратным ресурсам 0 — нет
системы. Возникновение потоков запросов с ограничений; 5 — продукт целиком должен
изначально высокой вероятностью конфликта. функционировать на определенном процессоре
Зацикливание. Смешивание системных и и не может быть распределен.
интерфейсных модулей, ошибки в размещении Транзакционная нагрузка. 0 — транзакций не
бизнес-логики. Создание «монолитной», много, без пиков; 5 — число транзакций
тяжело сопровождаемой системы. велико и неравномерно, требуются
Дублирование модулей. Неоправданный рост специальные решения и инструменты.
затрат. Отсутствие или неполная реализация 41Общесистемные параметры. Интенсивность
требуемых заказчиком функций системы. взаимодействия с пользователем. 0 — все
Увеличение сроков разработки и конфликты с транзакции обрабатываются в пакетном
заказчиком. 12. режиме; 5 — более 30% транзакций -
13Разработка метрик генерации кода. интерактивные. Эргономика 0 — нет
Метрика генерации кода – это таблица специальных требований; 5 — требования по
плановой трудоемкости по кодированию и эффективности очень жесткие. Интенсивность
отладке ПО. Оценку времени разработки изменения данных пользователями. 0 — не
производят: на основе аналитической требуются; 5 — изменения интенсивные,
документации (на этапе эскизного жесткие требования по восстановлению
проектирования или при разработке ТЗ); Сложность обработки 0 — обработка
после выполнения большей части минимальна; 5 — требования безопасности,
проектирования схемы данных и модулей (на логическая и математическая сложность
этапе технического проектирования). В Повторное использование 0 — не требуется;
метрике учитываются: трудоемкость 5 — продукт разрабатывается как
проектирования модуля, трудоемкость стандартный многоразовый компонент.
генерации кода модуля, трудоемкость 42Общесистемные параметры. Удобство
тестирования модуля. 13. инсталляции. 0 — нет требований; 5 —
14Факторы оценки трудоемкости. установка и обновление ПО производится
стабильность модели данных и степень ее автоматически Удобство администрирования 0
изменения в течение разработки; — не требуется; 5 — система автоматически
стабильность модели функций и степень ее самовосстанавливается Портируемость 0 —
изменения в течение разработки; уровень продукт имеет только 1 инсталляцию на
квалификации персонала; среда разработки единственном процессоре; 5 — система
(инструменты и методы, использование является распределенной и предполагает
автоматических генераторов кода); размер установку на различные ТО и ОС Гибкость 0
конечного продукта; качество ИС — не требуется; 5 — гибкая система
(производительность, надежность, запросов и построение произвольных
адаптируемость). 14. отчетов, модель данных изменяется
15Обмен данными. Интерфейсы обмена с пользователем в интерактивном режиме.
внешними системами можно разбить на 43Размер ПО в функциональных точках.
следующие категории: одноразовый импорт Текстовые процессоры – 3500
данных, унаследованных из старой системы; Клиент-серверные приложения – 7500 ПО баз
периодический обмен данными между данных – 7500 Бизнес-приложения – 10000
компонентами информационной системы Корпоративные приложения – 25000
(внутренний обмен); периодический обмен Приложения в госучреждениях – 50000
данных с другими информационными системами Операционные системы – 75000 Системы
(внешний обмен). Если обмен данными должен масштаба предприятия – 150000 Крупные
осуществляться в режиме, близком к оборонные системы – 250000. 43.
реальному времени, то это будет задача о 44Количество строк кода на одну
распределенной базе данных, а не о простой функциональную точку. Assembler. 172. 86.
передаче данных. 15. 320. JavaScript. 56. 44. 65. C++. 60. 29.
16Алгоритм загрузки/выгрузки данных. 178. Visual Basic. 50. 14. 276. Язык
Определение перечня подсистем, которым (средство) программирования. Язык
нужен интерфейс выгрузки/загрузки данных; (средство) программирования. Оценка
определение периодичности обмена данными и количества строк кода на 1 FP. Оценка
объема передаваемых данных; определение количества строк кода на 1 FP. Оценка
возможных методов транспортировки данных; количества строк кода на 1 FP. Наиболее
согласование форматов данных для обмена; вероятная. Оптимис-тическая.
определение порядка выполнения операций Пессимис-тическая. 44.
при загрузке/выгрузке; определение 451. 1 день. 1. 10. До 1 месяца. 1. 100.
мероприятий в случае сбоев во время До 6 месяцев (85%). 1. 1000. До 1 года.
загрузки и выгрузки данных; формулировка 10. 10000. От 1,5 до 5 лет. 100. 100000.
правил определения ошибочных записей (при От 3 до 8 лет. До 1000. Число FP.
загрузке); определение правил регистрации Длительность. Количество разработчиков.
операций передачи и приема данных; Пример приложений. Утилиты. Дополнения к
определение графика передачи данных; готовой системе. Небольшое приложение.
составление графика разработки и Клиент-серверные приложения. Крупные
тестирования собственных утилит обмена приложения. Операционные системы. 45.
данными; составление графика разовой 46Статистическая модель оценки
загрузки данных, наследуемых из старой трудоемкости. Модель COCOMO (COnstructive
системы, и подготовка методики проверки COst MOdel) – конструктивная модель
корректности этой операции. 16. стоимости (1985, Барри Боэм, данные о 63
17Тестирование. Объект тестирования. проектах). Модель COCOMO II (1997, Центр
Наименование теста. Цель проведения теста. по разработке ПО Южно-Калифорнийского
Отдельный модуль. Автономный тест. 1) университета, данные о 161 проекте). В
обнаружение отказов модуля; 2) модели используется формула регрессии с
соответствие модуля спецификации. Группа параметрами, определяемыми на основе
модулей. Группа модулей. Группа модулей. отраслевых данных и характеристик
Группа модулей. Тесты связей. Определение конкретного проекта.
взаимного влияния модулей. Тесты имитации 47Допущения модели COCOMO. Исходный код
отказов системы. Определение степени конечного продукта включает в себя все
восстановления системы после сбоев. Тесты строки кода, кроме комментариев. Начало
наработки на отказ. Определение степени цикла разработки совпадает с началом
устойчивости системы в условиях штатной стадии реализации продукта. Окончание
работы, оценка времени безотказной работы. цикла разработки совпадает с окончанием
Тесты пиковой нагрузки. Определение приемочного тестирования. Виды
степени устойчивости системы в условиях деятельности включают в себя только
перегрузки. Подсистема (система). работы, непосредственно направленные на
Системный тест. Внутренняя приемка выполнение проекта. Человеко-месяц состоит
продукта, показывающая уровень его из 152 часов. Проект управляется
качества. 17. надлежащим образом. Требования стабильны.
18Функции системы хранения ошибок. 47.
хранение сообщения об ошибке; уведомление 48Оценка трудоемкости проекта. PM –
о появлении новых ошибок, об изменении трудоемкость в чел./Мес. SIZE — размер
статуса известных в системе ошибок; продукта в тыс. Строк исходного кода emi —
формирование отчетов об актуальных ошибках множители трудоемкости sfj — факторы
по компонентам системы, по интервалам масштаба n=7 — для предварительной оценки
времени, по разработчикам; хранение n=17 — для детальной оценки.
информации об истории ошибки; организация 49Оценка длительности проекта. С = 3,67;
доступа разработчиков к ошибкам разных D = 0,28; TDEV – продолжительность проекта
категорий; организация доступа конечного PMNS — трудоемкость проекта без учета
пользователя ИС как интерфейс обмена множителя SCED, определяющего сжатие
информацией между пользователем и службой расписания.
технической поддержки. 18. 50Факторы масштаба в COCOMO. Фактор.
19Основные причины неудач проектов Низкий уровень. Балл. Высокий уровень.
разработки ИС. Плохое управление проектом Балл. 6,2. 0. 5,07. 0. 7,07. 0. 5,48. 0.
«Плывущие» требования Неправильная оценка 7,8. 0. Прецедентность. Опыт в продукте и
проекта, связанная с отсутствием опыта или платформе отсутствует. Продукт и платформа
методики оценки проекта; непредвиденными полностью знакомы. Гибкость процесса
проблемами в используемых средствах и разработки. Процесс строго детерминирован.
компонентах; непониманием ключевых Определены только общие цели. Архитектура
технических проблем проекта. 19. и разрешение рисков. Риски неизвестны/не
20Единица измерения проекта. Наиболее проанализированы. Риски определены на
популярные единицы измерения – время и 100%. Сработанность команды. Формальные
функции системы. зависит от сложности взаимодействия. Полное доверие,
проекта и позволяет изменять оценку взаимозаменяемость и взаимопомощь.
размера проекта с изменением требований; Зрелость процессов. CMM Уровень 1. CMM
применима на всех стадиях жизненного цикла Уровень 5.
системы, причем на различных этапах 51Множители трудоемкости. Множители EMi
жизненного цикла проекта его эффективность отражают совместное влияние многих
определяется заново, с различной глубиной параметров. Позволяют характеризовать и
проработки; дает независимые оценки нормировать среду разработки по
времени выполнения проекта и его параметрам, содержащимся в БД проектов
трудоемкости; позволяет распределить риски модели COCOMO II. Для конкретного проекта
между всеми участниками проекта. 20. каждый множитель оценивается с помощью
21Методы оценки трудоемкости разработки лингвистической переменной – очень низкий,
ПО ИС. Алгоритмическое моделирование низкий, номинальный, высокий, очень
Основан на анализе статистических данных о высокий.
ранее выполненных проектах, затраты 52Множители трудоемкости для
прогнозируются в зависимости от предварительной оценки. Квалификация
количественного показателя Экспертные персонала (PERS) Low — аналитики и
оценки Основан на опросе экспертов по программисты имеют низшую квалификацию,
технологии разработки ПО в заданной текучесть больше 45%; High — аналитики и
предметной области Оценка по аналогии программисты имеют высшую квалификацию,
Основан на сравнении проекта с текучесть меньше 4% Сложность и надежность
предыдущими, имеющими подобные продукта (RCPX) Low — продукт простой,
характеристики. 21. специальных требований по надежности нет,
22Методы оценки трудоемкости разработки БД маленькая, документация не требуется;
ПО. Закон Паркинсона Усилия, затраченные High — продукт очень сложный, требования
на работу, распределяются равномерно по по надежности жесткие, БД сверхбольшая,
выделенному на проект времени. Критерием документация требуется в полном объеме
для оценки затрат являются человеческие Сложность платформы разработки (PDIF) Low
ресурсы, а не целевая оценка самого — специальные ограничения по памяти и
программного продукта. Оценка с целью быстродействию отсутствуют, платформа
выиграть контракт Трудоемкость проекта стабильна; High — жесткие ограничения по
зависит от бюджета заказчика, а не от памяти и быстродействию, платформа
функциональных характеристик создаваемой нестабильна.
ИС. 22. 53Множители трудоемкости для
23Хорошая оценка трудоемкости. Создается предварительной оценки. Опыт персонала
и поддерживается коллективом (PREX) Low — новое приложение, инструменты
разработчиков; основывается на подробно и платформа; High — приложение,
описанной и обоснованной модели оценки; инструменты и платформа хорошо известны
основывается на данных по аналогичным Оборудование (FCIL) Low — инструменты
проектам; учитывает все области риска. 23. простейшие, коммуникации затруднены; High
24Факторы оценки трудоемкости. Размер — интегрированные средства поддержки
конечного продукта (количество строк кода жизненного цикла, интерактивные
или количество функциональных точек); мультимедиа коммуникации Сжатие расписания
Особенности технологии разработки ПО; (SCED) Low — 75% от номинальной
Квалификация персонала; Особенности среды длительности; High — 160% от номинальной
разработки (инструментальных средств); длительности Разработка для повторного
Требуемое качество продукта использования (RUSE) Low — не требуется;
(функциональные возможности, High — требуется многократное
производительность, надежность). 24. использование в других продуктах.
25Недостатки метода определения размера 54Множители трудоемкости. Идент.
продукта через количество строк кода. Не Описание множителя. Диапазон. RELY.
применяется на ранних стадиях разработки. Требуемая надежность. 0,82 – 1,26. DATA.
Строки исходного кода зависят от типа Размер базы данных. 0,9 – 1,28. CLPX.
языков программирования, методов Сложность продукта. 0,73 – 1,74. RUSE.
проектирования, стиля и квалификации Требуемый уровень повторного
программиста. Разработка ПО связана с использования. 0,95 – 1,24. DOCU.
большими затратами, напрямую не зависящими Соответствие документации требованиям ЖЦ.
от размера программного кода. Генераторы 0,81 – 1,23. TIME. Ограничение времени
кода продуцируют чрезмерный объем кода, в выполнения. 1,0 – 1,63. STOR. Ограничение
результате чего искажаются показатели по объему основной памяти. 1,0 – 1,46.
трудоемкости. 25. PVOL. Изменчивость платформы. 0,87 – 1,30.
261 мес. 1 мес. 2 мес. 2 мес. 9 мес. 2 55Множители трудоемкости. Идент.
мес. 4 мес. 2 мес. 3 мес. 2 мес. 19 мес. 9 Описание множителя. Диапазон. ACAP.
мес. 30000. 5000. 150000 у.Е. 90000 у.Е. 5 Способность аналитика. 1,42 – 0,71. PCAP.
у.Е. 18 у.Е. 1500 строк/мес. 500 Способность программиста. 1,34 – 0,76.
строк/мес. Показатель (по стадиям ЖЦ). APEX. Знание приложений. 1,22 – 0,81.
Команда №1 (низкоуровневый ЯП). Команда №2 PLEX. Знание платформы. 1,19 – 0,85. PCON.
(высокоуровневый ЯП). Изучение требований Преемственность персонала. 1,29 – 0,81.
к ПО. Внешнее и концептуальное LTEX. Знание языка/инструментальных
проектирование. Кодирование. Тестирование. средств. 1,20 – 0,84. TOOL. Использование
Подготовка комплекта документации. ИТОГО инструментальных средств. 1,17 – 0,78.
по времени. Число строк кода. Затраты. SCED. Требуемые сроки разработки. 1,43 –
Цена строки кода. Производительность 1,0. SITE. Распределенность команды
труда. 26. разработчиков. 1,22 – 0,8.
27Методы определения размера продукта. 56Пример определения TOOL. Элементы
Количество строк кода - точка зрения множителя. Уровни рейтинга. Значение.
разработчика. Количество функциональных Редакторы кода, отладчики. Очень низкий.
точек – точка зрения пользователей. 1,17. Простые CASE-средства с минимальной
Разработчик метода Алан Альбрехт интеграцией. Низкий. 1,09. Средства
(IBM),1979 Основная идея метода - поддержки основных процессов ЖЦ, средняя
максимальный отказ от деталей реализации степень интеграции. Номинальный. 1,0.
ПО и перенос оценки в область Развитые средства поддержки ЖЦ, средняя
функциональности, наблюдаемой степень интеграции. Высокий. 0,9. Мощные
пользователем. 1986 г. – сформирована средства поддержки ЖЦ, хорошо
Международная Ассоциация Пользователей интегрированные. Очень высокий. 0,78.
Функциональных Точек (International
Стадии проектирования и реализации ИС.ppt
http://900igr.net/kartinka/cherchenie/stadii-proektirovanija-i-realizatsii-is-263689.html
cсылка на страницу

Стадии проектирования и реализации ИС

другие презентации на тему «Стадии проектирования и реализации ИС»

«3d проектирование» - Tutorial – книги и учебники как на русском языке , так и на EN. Направления применения программы трехмерного моделирования. 3D проектирование. Текстурирование (создание и подготовка карт текстур материалов). Навыки использования программы трехмерного проектирования. Выполнение построений с использованием сплайнов (тела вращения, выдавливания).

«Стадии человека» - Презентация подготовлена студентом гр. Овладение огнем. Дриопитеки – общие предки понгид и гоминид. Стадия палеоантропа. 200-500 тыс. лет. Использование предметов в качестве орудий добывания пищи и защиты. Около 10% браков не приносят детей из-за мужского и женского бесплодия и других причин. Высокая культура изготовления орудий.

«Проектирование баз данных» - Проектирование. Таблица может быть: Хорошо нормализованной Плохо нормализованной. Задание структуры базы данных. Плохо нормализованная таблица. Нормализация. Работа с сохраненной базой данных. Нормализованная база данных. Проектирование баз данных. Этапы создания базы данных. Организация информации в табличную форму.

«Социальное проектирование» - «Капля мысли о природе, рождает могучую, полноводную реку мысли… Формулировка социальной проблемы, актуальной в данном местном сообществе. Технология социального проектирования. Выявление уровня сформированности гражданственности у старшеклассников в 2010-2011 учебном году. Метод проектов. Цель: определение условий успешности использования социального проектирования для учащихся.

«Проектирование пресс-форм» - Центрирующие фланцы фиксируют пресс-форму на литьевой машине. Крышка трубки. Проектирование системы охлаждения. Этапы проектирования пресс-формы. Элементы привода формообразующих. Коническая пробка. Фильтр типоразмеров. Сборочный чертеж на 7 листах. Формообразующая поверхность. Сборочный чертеж и спецификация.

«Дипломное проектирование» - Дипломное проектирование - важный этап подготовки специалистов. Предусматриваются следующие виды практик: производственная, научно-исследовательская, педагогическая. Защитил магистерскую диссертацию на тему «Управление знаниями с использованием информационных технологий». На все практики - 57 зачетных единицах (2052).

Графика

7 презентаций о графике
Урок

Черчение

7 тем
Картинки
900igr.net > Презентации по черчению > Графика > Стадии проектирования и реализации ИС