Группа разработчиков пользовательской документации

• Группа менеджмента и маркетинга продукта

Группа технической поддержки

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

Администратор программы бета-тестирования

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

Риски проекта.

1. внутренние изъяны календарного планирования

2. раздувание требований (изменение требований)

3. текучесть кадров

4. нарушение спецификаций

5. низкая производительность

Вы чаще упускаете какие-то работы, которые оказываются нужными, чем включаете в расписание работы, которые впоследствии окажутся ненужными. Любая переоценка размера работ, оказавшаяся в вашем плане, редко оказывается достаточной, чтобы компенсировать недооценку.

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

17. Реинженеринг, рефакторинг, ревью.

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

Рефакторинг или рефакторирование (англ. refactoring) — процесс изменения внутренней структуры программы, не затрагивающий её внешнего поведения и имеющий целью облегчить понимание её работы ^[1] . В основе рефакторинга лежит последовательность небольших эквивалентных (то есть сохраняющих поведение) преобразований. Поскольку каждое преобразование маленькое, программисту легче проследить за его правильностью, и в то же время вся последовательность может привести к существенной перестройке программы и улучшению её согласованности и четкости.

Рефакторинг нужно применять постоянно при разработке кода. Основными стимулами его проведения являются следующие задачи:

1. необходимо добавить новую функцию, которая недостаточно укладывается в принятое архитектурное решение;

2. необходимо исправить ошибку, причины возникновения которой сразу не ясны;

3. преодоление трудностей в командной разработке, которые обусловлены сложной логикой программы.

 

Какой код ревьювится?
Сделали новую фичу или пофиксили баг — на ревью попадают модули, в которых сделаны изменения.

Какие используете инструменты?
Скриптом генерится pdf-ка с diff-ом всех измененных файлов.

Как код попадает на review?
Есть свой веб-тул для формальных ревью (не только кода, ещё доков и т.п.). Всем заинтересованным рассылается письмо, выставляются даты, люди заносят свои комментарии, автор исправляет и выкладывает новую версию и снова идет ревью, когда все согласились (грубо говоря поставили галочки) — ревью закрывается.

Как используются результаты review?
Код должен быть исправлен в соответствии с комментариями, или автор должен убедить комментирующего, что тот не прав. За всем следит назначенный модератор.
Как отслеживается что замечания сделанные во время review были исправлены?
В конце ревью все участники видят, что код приведен в соответствие с выдвинутыми замечаниями, без общего согласия ревью нельзя закрыть, а без закрытия ревью тул, отслеживающий внесение изменений на главную ветку в системе контроля версий, просто не даст сделать изменения на мейне.

Use case, отличие от историй пользователя.

Прецеде́нт (англ. Use Case), также: вариант использования, сценарий использования — спецификация последовательностей действий (варианты последовательностей и ошибочные последовательности) в Унифицированном языке моделирования (UML), которые может осуществлять система, подсистема или класс, взаимодействуя с внешними акторами (англ. Actors).

Прецеденты были предложены Иваром Якобсоном и значительно популяризированы Алистером Коберном.

Прецеде́нт (англ. Use Case), также: вариант использования, сценарий использования — спецификация последовательностей действий (варианты последовательностей и ошибочные последовательности) в Унифицированном языке моделирования (UML), которые может осуществлять система, подсистема или класс, взаимодействуя с внешними акторами (англ. Actors).

Прецеденты были предложены Иваром Якобсоном и значительно популяризированы Алистером Коберном.

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

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

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

Один и тот же прецедент может быть описан с различной степенью детализации.

В MSF используются аналоги прецедентов — сценарии (англ. Scenario).

Диаграммы UML

Диаграммы UML

Структурные диаграммы:

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

Диаграммы поведения:

• Деятельности - используется для моделирования процесса выполнения операций.
• Состояний - предназначена для отображения состояний объектов системы, имеющих сложную модель поведения.
• Вариантов использования - используется при описании бизнес процессов автоматизируемой предметной области, определении требований к будущей программной системе.

Диаграммы взаимодействия:

• Коммуникации (UML2.0) / Кооперации (UML1.x) - диаграмма, на которой изображаются взаимодействия между частями композитной структуры или ролями кооперации.
• Обзора взаимодействия (UML2.0) - разновидность диаграммы деятельности, включающая фрагменты диаграммы последовательности и конструкции потока управления.
• Последовательности - диаграмма, на которой показаны взаимодействия объектов, упорядоченные по времени их проявления. Используется в языке UML.
• Синхронизации (UML2.0) - альтернативное представление диаграммы последовательности, явным образом показывающее изменения состояния на линии жизни с заданной шкалой времени. Может быть полезна в приложениях реального времени.

 

Чего не хватает в UMI.

коммерческая система управления сайтом (CMS), написанная на языке программирования PHP. Создаётся с 2004 года командой российских разработчиков «Юмисофт». В массовую продажу поступила в 2007 году. Существует в бесплатной и коммерческой версиях.

Главная идеологическая особенность UMI.CMS — user-friendly интерфейс ^[2]. Например, поддерживается изменение структуры сайта с использованием drag & drop. В последних версиях используется способ редактирования содержания страницы и компонентов страниц на самом сайте без перехода в административный интерфейс и диалоговых окон.

Быстродействие

 

Давайте откроем рекламный проспект UMI.CMS и пробежимся по нему глазами. У вас его, наверное, нет, но я постараюсь по памяти сформулировать один из пунктов: “UMI.CMS выдерживает несколько миллионов посетителей в день”.

Предположим, что если день - 12 часов, а “несколько миллионов” - минимум 2 миллиона (для сравнения - у ЖЖ примерно 2-4 млн). То есть в час у нас примерно 166 667 посетителей или 2778 посетителей в минуту. Выглядит круто, правда? На практике это не так: получив в течение 1 минуты 2000 запросов сайт UMI.CMS умирает.

Скорость загрузки

Что касается удобства использования, то проблемы начинаются сразу как только пользователь входит в админку. Интерфейс в UMI.CMS тяжеловесный, как и в любой системе подобного рода. При загрузке на сервер отправляется аж 99 (!) HTTP-запросов и время порой больше 30 секунд.

При входе пользователь видит перед собой дерево сайта, которое подгружается по частям аяксом. Если у вас (не дай Бог) в каком-нибудь разделе накопилось свыше сотни подразделов, то подгрузка и отображение списка займет секунд 10-20.

Управление файлами

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

Программирование в UMI.CMS

 

Каждый модуль в UMI.CMS - класс. Правда, этот класс разбит на несколько файлов (как - не спрашивайте) и может содержать только public методы;). Последний факт в корне меняет стандартные представления об объектно-ориентированном программировании, заставляя придумывать все большие ухищрения для работы. Отладка функций, которые вы добавляете в класс крайне затруднена: сообщения об ошибках не выводятся (а если и выводятся, то в совсем уж критических случаях). Жуть!