- •1 Этапы разработки по.
- •2 Проблемы разработки по
- •3 Технологии организации разработки по. 4 и 5.
- •6. Модельные техники.
- •8. Как моделируются данные и их движение?
- •9. Откуда берутся спецификации.
- •10. Откуда берутся требования.
- •11. Как управлять проектом.
- •Сопутствующие процессы при управлении проектом
- •Планирование, отслеживание и контроль за проектом
- •12. Какие (драйвера) движущие силы проекта.
- •13. Как можно разделить различные подходы к управлению проектами. ГосТы
- •14. Что такое требования и как с ними работать.
- •Проверка требований
- •Анализ требований
- •Документирование требований
- •15. Роли и обязанности участников проекта. Менеджер проекта
- •16. Риски проекта.
- •18. Use case, отличие от историй пользователя.
- •20/19. Диаграммы uml
- •21. Чего не хватает в umi.
- •Скорость загрузки
- •Управление файлами
- •22. Как структурировать программу?
- •23. Что такое компонента и компонентная разработка?
- •Языки программирования
- •Отличия от ооп
- •25. Основные принципы ооп.
- •26. Чем класс отличается от объекта и от интерфейса.
- •Классы и объекты, понятие экземпляра класса, понятие членов класса
- •Интерфейс и реализация, наследование реализации
- •27. Что такое программирование по контракту и как выразить контракт класса.
- •Описание
- •28. Unit test. Автоматическое тестирование.
- •29. Паттерны проектирования их применение.
- •30. Архитектура, типы.
- •31. Сервис ориентированная архитектура web сервисы и как тут работает xml.
- •Достоинства
- •Недостатки
- •32. Примеры основных диаграмм uml.
- •33. Чем отличается требования спецификации тех проект и проект разработки по?
- •34. Возможно ли тестирование на разных этапах проекта на ранних или поздних чем оно отличается? см 1
16. Риски проекта.
1. внутренние изъяны календарного планирования
2. раздувание требований (изменение требований)
3. текучесть кадров
4. нарушение спецификаций
5. низкая производительность
Вы чаще упускаете какие-то работы, которые оказываются нужными, чем включаете в расписание работы, которые впоследствии окажутся ненужными. Любая переоценка размера работ, оказавшаяся в вашем плане, редко оказывается достаточной, чтобы компенсировать недооценку.
Программное обеспечение, которое вы со своей командой разрабатываете, всегда предназначено для того, чтобы вписаться в область деятельности вашего клиента. В одном вы можете быть уверены – в том, что эта область не останется статичной за время создания программного обеспечения. Она будет изменяться со скоростью, диктуемой рынком и собственными темпами технологического развития.
17. Реинженеринг, рефакторинг, ревью.
Реинжиниринг — это радикальное переосмысление и перепроектирование деловых процессов для достижения резких, скачкообразных улучшений главных современных показателей деятельности компании, таких, как стоимость, качество, сервис и темпы.
Рефакторинг или рефакторирование (англ. refactoring) — процесс изменения внутренней структуры программы, не затрагивающий её внешнего поведения и имеющий целью облегчить понимание её работы[1]. В основе рефакторинга лежит последовательность небольших эквивалентных (то есть сохраняющих поведение) преобразований. Поскольку каждое преобразование маленькое, программисту легче проследить за его правильностью, и в то же время вся последовательность может привести к существенной перестройке программы и улучшению её согласованности и четкости.
Рефакторинг нужно применять постоянно при разработке кода. Основными стимулами его проведения являются следующие задачи:
необходимо добавить новую функцию, которая недостаточно укладывается в принятое архитектурное решение;
необходимо исправить ошибку, причины возникновения которой сразу не ясны;
преодоление трудностей в командной разработке, которые обусловлены сложной логикой программы.
Какой код ревьювится? Сделали новую фичу или пофиксили баг — на ревью попадают модули, в которых сделаны изменения. Какие используете инструменты? Скриптом генерится pdf-ка с diff-ом всех измененных файлов. Как код попадает на review? Есть свой веб-тул для формальных ревью (не только кода, ещё доков и т.п.). Всем заинтересованным рассылается письмо, выставляются даты, люди заносят свои комментарии, автор исправляет и выкладывает новую версию и снова идет ревью, когда все согласились (грубо говоря поставили галочки) — ревью закрывается. Как используются результаты review? Код должен быть исправлен в соответствии с комментариями, или автор должен убедить комментирующего, что тот не прав. За всем следит назначенный модератор. Как отслеживается что замечания сделанные во время review были исправлены? В конце ревью все участники видят, что код приведен в соответствие с выдвинутыми замечаниями, без общего согласия ревью нельзя закрыть, а без закрытия ревью тул, отслеживающий внесение изменений на главную ветку в системе контроля версий, просто не даст сделать изменения на мейне.