Выполнение оценки на основе лог и fp метрики

Цель :

1. Сформировать требование по срокам и стоимости разраюотки проекта и предъявить их заказчику

2. Составить план программного проекта

Варианты использование :

1. Для оценки размеров состовляющих разрабатующего програмного продукта

2. В качеств метрик собранных по результат прошлых проектов(метрические базис фирмы )

Методика оценки:

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

2. Для каждой функции f_i формируем 3 оценки.(лучшую, худшую, наиболее вероятное).

3. Ожидаемая оценка=(лучшая+ худшая +4 вероятных ) /6 .

4. Начинаем считать Loc или FP оценки

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

   2. Для каждой этой функция p_i-производимость=p-средние* LOC –средние/LOC-ожидаемое

5. Общая оценка затрат на проект

   1. для средней производимости(соответствует 4.1).

Затрат₁= ( _{ожидание})/П_ср

2. Затрат₁= ( _{ожидание})/П_i

1. Вычисление удельной стоимости(стоимость одной строки текста которую берем из метрической базис).

Ст₁= ( _{ожидание})/ Удельная стоимость.

//типа конс

ФИО
ID
Должность
Начислено
д

Лекция 5

Доступ к бд. Технология ado.Net

Основная технология доступа к БД на платформе Net. Набор объектов при помощи которых программист может осуществить подключении к серверу БД, выборку данных и хи модификацию. Ориентирован на разработку приложений корпоративного масштаба .

Основные компоненты: провайдер данных() и набор данных.

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

Connection –обеспечивает сведение с БД и транзакцию

- манипулировать с данними источниками хранить выполняемые процедуры в том числе с перадчкей параметром

DateAdapter -адаптирует данные, служит связующим с звеном между… Использует объект (Комент) для выполнение команды SQL

Data Reader –данные только для чтения.

Date Set- аналог, образ реалициной БД, который хранить в оперативной памяти клиента, можем загрузить данные из нескольких источников, потом соединение с ними разорвать и работать только с набором данных. Коллекция: коллекция таблиц(объединяет объекты таблицы, каждый из которых представляет собой одну таблицу, храниться как исходные так и изменение, набор ограничений целостности данных) и связей(связь между таблиц ).

Управление проектом. Типовая связь

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

Типичная схема управлении проекта:

1. Исследование предметной области.

2. Определяемся с средствами разработки и технологии.

//выбираем каскадную, водопадную, и т.д. модель

3. Разработка орг. структуры.

4. Распределение ответственности.

//кто камому отчитается

5. Расписание.

//примерно количество человек-дней, количество сотрудников

6. План подбора кадров.

7. Управление рисками.

8. Документы.

9. Начало процесса разработки

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

Матричных фирмах служащие относиться к функциональным подразделам, например: отдел разработки, отдел продажи, и выделяется для участие в том или ином проекте. Достоинства: гибкость возможность повышение классификации. Недостаток : размытая структура управление.

Риски

Риск представляется виде факторов которые могу проявиться по ходу проекта и негативно влиять на проект. Типы: которые можно пред отварить и избежать, которых избежать нельзя. Пример 1: уходит руководила проекта, предотвращение подготовка зама. Пример 2: необходимо собрать данные примерно за 5 лет о работе.

Управление рисками

Необходимо интенсифицировать риски. Основная проблема не идентифицируемые риски. Шаги управление рисками :

1. Инициация

2. Планирование и устранение

3. Выбор приоритетов

4. Устранении или уменьшение рисков

Индикация : часто методом мозгового штурма

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

Лекция 6

Представляет процесс их снижение или устранение. Способы: избежание риска и преодоление(вносим изменение в проект что устранить причины возникновения риска, вносим такие инженерные решение, …. Что бы решить проблему риска), список рисков которые подлежать к рассмотрению, их выстраиваем по приоритету. Для расчета приоритета учитывается следующие факторы: вероятность возникновение(1-10) , ущерб(1-10), стоимость устранения (1-10).

