Как моделируются данные и их движение.

2.4.1. Case-метод Баркера
Цель моделирования данных состоит в обеспечении разработчика ИС концептуальной схемой базы данных в форме одной модели или нескольких локальных моделей, которые относительно легко могут быть отображены в любую систему баз данных.
Наиболее распространенным средством моделирования данных являются диаграммы "сущность-связь" (ERD). С их помощью определяются важные для предметной области объекты (сущности), их свойства (атрибуты) и отношения друг с другом (связи). ERD непосредственно используются для проектирования реляционных баз данных.

Первый шаг моделирования - извлечение информации из интервью и выделение сущностей.
Сущность (Entity) - реальный либо воображаемый объект, имеющий существенное значение для рассматриваемой предметной области, информация о котором подлежит хранению (рисунок 2.18).

Следующим шагом моделирования является идентификация связей.
Связь (Relationship) - поименованная ассоциация между двумя сущностями, значимая для рассматриваемой предметной области.

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

Откуда берутся спецификации.

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

• Описательное название, номер или другой идентификатор спецификации
• Время последнего пересмотра и отметку, кем был выполнен пересмотр.

· Логотип или торговую марку, указывающую кому принадлежит право на копирование, владельца и происхождение документа.

• Содержание документа, если документ длинный
• Ответственное лицо или организацию по вопросам по спецификации, по обновлениям и отклонениям.
• Важность, область применения спецификации и её назначение.
• Термины, определения и аббревиатуры для пояснения сути спецификации.
• Способы проверки для всех установленных требований и характеристик.
• Материальные требования: физические, механические, электрические, химические и другие. Целевые и допустимые.
• Требования по эксплуатационному тестированию. Целевые и допустимые.
• Изображения, фотографии или технические иллюстрации
• Требования по мастерству
• Требования к сертифицированности
• Требования по технике безопасности
• Экологические требования
• Контроль по обеспечению кач-ва, образец для проверки, проверка, критерий приёма работы.
• Лицо или организация ответственное за выполнение спецификации.
• Выполнение и доставка.
• Условия по отклонениям, перепроверке, пересмотре, корректировке измерений и характеристик
• Ссылки и цитаты в тексте спецификации которые могут потребоваться для установки ясности документа.
• Подписи и разрешения, если они необходимы.
• Контроль изменений (с помощью специальных компьютерных программ) для последовательной разработки, проверки и выполнения, если документ предназначен для внутреннего использования.
• Приложения, которые раскрывают детали, добавляют ясности, или пояснения по оплате.

10. Откуда берутся требования.

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

Требования могут выражаться в виде текстовых утверждений и графических моделей.

В классическом техническом подходе совокупность требований используется на стадии проектирования ПО. Требования также используются в процессе проверки ПО, так как тесты основываются на определённых требованиях.

Этапу разработки требований, возможно, предшествовало технико-экономическое обоснование, или концептуальная фаза анализа проекта. Фаза разработки требований может быть разбита на выявление требований (сбор, понимание, рассмотрение и выяснение потребностей заинтересованных лиц), анализ (проверка целостности и законченности), спецификация (документирование требований) и проверка правильности.

Источники требований

• Федеральное и муниципальное отраслевое законодательство (конституция, законы, распоряжения)
• Нормативное обеспечение организации (регламенты, положения, уставы, приказы)
• Текущая организация деятельности объекта автоматизации
• Модели деятельности (диаграммы бизнес-процессов)
• Представления и ожидания потребителей и пользователей системы
• Журналы использования существующих программно-аппаратных систем
• Конкурирующие программные продукты

 

Как управлять проектом.

Перейти к: навигация, поиск

Управле́ние разрабо́ткой програ́ммного обеспе́чения (англ. Software project management) - особый вид управления проектами, в рамках которого происходит планирование, отслеживание и контроль за проектами по разработке программного обеспечения. Ключевым моментом в управлении проектом по разработке программного обеспечения является правильный выбор метода разработки.

 

Сопутствующие процессы при управлении проектом

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

• Управление рисками начинается с составления технико-экономического обоснования, включающего в себя расчет возможных доходов и расходов проекта и список возможных неуправляемых рисков, а также план действий в случае их наступления. Важным моментом в управлении рисками проекта по разработке программного обеспечения является постоянный мониторинг текущих рисков на протяжении всего проекта.
• Управление требованиями, включающее в себя анализ требований, является важной частью процесса управлением разработкой программного обеспечения. Посредством анализа требований бизнес-аналитики и разработчики программного обеспечения выявляют потребности и требования заказчика, предъявляемые к конечному программному обеспечению.
• Конфигурационное управление в рамках управления программным проектом в общем заключается в управлении версиями, определении правил именования переменных, функций, классов и т.д. в исходном коде и документации, а также определении соглашений об архивировании программного обеспечения.
• Управление изменениями проекта по разработке программного обеспечения ориентировано на анализ влияния изменений свойств и функций конечного программного обеспечения в процессе реализации проекта. Управление изменениями тесно связано с управлением требованиями, так как бизнес-аналитки и разработчики программного обеспечения, выявив изменения в потребностях и требованиях заказчика, способны перестроить или улучшить дальнейшую реализацию проекта. Однако каждое изменение или нововведение способно так или иначе повлиять на сроки проекта или его бюджет, поэтому очень важно провести предварительную оценку рисков.

Планирование, отслеживание и контроль за проектом

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

• Цель отслеживания и контроля над проектом заключается в поддержании соответствия действий команды текущему состоянию проекта. В случае отклонения проекта от плана управляющий проектом может оперативно исправлять выявленные ошибки. Отслеживание состояния проекта включает в себя регулярные встречи с командой для обсуждения текущего состояния проекта.

12. Какие (драйвера) движущие силы проекта.

1.Календарный подход к разработке

+все подчинено временным вехам, определены сроки, управление сроками хорошо и для заказчика и управленцам

+планирование

-рзработчику приходиться подчиниться графику в ущерб качеству, сути работы, уменьшается тестирование, ревью и рефакторинг

2.Процессы управляемые документацией

+хорошая управляемость, просто управленцам

+организованнось в работе

-в сроки отчётности нет содержательной работы

-документацию не читают и удалённое отношение к продукту

3.Управляемый требованиями

+соответсвует нуждам заказчика

+разработчик понимает суть и объём работы

+делается только то, что нужно

-изменение требований

-страдает управляемость

4.Архитектурный тип

+решения не меняются

-ограничение архитектуры

-управляемость процессом - не видно разницы между прототипом и работающей версией

5.Управление бизнесс-процессом

управленческие бизнесс-процессы - бизнес-правила

базовые(производство)

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

+соответствие самому бизнесу

+стабильность

-закреплённость бизнес-организации