Управление подвигом ... Сайт про подходы и инструменты, которые помогают совершить подвиг !
  • ГЛАВНАЯ
  • СПОРТ
  • ПУТЕШЕСТВИЯ
  • ЖИЗНЬ
  • НЕМНОГО ТЕОРИИ
  • ОБО МНЕ
  • КОНТАКТЫ
11.09.2019 Немного теории

Книжный шкаф: Ретро о разработке ПО

Software development. Data Digital Programs System Technology Concept.

Книга Джозефа Фокса «Программное обеспечение и его разработка», изданная в СССР в 1985 году полна множества цитат. Работая в авиации я часто вспоминал одну: «Общеизвестно, что вес проектной документации на Боинг-747 превышал вес самого самолета!». Автор системно изложил принципы гибкой разработки и его книга все еще жива и актуальна.

fox_software_and_its_development

Джозеф Фокс — руководитель проектов в IBM. Хотя книга была издана в 1982 году (в СССР — в 1985), она представляет собой не только исторический, но и практический интерес. Прежде всего, потому что автору удалось оторваться от конкретных аппаратных платформ, изложив свой многолетний опыт в форме попыток обобщения и конкретных примеров из практики не только в отдельных проектах, но и в масштабах компании. Автор учитывает ментальную модель реальных проектов (рис.ниже).

Ментальные модели

В этой книге сформулированы основные принципы не только разработки ПО, но и управления программным проектом. Они сформулированы тогда, когда еще не было икон типа PMBOK, ITIL, Agile и прочих. Недавно перечитал эту книгу и с удовольствием обнаружил, что основные положения книги фундаментальны и, без сомнения, оказали влияние на то, что мы сейчас называем гибкими методологиями разработки. Несколько цитат и иллюстраций из этой книги для тех, кто хочет почитать этот бестселлер.

Факты о программном обеспечении

Развитие программного обеспечения происходит одновременно в двух противоположных направлениях.

Жизнь любой программы обычно проходит три стадии, и в своей работе разработчики и проектировщики должны принимать во внимание все эти три стадии. Обычно рассматриваются только стадия разработки и стадия использования. Однако, уже на ранних этапах разработки нужно иметь в виду и стадию поддержки (сопровождения) или продолжающейся разработки.

Разработка программного обеспечения проходит следующие шесть этапов: определение требований, проектирование, написание команд, компоновка, тестирование и документирование.

Разработка больших систем программного обеспечения часто зависит от наличной аппаратуры.

Любой процесс может быть выражен несколькими различными «правильными» последовательностями команд.

Программное обеспечение носит абстрактный характер, что усложняет процесс его разработки.

Основным инструментом создания нового программного обеспечения являются вычислительная машина и ее программное обеспечение.

При разработке программного обеспечения основную трудность обычно представляет собой не та функция, которую должна выполнять данная система, а методика взаимодействия с пользователем, которой должна подчиняться эта система.

Некоторые виды программного обеспечения можно разрабатывать теми же методами, что и аппаратуру, другие же так разрабатывать нельзя.

Правильное программное обеспечение не подвержено никаким сбоям. Термин «поддержка» по отношению к программному обеспечению является, следовательно, неправильным.

Разработка больших программ – это весьма многогранная деятельность, отнюдь не связанная только с работой на вычислительной машине.

Большая часть программного обеспечения никогда не может быть отлажено до конца, даже после нескольких лет тестирования и использования.

Разработка программного обеспечения часто весьма трудоемкий и дорогостоящий процесс.

Полный цикл

Давая поэтапный список процессов, как это сделано на рис. 5.2, мы должны понимать, что реально он никогда не бывает таким простым и понятным.

ris_5.2

Очевидно, что только простейшие задачи проходят все шаги без каких-либо итераций, т.е. постоянных возвратов на более ранние этапы процесса. При проектировании кто-то может обнаружить, что следование какому-либо требованию может привести к двукратному увеличению стоимости разработки подсистемы. Разработчик должен пересмотреть и переоценить требования. Этот процесс продолжается непрерывно. Группе проектировщиков передается новая информация, проект должен быть пересмотрен. (См. рис.5.3.).

ris_5.3-5.4

В конце 60-х гг. в Гейтсбурге в отделении фирмы IBM мы создали специальный курс лекций под названием КУПП – курс управления программным проектом. Этот курс был предназначен для того, чтобы молодые руководители работ лучше понимали, на что обращать особое внимание, как привести проект к оптимальному результату (см. рис.5.4). Материал мало менялся с годами, я здесь привожу две диаграммы распределения людских ресурсов, использовавшихся на протяжении 5 лет. Рис. 5.4 был в конце концов признан неправильным. Для больших проектов проектирование не кончается никогда. Диаграмма была изменена таким образом, чтобы отразить продолжающееся в течение всего этапа разработки проектирование (см. рис. 5.5).

ris_5.5

Нам никогда бы не пришло в голову, что деятельность по определению требований, как и проектирование, могла бы продолжаться в течение всего хода работ по разработке. Как показано на рисунках, число занятых людей резко уменьшается после сдачи системы. Такого не случается только с системами V.

Причина заключается в том, что «закон обязательной даты» — необходимость сдать работу в срок, приводит к временному откладыванию реализации многих обещанных и запланированных функций. Их приходится вводить в действие после «сдачи». Как мы увидим, распределение времени по различным этапам зависит от множества факторов. Однако размер программной системы, зависящей только от того, какие функции она должны выполнять, является одним из основных определяющих факторов. Время, затрачиваемое на написание программ, сокращается по отношению ко времени и усилиям, затраченным на весь проект в целом, по мере увеличения проекта. Эти ошибочные диаграммы укомплектования персоналом очень живучи. Диаграмма, изображенная на рис. 5.6, появилась в ведущем журнале в 1979 г.