Разработка и поддержка модели и средства

Модели.

Case- средства. Отслеживание перехода требованье в проект и сам проект в программный код. Контроль тестирование. Поддержка сопровождения. Управление проекта: расписание, распределение работы, управление конфигурации, управление требованье. Пи непосредственном проектирование: функциональный, ОО, варианты использование(кто будет использовать эти функции, или для кого-то это будет нужен).

//UML-диаграмма использование

//Выбрать любую задачу, на эту задачу нарисовать задачу использование

Выбор языка программирование.

Детали реализации

1. Интеграции существующий приложений, унаследованных.

//есть прототип, из него хотят сделать готовый продукт

2. Проектирование, оценка стоимости.

3. Оценка трудозатрат и длительность проекта.

На основание количество строк кода. Трудозатраты растут экспоненциально в зависимости от количестве строк кода.

Разработка команды.

1. Выбираем процесс разработки.

2. Определяем уровень качества продукта .

3. Определяем метод отслеживание уровня качества.(это степень удовлетворённости потребителя, практикуются выход на рынок сырая программа а потом бесплатно рассылают обновление ).

4. Определить порядок принятия решений .

5. Определить действия, если не устраивает уровень качества.

6. Определить и распределить рои в команде.

План управление проекта. Разработанные международные стандарты и их использование SPM - Software Management Plan. Детализовано все то что выше сказанное.

Оценка качества : метрики:

1. Количество дефектов на 1000 строк кода, выявленных в течении определённого периода .

2. Отклонение в расписание.//Лучше в процентах

3. Отклонение в стоимости. //Лучше в процентах

4. Общее время проектирование.

Уличение процесса:

1. Классификация типов работы.

2. Классификация процессов.

Анализ требованье

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

Лекция 7

С-требований и D-требование

IEEE

Функции:

1. введение,(C)

2. общее описание (требование заказчика)

3. Конкретные требование(development)

4. Сопровождающая информация.(C+D)

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

Процесс анализа требование. Типовая схема

1. Идентифицировать заказчика.

2. Интервью представителями заказчика.

   1. Желание и требование заказчика.

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

   3. Конфигурация оборудование

   4. Средства поддержки.

3. C-требование в стандартной форме.

4. Проверка С-требованье.

5. D-требование.

Метрики для оценивание: время, количество, страниц С-требованье, время на получения одной С-требованье(общение с заказчиком), оценка качества результата(экспертная 1-10), оценка дефектов по оценки проверки требованье.

Примерная структура С-требованье:

Введение:

1. Цель.

2. Область применение.

3. Определение термин и сокращение.

4. Ссылки .

5. Обзор.

2.Общое описание.

2.1 Перспективы продукта

2.1.1 Системные интерфейсы.

2.1.2 Пользовательские интерфейсы

2.1.3Программные интерфейсы

2.1.4Коммуникационные интерфейсы

2.1.5Ограничение по памяти

2.1.6Операции

2.1.7 Требование по адаптации.

2.2 Функции продукта

2.3 Пользовательские характеристики.

2.4 Ограничение

2.5 Предположение и зависимости

2.6 Распределение требованье

Недостаток: надо особенности ООП.

Стоимость обнаружение ошибки у требованье 50-20 раз.

Результата анализа требованье- согласованное с заказчиком понимание, разрабатываемой программы.

Источники возникновение требованье – значительный процент требованье – в результате опроса представителя заказчика. Причем этот процент отличается для разных задач.

Заинтересованные личности.

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

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

2. Нужд заказчика от его желаний.

3. Порядок проведение опроса и его документирование

Подготовка к интервью :

1. Приоритеты

2. Планы интервью, с фиксированным времени

Желательно 2-3 человека из команды разработчики, желательно запись интервью.

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

После интервью: составить черновик С-требованье, оправить заказчику.