Книга: Программное обеспечение и его разработка
Стандарты программного обеспечения
Стандарты программного обеспечения
Стандарты программного обеспечения необходимы группе разработчиков для всех крупных программных систем. Множество иерархически структурированных стандартов программирования нужно любому единому коллективу; это позволяет не вводить неоправданных ограничений. В каждой крупной организации должен быть директор по программному обеспечению. Все стандарты должны быть документированы, разосланы и введены в действие с проверкой исполнения. Существенную роль играет постоянное их изучение.
Если какая-нибудь достаточно крупная группа программистов не следует этим правилам, она не может гарантировать постоянно высокий уровень качества своей продукции. Случайные успехи, конечно, возможны, поскольку некоторые руководители все же знают, как надо работать, но надежной работы ожидать не приходится. Качество разработки программного обеспечения можно повысить, если обратиться к опыту технических дисциплин.
Методы, ставшие общепринятыми во всех других отраслях, в программном обеспечении кажутся абсолютными новинками. Фирма IBM выдала одному из своих служащих премию в 75 тыс. долларов за идею проведения обзоров состояния дел по проводящейся разработке с привлечением коллег и руководящих лиц — за так называемый «сквозной контроль», а ведь в промышленных отраслях этот процесс — обычное дело.
В практике разработки программного обеспечения наблюдается столь быстрый прогресс, что многие организации, занимающиеся этой разработкой, безнадежно отстают от него. Для внедрения среди авторитетной группы программистов правильных, коммерчески обусловленных методов требуются и денежные вложения, и строгий контроль, и сильное руководство.
Стандарты должны иметь иерархическую структуру. Стандарты для аппаратно-интенсивного программного обеспечения могут быть менее строгими, чем стандарты для обеспечения программно-интенсивного.
Значительную роль в деле повышения возможностей использования скудных ресурсов разработчиков программного обеспечения играют последовательная терминология и последовательно составленный набор руководящих документов.
Приведенное ниже множество «стандартов» (табл. 6.6) установлено для крупных программных разработок. У каждого правила могут быть свои исключения, но в целом его следует принимать за основу в начале работ. Введены ли они в действие? Опубликованы и им уже начали следовать? Понятны ли они? Изменялись ли? Кем?
Стандартные разделы программного обеспечения (например, операционная система) вошли в нашу повседневную практику обработки данных, и, хотя мы уже не рассматриваем их в качестве стандартов, они оказывают именно такое действие — определяют стандартные способы выполнения заданий и стандартное деление работ, выполнение которых проводится с их помощью.
Таблица 6.6. Методы производства программного обеспечения
1. Программы операционной системы | Стандартное разделение программного обеспечение |
2. Программы системы управления базой данных | |
3. Программное обеспечение системы связи | |
4. Программы ввода/вывода | |
5. Программы работы с дисплеями | |
6. Программы информационной системы | |
7. Использование управления конфигурацией | |
8. Обеспечение необходимого качества | |
9. Документация, описывающая функцию программы по подпрограммам | |
10. Диаграммы, отображающие взаимоотношения оборудования и программ, с обозначением внутренних и внешних потоков данных | |
11. Языки высокого уровня | |
12. Использование анализа и оценок необходимых ресурсов (ЦП, память) | |
13. Использование структурного программирования | |
14. Размеры модулей небольшие; функциональное разграничение ярко выраженное, обязательное упрятывание информации | |
15. Список ограничений, возникших при проектировании, и принципов построения проекта | |
16. Частый сквозной контроль | |
17. Использование библиотекарей | |
18. Внесение исправлений в рабочие и исходные программы | |
19. Использование средств автоматизации сопровождения | |
20. Проектирование высокой производительности системы | |
а) функциональной: доля удовлетворенных требований | |
б) технической: точность, методология, проверка алгоритмов | |
в) операционной: восстанавливаемость после сбоев | |
г) удовлетворение временных ограничений на производительность |
Важнейшей причиной применения системы управления базой данных должно быть стремление автоматизировать процесс внесения исправлений и сэкономить силы программистов.
- Системы, подсистемы и программное обеспечение
- Общесистемная незамкнутость
- Взгляд сверху вниз
- Различные подсистемы обработки данных в одной системе
- Отделение программного обеспечения от аппаратуры
- Перегрузка аппаратной подсистемы, которую можно принять за неполадку с программным обеспечением
- Стоимость и график разработки предсказать невозможно
- «Эффект заброшенных функций» при разработке больших программ
- Планирование развития
- Занятость
- Эволюционный подход к разработке больших систем
- Задачи руководства программным обеспечением проекта
- Результаты процесса разработки
- План разработки или проекта
- Производительность труда и оценки
- Производительность труда при разработке программного обеспечения
- База данных по производительности труда
- Определения терминов «строка программы» и «человеко-месяц»
- Два значения термина «строка программы»
- Категории программного обеспечения
- Определение человеко-месяца
- Изменчивость
- Вопросник по производительности труда
- Ошибки при подсчете СТП
- Форма отчетности по строкам программ
- Некоторые результаты сбора статистики
- Оценка
- Оценка размеров программы
- Факторы, определяющие трудность разработки
- Функциональные факторы
- Как проводить оценки
- Предположения при проведении оценок
- Организация усилий по разработке программного обеспечения
- Ключевые моменты больших проектов
- Надзор над разработкой
- Управление
- Экономия усилий
- Управление конфигурацией
- Автоматизированная матрица модулей/функций
- Ключ к успеху — руководитель разработки
- Выбор руководителя разработкой программного обеспечения
- Технический опыт
- Карьера разработчика программного обеспечения
- Пять стадий развития всех новых проектов
- Печальная участь первопроходцев
- Будет ли удовлетворен настоящий пользователь?
- Прослушивания
- Прослушивания очень важны
- Что необходимо выносить на прослушивания — и когда?
- Что такое «прослушивание»?
- Кто должен участвовать в прослушиваниях?
- В чем вред прослушивании?
- Отчеты на прослушиваниях — делайте их устно
- Первый выход на прослушивание или в группу инвентаризации
- Кадры и инструментарий
- Купить или сделать
- Разрабатывать самим или заказывать на стороне
- Как заказывать разработку программного обеспечения
- Вид заключаемого контракта
- Что делать, когда все идет прахом
- Поиски замены для руководителя
- Неуправляемый гигант
- Стандарты программного обеспечения
- Ничто не дается бесплатно — средства на стандартизацию тратятся с первых же шагов
- Склонность к фантазированию
- Сопротивление нововведениям
- Изменения дорого обходятся с самого начала
- Разработка или продолжающаяся разработка как наиболее дорогостоящая фаза
- Одна причина оптимистических оценок
- Научные исследования в программном обеспечении
- Отсутствие методов представления программ
- Разрабатывать программы так же, как и аппаратуру?
- Сходство между аппаратурой и программным обеспечением
- Стандарты и руководства по проектированию безопасности
- Производительность труда при разработке программного обеспечения
- Стандарты
- 1.5.2. Кроссплатформенная переносимость и открытые стандарты
- Продукция с минимальным количеством программного обеспечения
- 11.2. СВОЙСТВА ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
- Выбор аппаратного обеспечения для InterBase
- 7.9 Будущее управления хранилищами по версии ассоциации SNIA: стандарты SMI
- Глава 1 Стандарты и угрозы информационной безопасности
- Функция программного обеспечения
- Центр обеспечения безопасности
- Вызов окна программного кода