Успех программного продукта: что делать?
Стив Макконнелл в своей книге [17] приводит тест программного проекта на выживание. Этот чек-лист из 33-х пунктов, который необходимо процитировать с небольшими корректировками. Руководитель программного проекта должен его периодически использовать для внутреннего аудита своих процессов.
Чтобы программный проект стал успешным, необходимо:
1. Четко ставить цели.
2. Определять способ достижения целей.
3. Контролировать и управлять реализацией.
4. Анализировать угрозы и противодействовать им.
5. Создавать команду.
1. Ставим цели
1.1. Концепция определяет ясные недвусмысленные цели.
1.2. Все члены команды считают концепцию реалистичной.
1.3. У проекта имеется обоснование экономической эффективности.
1.4. Разработан прототип пользовательского интерфейса.
1.5. Разработана спецификация целевых функций программного продукта.
1.6. С конечными пользователями продукта налажена двухсторонняя связь
2. Определяем способ достиженияцелей
2.1. Имеется детальный письменный план разработки продукта.
2.2. В список задач проекта включены «второстепенные» задачи (управление конфигурациями, конвертация данных, интеграция с другими системами).
2.3. После каждой фазы проекта обновляется расписание и бюджет.
2.4. Архитектура и проектные решения документированы.
2.5. Имеется план обеспечения качества, определяющий тестирование и рецензирование.
2.6. Определен план многоэтапной поставки продукта.
2.7. В плане учтены обучение, выходные, отпуска, больничные.
2.8. План проекта и расписание одобрен всеми участниками команды.
|
|
|
3. Контролируем и управляемреализацией
3.1. У проекта есть куратор. Это такой топ-менеджер исполняющей компании, который лично заинтересован в успехе данного проекта.
3.2. У проекта есть менеджер, причем только один!
3.3. В плане проекта определены «бинарные» контрольные точки.
3.4. Все заинтересованные стороны могут получить необходимую информацию о ходе проекта.
3.5. Между руководством и разработчиками установлены доверительные отношения.
3.6. Установлена процедура управления изменениями в проекте.
3.7. Определены лица, ответственные за решение о принятии изменений в проекте.
3.8. План, расписание и статусная информация по проекту доступна каждому участнику.
3.9. Код системы проходит автоматическое рецензирование.
3.10. Применяется система управления дефектами.
4. Анализируемугрозы
4.1. Имеется список рисков проекта. Осуществляется его регулярный анализ и обновление.
4.2. Руководитель проекта отслеживает возникновение новых рисков.
4.3. Для каждого подрядчика определено лицо, ответственное за работу с ним.
5. Работаем над созданиемкоманды
|
|
|
5.1. Опыт команды достаточен для выполнения проекта.
5.2. У команды достаточная компетенция в прикладной области.
5.3. В проекте имеется технический лидер.
5.4. Численность персонала достаточна.
5.5. У команды имеется достаточная сплоченность.
5.6. Все участники привержены проекту.
Оценка и интерпретациятеста
Оценка: сумма баллов, каждый пункт оценивается от 0 до 3:
- 0 — даже не слышали об этом;
- 1 — слышали, но пока не применяем;
- 2 — применяется частично;
- 3 — применяется в полной мере.
Поправочные коэффициенты:
- для малых проектов (до 5 человек) — 1.5;
- для средних (от 5 до 20 человек) — 1.25.
Результат:
- <40 — завершение проекта сомнительно.
- 40-59 — средний результат. В ходе проекта следует ожидать серьезные проблемы.
- 60-79 — хороший результат. Проект, скорее всего, будет успешным.
- 80-89 — отличный результат. Вероятность успеха высока.
- >90 — великолепный результат. 100% шансов на успех.
Этот чек-лист перечисляет, что надо делать для успеха программного проекта, но не дает ответ на вопрос как это следует делать. Именно об этом пойдет речь в остальных лекциях.
Выводы
Процесс разработки ПО — совокупность процессов, обеспечивающих создание и развитие программного обеспечения. Модель процесса разработки ПО — формализованное представление процесса разработки ПО. Часто при описании процессов вместо слова модель употребляется термин методология, что приводит к неоправданному расширению данного понятия.
|
|
|
· Модели играют важнейшую роль в проектировании программ. При построении моделей используется абстрагирование и декомпозиция.
· То, что производят программисты нематериально – это коллективные мысли и идеи, выраженные на языке программирования. В силу уникальности отрасли опыт, накопленный в отраслях материального производства, мало способствует успеху в управлении программным проектом. Прямые аналогии с этими отраслями не работают. Управлять разработкой ПО надо иначе.
· Не существует единственного правильного процесса разработки ПО. Эффективный производственный процесс должен основываться на итеративности, инкрементальности, самоуправляемости команды и адаптивности, в соответствие с «Законом 4-х П». Главный принцип: не люди должны строиться под выбранную модель процесса, а модель процесса должна подстраиваться под конкретную команду, чтобы обеспечить ее наивысшую производительность.
· Чтобы программный проект стал успешным, необходимо:
|
|
|
1) Четко ставить цели.
2) Определять способ достижения целей.
3) Контролировать и управлять реализацией.
4) Анализировать угрозы и противодействовать им.
5) Создавать команду.
Контрольные вопросы
1. В чем суть моделирования?
2. Что такое задачи абстрагирования и последующей декомпозиции?
3. Какие современные методы моделирования ПО?
4. Какие плюсы и минусы тяжелых и легких моделей процессов разработки программного обеспечения?
5. Что такое итеративность и инкрементальность при разработке программного обеспечения?
13. Что необходимо для успеха программного проекта?
Дополнительная литература и источники
1. IEEE Std 610.12-1990, IEEE Standard Glossary of Software Engineering Terminology.
2. IEEE Std 1074-1995, IEEE Standard for Developing Software Life Cycle Processes.
3. «Руководство к своду знаний по программной инженерии». The Guide to the Software Engineering Body of Knowledge, SWEBOK, IEEE Computer Society Professional Practices Committee, 2004.
4. David Rubinstein, «Standish Group Report: There's Less Development Chaos Today». 2007
5. Брукс Фредерик, «Мифический человеко-месяц, или Как создаются программные комплексы», Пер. с англ., СПб., Символ-Плюс, 1999.
6. «PMBOK. Руководство к Своду знаний по управлению проектами», 3-е изд., PMI, 2004.
7. Уолкер Ройс, «Адаптивный стиль управления программными проектами». Открытые системы. 2006. № 1.
8. Ершов А. П., «О человеческом и эстетическом факторе в программировании». Информатика и образование. 1993. № 6.
9. Paulk, Mark C., and others, Capability Maturity Model for Software, Version 1.1 (CMU/SEI-93-TR-24). Pittsburgh, Pa.: Software Engineering Institute, Carnegie Mellon University, 1993.
10. Филипп Крачтен, «Введение в Rational Unified Process», Вильямс, 2002 г.
11. «MSF, Microsoft, Microsoft Solutions Framework», Отдел MSF, Microsoft, 2002.
12. M. Pomeroy-Huff, J. Mullaney, R. Cannon, M. Sebern, «The Personal Software Process (PSP) Body of Knowledge», version 1.0, SPECIAL REPORT CMU/SEI, 2005
13. Watts S. Humphrey, «The Team Software Process (TSP)», Technical Report CMU/SEI, 2000
14. Kent Beck, and others, «Manifesto for Agile Software Development», 2001
15. А. Коуберн, «Люди как нелинейные и наиболее важные компоненты в создании программного обеспечения», Humans and Technology Technical Report, Oct.1999 (русский перевод — К.Максимов, А.Максимова)
16. А. Коуберн, «Каждому проекту своя методология», Humans and Technology Technical Report, TR 99.04, Oct.1999 (русский перевод — К.Максимов, А.Максимова).
17. С. Макконнелл, «Остаться в живых. Руководство для менеджеров программных проектов», «Питер», 2006.
Дата добавления: 2018-05-02; просмотров: 895; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!