Основные контуры (разделы) стандарта pm bok Guide
Свод знаний по управлению проектами представляет собой сумму профессиональных знаний по управлению проектами. Руководство PMBOK фиксирует части Свода знаний по управлению проектами, которая обычно считается хорошей практикой.
В настоящем стандарте описываются суть процессов управления проектами в терминах интеграции между процессами и взаимодействий между ними, а также цели, которым они служат. Эти процессы разделены на пять групп, называемых «группы процессов управления проектом».
Группа процессов инициации
она состоит из процессов, способствующих формальной авторизации начала нового проекта. (устав проекта, описание содержание проекта предварительное) – вне времени реализации проекта
Группа процессов планирования
Определяет и уточняет цели и планирует действия, необходимые для достижения целей и содержания, ради которых был предпринят проект.
Группа процессов исполнения
Объединяет человеческие и другие ресурсы для выполнения плана управления проектом данного проекта.
Группа процессов мониторинга и управления
Регулярно оценивает прогресс проекта и осуществляет мониторинг, чтобы обнаружить отклонения от плана управления проектом, и, в случае необходимости, провести корректирующие действия для достижения целей проекта.
Группа завершающих процессов
Формализует приемку продукта, услуги или результата и подводит проект или фазу проекта к правильному завершению.
Области знаний
Рассматривает области знаний по управлению проектами.
Формирование бизнес-логики. Классификация бизнес-правил.
Под бизнес-логикой понимается четко определенный набор требований к функциональности проектируемой программы, вытекающий из специфики моделируемого объекта и запросов потенциальных пользователей программы. Бизнес-логика состоит из бизнес-правил, которые мб классифицированы по различным категориям.
Реализация бизнес-логики в программе возможна на нескольких уровнях. Соверменные программы , функционирующие в сетевых операционных средах, почти всегда построены по идеологии «клиент-сервер», причем в зависимости от сложности и комплексности программы количество функциональных блоков мб и больше, например, «клиент-сервер транзакций-сервер БД». Т.о необходимо выделять, по крайней мере, два уровня бизнес логики: клиентская часть программы и серверная часть. Фактически функциональность программы распределяется между двумя неравными ее частями.
На уровне клиента бизнес-логика обеспечивается особенностями экранного интерфейса( компоновка экранных форм, навигацией между отдельными формами) и соответствующими программными алгоритмами. Бизнес-правила. Ориентированные на манипуляции с данными в базах, в этом случае реализуются за счет подбора различных компонентов используемых в программе и продуманных запросов к СУБД. Практически всегда бизнес-логика клиентского уровня выводится из моделей бизнес-процессов и сопутствующей этим моделям первичной документации
Уровень сервера позволяет реализовывать бизнес-правила за счет адекватного физического проектирования структуры таблиц (сущностей) БД и посредствам создания хранимых процедур
MoSCoW
M - MUST have this.
S - SHOULD have this if at all possible.
C - COULD have this if it does not affect anything else.
W - WON'T have this time but WOULD like in the future. Alternatively WANT.
FURPS — классификация требований к программным системам.
Образована от первых букв слов:
Functionality — Функциональные требования. Являются основными, по этим требованиям строятся диаграммы вариантов использования (Use case diagram).
Usability — Требования к удобству использования.
Reliability — Требования к надежности.
Performance — Требования к производительности.
Supportability — Требования к поддержке.
+ проектные ограничения
Требования выполнениния
Требования к интерфейсу
Физич. требования
Логические правила, сценарные модели, интерфейсы
Классификация бизнес-правил.
Все бизнес-правила можно разделить на 3 основных категории: условия, факты и правила. Условия и факты - основа для логической модели данных и физической базы данных. Третья категория (правила) представляет наибольший интерес, их можно разделить на 5 категорий.
Основные конструктивы языка SQL-94
SELECT– выборка строк, удовлетворяющих заданным условиям. Оператор реализует, в частности, такие операции реляционной алгебры как "селекция" и "проекция".
UPDATE– изменение значений определенных полей в строках таблицы, удовлетворяющих заданным условиям.
INSERT– вставка новых строк в таблицу.
DELETE– удаление строк таблицы, удовлетворяющих заданным условиям. Применение этого оператора учитывает принципы поддержки целостности, поэтому он не всегда может быть выполнен корректно.
Оператор выбора SELECT
Первый пример находит в таблице kadry строку, в которой столбец tabnum=345 . Из этой строки берутся только три указаных столбца. Второй пример выбирает ВСЕ строки из таблицы ceh, и все столбцы.
SELECT fio, dolvn, zarplata FROM kadry WHERE tabnom=345
SELECT * FROM ceh
SELECT kadry.fio, ceh.nameceh WHERE kadry.nomerceh=ceh.nomerceh
Третий пример выбирает фамилии работников из таблицы кадры, а названия цехов, в которых они работают, из таблицы ceh.
Оператор UPDATE— оператор языка SQL, позволяющий обновить значения в заданных столбцах таблицы.
UPDATE ceh SET kod_ceha[1,4]=nameceh[5,8] WHERE nomerceh BETWEEN 3 AND 5 OR nameceh IN ("токарный","литейный").
В таблице ceh в цехах номер 3,4,5 а так же в токарном и литейном первые четыре символа в коде цеха будут заменены на подстроку поля nameceh из той же строки.
Оператор INSERT.
Может вставить в таблицу одну строку, если используется в форме INSERT INTO ... VALUES, а может вставить в таблицу целый набор строк, выбранных подзапросом SELECT из другой таблицы.
INSERT INTO kadry VALUES (4, 0, "Грицко", num, "10/25/1939", NULL)
Оператор DELETE.
Уничтожает строки в таблице
DELETE FROM kadry WHERE ceh=4 AND fio MATCHES "*ов"
Уничтожить в таблице kadry все строки, в которых номер цеха равен 4, а фамилия кончается на буквы "ов".
Проектирование экранных форм. Особенности проектирования и программирования в разных операционных средах.
Проектирование экранных форм
Самый важный вопрос проектирования экранных форм — как сделать, чтобы они были интуитивно понятными и могли, не утомив пользователя, провести его по тому или иному рабочему процессу.
-обеспечить максимальное соответствие стандартам, принятым в рабочей среде пользователя. Следует также добиваться согласованности с другими приложениями, привычными для пользователей.
-Однако при этом легко попасть в зависимость от этого требования и в результате получить программу, напоминающую нечто такое, чем она на самом деле не является. Электронные таблицы и текстовые процессоры хороши для выполнения многих задач, однако в качестве внешних систем баз данных они непригодны, особенно если базу данных нужно обновлять.
-На ознакомление пользователей с новым форматом или стилем требуется совсем немного времени.
Полезно разбить всех пользователей на группы. Вот один из вариантов такого разбиения:
• операторы ввода данных, которые пользуются системой часто и интенсивно, но не выдают запросы;
• пользователи, регулярно выдающие запросы, но вводящие мало данных;
• пользователи, задающие нерегламентированные запросы, иногда выполняющие поиск и (еще реже) обновление;
• пользователи, обеспечивающие поддержку принятия решений, которым нужно работать с нерегламентированными запросами, но которые редко выполняют обновление или не выполняют его вообще;
• операторы, планирующие и контролирующие отчеты и пакетные задания.
Вот общие принципы проектирования экранных форм:
• Все экранные формы должны иметь уникальные и информативные заголовки.
• Все поля необходимо снабдить надписями; при вызове справочной с системы должны быть доступны подробные описания полей.
• Курсор по умолчанию, как правило, должен перемещаться слева направо, а затем сверху вниз.
• Обязательные элементы должны находиться в верхней части экрана. Элементы на экране необходимо упорядочить по степени важности.
• Экранная форма должна обнаруживать ошибочно введенные данные и сообщать о них как можно раньше, а не откладывать проверку.
• Экранная форма не должна состоять из множества страниц .
• Пользователи должны вводить код только один раз и не должны ничего запоминать или записывать при переходе от одной экранной формы к другой.
• Использование специальных эффектов следует свести к минимуму. Если вы решительно настроены придать экранным формам и отчетам профессиональный вид, обратитесь к специалисту-дизайнеру.
• Размещение на экранной форме дополнительных элементов за счет уменьшения размера символов допустимо только в ограниченной степени.
• Большинство пользователей гораздо лучше справляются с вертикальной, а не с горизонтальной прокруткой, особенно если при прокрутке вправо из левой части экрана исчезают важные данные и условные обозначения.
Технологические и организационные особенности этапа отладки и тестирования программной системы.
Отла́дка— этап разработки компьютерной программы, на котором обнаруживают, локализуют и устраняют ошибки. Чтобы понять, где возникла ошибка, приходится :
узнавать текущие значения переменных;
выяснять, по какому пути выполнялась программа.
Существуют две взаимодополняющие технологии отладки.
Использование отладчиков — программ, которые включают в себя пользовательский интерфейс для пошагового выполнения программы: оператор за оператором, функция за функцией, с остановками на некоторых строках исходного кода или при достижении определённого условия.
Вывод текущего состояния программы с помощью расположенных в критических точках программы операторов вывода — на экран, принтер, громкоговоритель или в файл. Вывод отладочных сведений в файл называется журналированием.
Процесс отладки выполняется примерно по такому алгоритму: после того как написан рабочий код производятся тестовые запуски программы на различных наборах тестовых данных. При этом тестер или программист заранее должны получить контрольный результат, с которым будет идти сверка работы проверяемого кода. Например, заранее произвести вычисления. В случае обнаружения расхождений между контрольным и фактическим результатами, начинается поиск проблемного участка кода и выявление ошибок вышеуказанными способами. Сейчас получают довольно мощное распространение средства автоматического тестирования исходного кода программ. Основной прием здесь это создание тестов исходного текста, которые будут применены к тестируемому участку кода, система тестирования сообщит об их результатах. Примерами таких систем могут быть: встроенный модуль doctest в Pythonи мультиязыковая библиотека тестированияxUnit, распространяемая на условияхGNU/GPLиLGPL. Основа применения всех этих средств и техник это разбиение одной большой задачи на ряд четких и более маленьких задач.