ris_5.6-5.7

Для маленьких программ в хорошо известных уже полностью автоматизированных областях эта диаграмма вполне пригодна. Но она совершенно не подходит большим программным системам и даже системам небольшого размера, относящимся к области управления процессами! Определение требований и проектирование продолжается гораздо дольше. Рис. 5.7, созданный Э.Ферентино, полнее соответствует реальной ситуации, или, лучше сказать, ситуации, которая должна возникать при разработке крупномасштабного программного обеспечения.

Еще раз взгляните на модель, использованную нами в отделении федеральных систем фирмы IBM в начале 70-х гг. (рис. 5.5). Процесс проектирования, как мы уже видели, отражен вполне удовлетворительно, но совершенно неправильно представлена роль тестирования. Показано, что тестирование начинается только вместе с кодированием.

Как можно видеть из правильной модели, тестирование должно начинаться вскоре после «первого прохода» процесса определения требований.

___________________________________________________

И в завершении — о прогнозах. Как оказалось, в 1982 году прогнозы мало отличались от даваемых в 2019.

Первый: Программное обеспечение станет решающим фактором, влияющих на качество продаваемых крупных программных систем.

Второй: Недостаточное число программистов… которое существует сейчас, со временем еще больше усугубится.

Третий: Вычислительная техника станет настолько дешевой, что появятся системные конструкторы. Они будут связывать квазиуниверсальные программы, создавая «обрабатывающие системы.

Четвертый: Разрыв между стремительным развитием микроэлектроники и инерцией разработки программного обеспечения станет наиболее известным примером неодолимой силы и недвижимого объекта. В результате разработка программного обеспечения достигнет небывалых высот… произойдет подлинная революция.

IBM PMBOK КНИГИ

Статьи по этой теме:

  • оренбург_0230
    Книжный шкаф: Правила мозга
  • titul
    Виктор Николенко: Подвиг инженера

Комментарии: нет ответов

Присоединяйтесь: Оставьте ваш комментарий Cancel Reply

(не будет отображаться другим)

ПОИСК

АРХИВ

  • Февраль 2021 (8)
  • Январь 2021 (8)
  • Декабрь 2020 (10)
  • Ноябрь 2020 (6)
  • Октябрь 2020 (8)
  • Сентябрь 2020 (8)
  • Август 2020 (13)
  • Июль 2020 (12)
  • Июнь 2020 (10)
  • Май 2020 (9)
  • Апрель 2020 (10)
  • Март 2020 (5)
  • Февраль 2020 (8)
  • Январь 2020 (9)
  • Декабрь 2019 (12)
  • Ноябрь 2019 (12)
  • Октябрь 2019 (14)
  • Сентябрь 2019 (14)
  • Август 2019 (14)
  • Июль 2019 (16)
  • Июнь 2019 (20)
  • Май 2019 (20)
  • Апрель 2019 (20)
  • Март 2019 (11)
  • Февраль 2019 (18)
  • Январь 2019 (15)
  • Декабрь 2018 (19)
  • Ноябрь 2018 (6)
  • Май 2018 (2)
  • Январь 2015 (1)
  • Ноябрь 2014 (1)

КАЛЕНДАРЬ

Февраль 2021
Пн Вт Ср Чт Пт Сб Вс
« Янв    
1234567
891011121314
15161718192021
22232425262728

ПОСЛЕДНИЕ ЗАПИСИ

  • titul2
    Красногорск: Музей техники или снова в СССР Четверг, 25, Фев
  • титул
    Искусство презентации: Ошибки и лайфхаки Четверг, 25, Фев
  • титул
    Малайзия: Управление проектами в госорганах Четверг, 18, Фев

ОБЛАКО ТЕГОВ

IBM MIND-MAP PMBOK PMI АВТО АЛЬПИНИЗМ АНАПА АРКТИКА БЕГ ВЕЛО ВИРУС ВОИНЫ ВОЙНА ДОРОЖНАЯ КАРТА ЕКБ ЖИВОПИСЬ КАРЕЛИЯ КИНО КНИГИ КОМАНДА КОНЮХОВ КРАСНОДАР ЛИДЕР ЛОДКА МОСКВА ПОДВИГ ПОДМОСКВА ПОЭТ ПРОЕКТ РИСК РОССИЯ СВЯТОЙ СКРАМ СОБАКА СПБ СПОРТ СССР СТРОЙКА ТАТАРСТАН ТЕАТР ТРЕНИНГ ТРИАТЛОН УРОКИ ФУТБОЛ ХРАМ

Обо мне

Здравствуйте! Меня зовут Евгений Пикулев. На работе я занимаюсь управлением сложными проектами. А этот сайт посвящен управлению персональными проектами (своими и не только), которые я называю подвигами.

Последние записи

  • titul2
    Красногорск: Музей техники или снова в СССР
  • титул
    Искусство презентации: Ошибки и лайфхаки
  • титул
    Малайзия: Управление проектами в госорганах

Из Twitter

Instagram

Please check the widget data
  • ГЛАВНАЯ
  • СПОРТ
  • ПУТЕШЕСТВИЯ
  • ЖИЗНЬ
  • НЕМНОГО ТЕОРИИ
  • ОБО МНЕ
  • КОНТАКТЫ
Евгений