Правило распределения затрат проекта
Технология конструирования программного обеспечения (ТКПО) – это система инженерных принципов для создания экономичного ПО, которое надежно и эффективно работает в реальных компьютерах. Методы ТКПО обеспечивают решение следующих задач: • планирование и оценка проекта; • анализ системных и программных требований; • проектирование алгоритмов, структур данных и программных структур; • кодирование; • тестирование; • сопровождение. Средства (утилиты) ТКПО обеспечивают автоматизированную или автоматическую поддержку методов. В целях совместного применения утилиты могут объединяться в системы автоматизированного конструирования ПО. Такие системы принято называть CASE-системами. Аббревиатура CASE расшифровывается как Computer Aided Software Engineering (программная инженерия с компьютерной поддержкой). Процедуры ТКПО соединяют методы и утилиты так, что они обеспечивают непрерывную технологическую цепочку разработки. Процедуры определяют: • порядок применения методов и утилит; • формирование отчетов, форм по соответствующим требованиям; • контроль, который помогает обеспечивать качество и координировать изменения; • формирование «вех», по которым руководители оценивают процесс. Стратегии конструирования: • однократный проход (водопадная стратегия) – линейная последовательность этапов конструирования с определением всех требований в начале процесса; • инкрементная стратегия. В начале процесса определяются все пользовательские и системные требования, оставшаяся часть конструирования выполняется в виде последовательности версий. Первая версия реализует часть запланированных возможностей, следующая версия реализует дополнительные возможности и т. д., пока не будет получена полная система (запланированное улучшение продукта); • эволюционная стратегия. Система также строится в виде последовательности версий, но в начале процесса определены не все требования. Требования уточняются в результате разработки версий. Классический жизненный цикл ПО: Макетирование: Инкрементная модель: Быстрая разработка приложений (RAD - Rapid Application Development): Спиральная модель: где: 1 – начальный сбор требований и планирование проекта; 2 – та же работа, но на основе рекомендаций заказчика; 3 – анализ риска на основе начальный требований; 4 – анализ риска на основе реакции заказчика; 5 – переход к комплексной системе; 6 – начальный макет системы; 7 – следующий уровень макета; 8 – сконструированная система; 9 – оценивание заказчиком. Компонентно-ориентированная модель: ХР-процесс Экстремальное программирование: 2. Модели качества процессов конструирования. 3. Процесс руководства проектом. Время Работы, выполняемые в процессе руководства проектом: · Начало проекта · Измерения, меры и метрики · Процесс оценки · Анализ риска · Планирование · Трассировка и контроль 4. Планирование проектных задач.
|
|
|
|
|
|
WBS – Work Breakdown Structure (структуры распределения работ)
Системный анализ:
Системный анализ проводится с целью:
выяснения потребностей заказчика;
оценки выполнимости системы;
выполнения экономического и технического анализа;
распределения функций по элементам компьютерной системы (аппаратуре, программам, людям, базам данных и т. д.);
определения стоимости и ограничений планирования;
создания системной спецификации.
В системной спецификацииописываются функции, характеристики системы, ограничения разработки, входная и выходная информация.
Анализ требований:
Анализ требований дает возможность:
• определить функции и характеристики программного продукта;
• обозначить интерфейс продукта с другими системными элементами;
• определить проектные ограничения программного продукта;
• построить модели: процесса, данных, режимов функционирования продукта;
|
|
|
• создать такие формы представления информации и функций системы, которые можно использовать в ходе проектирования.
Результаты анализа сводятся в спецификацию требованийк программному продукту.
Правило распределения затрат проекта
Рекомендуемое правило распределения
затрат проекта – 40-20-40:
• на анализ и проектирование приходится 40% затрат (из них на планирование и системный анализ – 5%);
• на кодирование – 20%;
• на тестирование и отладку – 40%.
• 5.Понятие и предметы URL.
• UML – это язык для определения, визуализации, конструирования и документирования артефактов программных систем, а также для моделирования экономических процессов и других не программных систем.
• UML обладает следующими основными характеристиками:
• является языком визуального моделирования, который обеспечивает разработку репрезентативных моделей для организации взаимодействия заказчика и разработчика ИС, различных групп разработчиков;
• содержит механизмы расширения и специализации базовых концепций языка.
• Структурные предметы:
• Классреализует один или несколько интерфейсов
• Графически класс отображается в виде прямоугольника, обычно включающего секции с именем, свойствами (атрибутами) и операциями.
|
|
|
• Интерфейсописывает поведение элемента, видимое извне
• Интерфейс может представлять полные услуги класса или компонента или часть таких услуг
• Графически интерфейс изображается в виде кружка с именем
• Имя интерфейса обычно начинается с буквы «I».
• Кооперацииимеют как структурное, так и поведенческое измерения
• Конкретный класс может участвовать в нескольких кооперациях
• Графически кооперация изображается как пунктирный эллипс, в который вписывается ее имя.
• Актер. Каждая роль требует от системы определенного поведения
• Изображается как проволочный человечек с именем.
• В модели элемент Use Case применяется для структурирования предметов поведения.
• Элемент Use Case реализуется кооперацией.
• Изображается как эллипс, в который вписывается его имя.
• Активный класс. Похож на обычный класс за исключением того, что его объекты действуют одновременно с объектами других классов
• Изображается как активный прямоугольник, обычно включающий имя, свойства (атрибуты) и операции.
• Обычно компонент – это физическая упаковка различных логических элементов (классов, интерфейсов и сотрудничеств)
• Изображается как прямоугольник с вкладками, обычно включающий имя.
Узел. В узле размещается набор компонентов, который может перемещаться от узла к узлу. Изображается как куб с именем.
Предметы поведения:
Взаимодействие может определять динамику как совокупности объектов, так и отдельной операции
Элементами взаимодействия являются сообщения, последовательность действий (поведение, вызываемое сообщением) и связи (соединения между объектами)
Сообщение изображается в виде направленной линии с именем ее операции.
С помощью конечного автомата может определяться поведение индивидуального класса или кооперации классов
Элементами конечного автомата являются состояния, переходы (от состояния к состоянию), события (предметы, вызывающие переходы) и действия (реакции на переход)
Изображается как закругленный прямоугольник, обычно включающий его имя и его подсостояния (если они есть).
Группирующие предметы:
В пакет могут помещаться структурные предметы, предметы поведения и даже другие группировки предметов
Пакет – это чисто концептуальное понятие и существует только в период разработки
Изображается как папка с закладкой, на которой обозначено его имя и, иногда, его содержание.
Поясняющие предметы:
Изображается в виде прямоугольника с загнутым углом, в который вписывается текстовый или графический комментарий.
6. Отношения UML
Зависимость.Изображается в виде пунктирной линии, возможно направленной на независимый предмет и иногда имеющей метку.
Агрегация– это специальная разновидность ассоциации, представляющая структурное отношение между целым и его частями
Изображается в виде сплошной линии, возможно направленной, иногда имеющей метку и часто включающей другие «украшения», такие как мощность и имена ролей.
Обобщение.Потомок разделяет структуру и поведение родителя
Изображается в виде сплошной стрелки с полым наконечником, указывающим на родителя.
Отношения реализации применяют в двух случаях: между интерфейсами и классами (или компонентами), реализующими их; между элементами Use Case и кооперациями, которые реализуют их
Изображается как нечто среднее между обобщением и зависимостью.
7. Диаграммы UML
• диаграммы классов
• диаграммы объектов
• диаграммы Use Case (диаграммы прецедентов)
• диаграммы последовательности
• диаграммы сотрудничества (кооперации)
• диаграммы схем состояний
• диаграммы деятельности
• компонентные диаграммы
• диаграммы размещения (развертывания).
Дата добавления: 2018-02-15; просмотров: 1227; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!