- •С.Л. Моругин Проектирование информационных систем
- •Часть 2
- •Содержание
- •5. Модели процессов
- •5.1. Состав функциональной модели
- •5.2. Иерархия диаграмм
- •5.3. Типы связей между функциями
- •5.4. Моделирование процессов по стандарту idef0
- •5.5. Модели as-is и то-ве
- •5.6. Моделирование в стандарте idef0
- •5.7. Нумерация работ и диаграмм
- •5.8. Диаграммы дерева узлов и feo
- •5.9. Каркас диаграммы
- •5.10. Рекомендации по рисованию диаграмм
- •6. Модели данных
- •6.1. Концепция баз данных
- •6.1.1. Независимость данных от обработки
- •6.1.2. Системы управления базами данных
- •6.1.3. Понятие о модели данных
- •6.1.4. Концепция трех схем
- •6.1.5. Семантические модели данных
- •6.1.6.Ограниченность реляционной модели при проектировании баз данных
- •6.1.7. Общие принципы классификации субд
- •6.1.8. Основные задачи и этапы проектирования баз данных
- •6.1.8.1. Основные задачи:
- •6.1.8.2.Основные этапы проектирования баз данных
- •6.2. Концептуальные модели предметной области
- •6.2.2. Основные понятия er-модели
- •6.2.2.1. Понятие сущности. Типы сущностей
- •6.2.2.2. Стержневая сущность
- •6.2.2.3. Ассоциация
- •6.2.2.4. Характеристика
- •6.2.2.5. Обозначение
- •6.2.2.6. Атрибут сущности
- •6.2.2.7. Ключ
- •6.2.2.8. Связь
- •6.2.3. Нотация Чена для изображения er-диаграмм
- •6.3. Логические модели данных
- •6.3.1. Получение реляционной схемы из er-модели
- •6.3.2. Построение логических реляционных моделей данных в стандарте idef1x
- •6.3.3. Создание логической реляционной модели данных в erWin
- •6.3.3.1. Ключи
- •6.3.3.2. Домены
- •6.3.3.3. Задание атрибутов модели
- •6.3.3.4. Задание связей
- •6.3.3.5. Связь многие-ко-многим
- •6.3.3.6. Типы сущностей и иерархия наследования
- •6.3.3.7. Пример создания модели
- •6.3.3.8. Денормализация в eRwin
- •6.3.3.4. Создание физической модели данных
- •6.4. Согласование моделей данных и моделей процессов
- •3. Создание сущностей и атрибутов bPwin и их экспорт в eRwin
- •7 Метрики программного обеспечения
- •7.1. Метрика
- •7.2. Размерно-ориентированные метрики
- •7.3. Функционально-ориентированные метрики
- •7.4. Метрики указателей свойств (Features Points).
- •7.5. Оценка сроков выполнения проекта и его трудоемкости
- •Обозначения и сокращения
- •Библиографический список
- •Проектирование информационных систем
- •607220, Г. Арзамас, Нижегородская обл., ул. К.Маркса, 36
- •607220, Г. Арзамас, Нижегородская обл., ул. К.Маркса, 36
7.5. Оценка сроков выполнения проекта и его трудоемкости
Зная скорректированную сумму функциональных пунктов, можно вычислить количество строк кода:
LOC = FP * KFP,
где KFP - коэффициент количества команд на функциональный пункт.
Пример нескольких номинальных коэффициентов для расчета количества строк кода: C# (55), JAVA (55), C++ (55), SQL (13), Perl (20).
Если программа из 320 функциональных пунктов реализовывается на C#, то количество строк кода вычисляется как 55 * 320 = 17600 LOC.
Количество строк кода зависит не только от языка программирования, т но и от технологии разработки программного обеспечения, стиля оформления и др.
Более точно оценить LOC можно по историческим данным для определенного типа проектов.
С помощью метода оценки первого порядка можно рассчитать приблизительное время реализации проекта T. Для этого необходимо общее количество функциональных пунктов FP возвести в степень типа программы S. Для объектно-ориентированной программы средний показатель S равен 0,36, для клиент-серверной программы – 0,37, для бизнес систем – 0,39, для научной системы и публичной Интернет-системы – 0,4:
T = FPS, мес.
Например, разработка бизнес системы, состоящей из 320 функциональных пунктов, грубо оценивается в 9,5 календарных месяцев.
Другим методом оценки является метод ISBSG. В этом методе существует несколько формул определенных для типа проекта. Результатом формул является число, определяющее оценку в человеко-месяцах. Для преобразования значений «человеко-месяцы» в срок календарных месяцев можно воспользоваться базовой формулой для вычисления срока, которая основана на вычислении кубического корня из объема работ.
Например, для общего типа проекта в методе ISBSG применяется следующая формула:
W = 0,512*FP0,392 *M0,791,
где W трудоемкость проекта в человеко-месяцах;
FP – скорректированное по формуле (7.1) число функциональных пунктов;
M – максимальный размер группы, человек.
В уточненных методиках в расчетах оценок участвуют дополнительно такие критерии (факторы) как:
фактор персонала;
опыт работы в прикладной области – если персонал незнаком с прикладной областью проекта, то потребуется значительно больше времени;
навыки владением языками и инструментарием – этот пункт противоположен предыдущему;
постоянство персонала – текучесть кадров обходится дорого;
размер базы данных, ограничения по объему хранимых данных – это значит, что большие базы данных требуют больших усилий на уровне проекта, соответственно и ограничения из-за платформы увеличивает объем работы проекта;
объем необходимой документации – большое количество документации может отрицательно повлиять на проект;
рассредоточенная (распределенная) разработка – если над проектом работает несколько команд или людей, находящиеся на разных географических площадках, то объем работ увеличивается;
неустойчивость платформы – если платформа нестабильна, разработка требует больше времени;
сложность продукта – этот фактор является основным в модели СОСОМО, он определяется типом создаваемой программы;
требуемая надежность программного обеспечения – чем больше установлено требований к надежности системы, тем больше времени нужно на ее реализацию;
ограничения по быстродействию – снижение времени отклика приводит к увеличению объема работ;
использование программных инструментариев – использование современного инструментария снижает объем работ.
Для повышения эффективности оценок используют калибровки (коррекция по результатам выполнения проектов). Обычно, самой лучшей калибровкой является использование исторических данных.