Проектирование информационных систем

Главная > Информатика > Проектирование ПО

Персональный компьютер - революция в вычислениях

КПД команды программистов — как у паровоза Черепановых: все пыхтят и создают работу друг для друга. Полезный выход — 2%.

Разделы страницы о стадиях ЖЦП:

Жизненный цикл программы (ЖЦП)

Этапы ЖЦП:

  1. Допроектное обследование предметной области и составление ТЗ:
    1. Бизнес-обследование предметной области, включая системное обследование ИС и средств автоматизауии. Входные документы: диктофонные записи интервью, руководящие документы компании (с глоссарием предметной области)
    2. Бизнес-моделирование (схематическое описание и согласование бизнес-процессов компании)
    3. Разработка и согласование Концепции системы
    4. Составление и согласование с Заказчиком Технического задания (ТЗ)
  2. Проектирование и разработка:
    1. Разработка проектных документов (модели данных, потоков, пользовательского интерфейса, основных алгоритмов...)
    2. Кодирование (программирование) и генерация БД
    3. Тестирование
    4. Отладка
    5. Документирование
  3. Работа с готовым продуктом:
    1. Внедрение
    2. Сопровождение (консультации и модификации)

Ссылки и книги о ЖЦП:

Разработка концепции системы

Ковыляющий по прямой дороге опередит бегущего, который сбился с пути. (Фрэнсис Бэкон)

Техническое задание (спецификация системы)

Без внятного ТЗ получишь результат ХЗ.

Рекомендации по составлению спецификаций

Примеры ТЗ и спецификаций

Другие проектные документы

Опыт проектировщиков ПО

Последние 10% работы перед запуском проекта требуют столько же энергии, как и первые 90%. (Роб Калин, со-основатель Etsy)

"Рыбы" и шаблоны документов

Методы проектирования

Делайте каждую деталь идеальной. Ограничивайтесь минимумом деталей. (Джэк Дорсей, со-основатель Twitter)

Объектно-ориентированное проектирование

Принципы объектно-ориентированного дизайна:

  1. Изящество всегда вознаграждается.
  2. Сначала заставь работать, потом ускоряй.
  3. Помните принцип «Разделяй и властвуй».
  4. Отделите создателя класса, от его пользователя (программиста-клиента).
  5. Когда создаете класс, постарайтесь использовать такие имена, чтобы комментарии не понадобились.
  6. Анализ и дизайн должны определить, как минимум, классы вашей системы, их открытые интерфейсы и их отношения с другими классами, в особенности — базовыми.
  7. Автоматизируйте все.
  8. Пишите тестовый код первым (прежде чем написать класс) для того, чтобы проверить, что разработка класса завершена.
  9. Все проблемы разработки ПО могут быть упрощены добавлением дополнительного уровня концептуального обобщения.
  10. Обобщение должно иметь значение.
  11. Делайте классы настолько атомарными, насколько это возможно.
  12. Следите за длинными списками параметров.
  13. Не повторяйтесь.
  14. Следите за операторами switch или цепочками ветвлений if-else.
  15. С точки зрения дизайна, осмотрите и отделите вещи, которые меняются, от вещей, которые остаются неизменными.
  16. Не расширяйте базовую функциональность с помощью подклассов.
  17. Меньшее — это большее.
  18. Прочтите ваши классы вслух, чтобы убедиться, что они логичны.
  19. Когда выбираете между наследованием и композицией, спросите себя требуется ли приведение к базовому типу.
  20. Используйте члены класса для изменения значения и перекрытие методов для изменения поведения.
  21. Следите за перегрузкой.
  22. Используйте иерархии исключений, предпочитетльно, производных от специфичных классов исключений в стандартной иерархии Java.
  23. Иногда помогает простая агрегация.
  24. Смотрите с точки зрения программиста-клиента и человека, поддерживающего код.
  25. Остерегайтесь «синдрома гигантских объектов».
  26. Если надо сделать что-нибудь безобразное, покрайней мере локализуйте безобразие внутри класса.
  27. Если надо сделать что-нибудь непереносимое, создайте абстракцию для этой задачи и локализуйте ее в классе.
  28. Объекты не должны просто хранить данные.
  29. Сперва попробуйте композицию, прежде чем создать новые классы из существующих.
  30. Используйте наследование и перекрытие методов для выражения разницы в поведении и поля для выражения различий состояний.
  31. Избегайте несогласованности.
  32. Избегайте ограничений при наследовании.
  33. Используйте шаблоны проектирования для уничтожения «голой функциональности».
  34. Остерегайтесь «аналитического паралича».
  35. Когда вам кажется, что у вас все проанализировано, разработано или реализовано, проведите сквозной контроль.

Искусство программирования

Литература по составлению технического задания

Главная

Информатика : Стандарты | ИТ-менеджмент | Системный анализ | Алгоритмы | Разработка | ОС | ЯВУ | СУБД | Интернет | Кибернетика | Электроника | Порталы | Курсы | Продукция | Книги | Статьи

Справочники | Математика | Эвристика | Рекрутинг | Предметные области | Компьютерные игры

На правах рекламы (см. условия):    

© «Сайт Игоря Гаршина», 2002, 2005. Автор и владелец - Игорь Константинович Гаршин (см. резюме). Пишите письма (Письмо И.Гаршину).
Страница обновлена 28.09.2022
[an error occurred while processing this directive]
Яндекс.Метрика