Powered by Invision Power Board


  Ответ в темуСоздание новой темыСоздание опроса

> Тонкости работы с программными продуктами
Mentat
Дата Apr 2 2008, 02:03 PM
Цитировать сообщение




Administrator
***


Группа: Admin
Сообщений: 2009
Пользователь №: 133
Регистрация: 5-February 04





Есть на свете такой умный товарищ. Зовут его Роберт Гласс. Он написал замечательную книгу - Facts and Fallacies of Software Engineering". Она есть и в русском переводе - "Факты и заблуждения профессионального программирования". (Оную в электронном виде не нашел.)

И вот, квинтэссенция мудрости. ( Уж простите, переводил сам. Что понял, то понял... :) )

Факты

Люди

1. Самый важный фактор в программистском бизнесе - это качество программистов.
2. Лучшие программисты в 28 раз эффективней худших.
3. Подключение людей к проекту на поздних стадиях лишь задерживает проект.
4. Производственные условия играют существенную роль в вопросах продуктивности и качества.

Инструментарий и технологии

1. Ажиотаж вокруг новых технологий и прибамбасов - настоящий бич в программистских конторах.
2. Новые инструменты и технологии поначалу всегда снижают продуктивность и качество.
3. Программеры всегда много толкуют о новых примочках, но редко их используют.

Оценки

1. Одна из двух основных причин провала проектов - плохая оценка сложности.
2. Оценки сложности проекта делают не вовремя.
3. Проект оценивают совсем не те люди.
4. Оценки запущенных проектов редко корректируются.
5. Неудивительно, что оценки сложности программных проектов плохие, но мы живем и умираем в соответствии с ними!
6. Существуют нестыковки между управленцами и программерами.(Я бы даже сказал - пропасть)
7. Всегда делайте анализ технической осуществимости и экономической целесообразности проекта. (Как это верно!!!)

Повторное использование

1. "Повторное использование в малом" - кошерно.
2. "Повторное использование в большом", чаще всего невозможно.
3. "Повторное использование в большом" лучше всего работает на похожих или родственных проектах.
4. Многократно используемый компонент в 3 раза тяжелей создать и он должен быть оттестирован в трех различных конфигурациях.
5. Модификация такого компонента приводит к появлению ошибок.
6. Решение проблемы "повторного использования" лежит в плоскости создания коцептуальных наработочек.

Техническое задание

1. Одна из самых типичных причин неконтролируемых проектов - изменяемый набор требований к проекту.
2. Ошибки в ТЗ дороже всего исправлять в ходе разработки.
3. Отсутствие ТЗ - самая большая ошибка.

Design-Проектирование

1. Точное ТЗ - просто бомба. Двусмысленное ТЗ - просто пердеж. (Explicit requirements 'explode' as implicit requirements for a solution evolve.)
2. Хорошее и единственное решение проблемы встречается редко.
3. Проектирование - сложный итеративный процесс. Начальный дизайн системы обычно плох и далек от оптимального.

Кодирование

1. "Вводные" проектировщика редко соответствуют "вводным" программера. (Designer 'primitives' rarely match programmer 'primitives'.)
2. COBOL - плохой язык программирования, но другие еще хуже. ( Гы Гы

Исправление ошибок

1. Отладка - самая време-затратная часть проекта.

Тестирование

1. Программы, в лучшем случая, тестируются процентов на 55-60.
2. 100 процентное тестирование очень далеко от достаточного уровня.
3. Средства тестирования очень важны, но редко используемы.
4. Автоматизация тестирования очень редка. Большинство процедур тестирования не может быть автоматизировано.
5. Самописный отладочный код - важное дополнение к средствам тестирования.

Инспекция и перепросмотр

1. Строгая контроль может устранить до 90 % ошибок еще до запуска теста.
2. Строгий контроль не может заменить тестирования.
3. Post-delivery reviews, postmortems, and retrospectives are important and seldom performed.
4. Рецензии это техническая и социологическая штука и они должны быть аккумулированы и переработаны.

Поддержка

1. Поддержка обычно составляет от 40 до 80 процентов расходов потребителя ПО и это очень важная часть жизненного цикла ПО
2. Улучшения составляют порядка 60% от объема расходов на поддержку.
3. Поддержка это продукт а не проблема.
4. Контроль, осмыслени и понимание существующего продукта - самая сложная задача.
5. Хорошо предлагать больше поддержки.

Качество

1. Качество - это совокупность свойств.
2. Если юзер доволен - это еще не "качество". "Отвечать требованиям" - это еще не "качество". Укладываться в бюджет или сроки - это еще не "качество"

Надежность

1. Существуют ошибки, которые программеры склонны совершать
2. Ошибки кучкуются.
3. Не существует единого лучшего способа устранения ошибок.
4. Остаточные ошибки всегда существуют. Цель в том, чтобы минимизировать или исключить серьезные ошибки.

Эффективность

1. Эффективность происходит из хорошего дизайна и хорошего кодирования.
2. Высокоуровневые языки продуктивней.
3. Ищите компромисс между оптимизацией по времени и размеру.

Исследования

1. Много "исследователей" рекомендуют раньше чем изучают.

Заблуждения

1. Вы не можете управлять тем, что не можете измерить.
2. Вы можете управлять качеством ПО.
3. Программирование может и должно быть обезличенным.
4. Инструмены и технологии. Все одним мирром мазаны (Tools and techniques: one size fits all).
5. Программирование нуждается в новых методиках.
6. Для оценки стоимости проекта и графика выполнения нужно оценить объем проекта в строках кода.
7. Случайные данные для тестирования хороший метод оптимизационного тестирования.
8. При наличии достаточного количества глаз все ошибки мельчают. (Given enough eyeballs, all bugs are shallow". Известен также как закон Линуса, хотя введен в обход Эриком Реймондом)
9. Хороший способ оценки стоимости обслуживания и принятия решения о замене продукта, опираться на предыдущие траты.
10. Вы учите людей программированию, показывая им как писать программы.

http://shalnev.blogspot.com/search/label/%...%BD%D0%B8%D0%B5
PM
Top
0 Пользователей читают эту тему (0 Гостей и 0 Скрытых Пользователей)
0 Пользователей:

Опции темы Ответ в темуСоздание новой темыСоздание опроса