Программное обеспечение и его разработка
Шрифт:
Таблица 6.1. Программы, выполняемые для печати платежных ведомостей
| Программа | Размер | Автор |
|---|---|---|
| Программа выписки чеков | 8402 Стп [34] | Джонсон А. Д., отдел 4 |
| Печать квитанций | 462 Стп | Шварц М. Д., отдел 5 |
| Программа | 892 Стп | Дэниэлс Р. М., отдел 11 |
| Удержания
| 44 °Стп | Абадан Д. Р., отдел 442 |
| Расчет даты | 414 Стп | Уитерс М. Р., уволился |
| Отчет по налогам штата | 317 Стп | Джонсон А. Д., отдел 4 |
| Расчет профсоюзных взносов | 219 Стп | Трэверс Д., отдел 41 |
| Печать профсоюзных взносов | 44 Стп | Трэверс Д., отдел 41 |
34
СТП — строки текста программы на исходном языке.
Мы достигли достаточно точного и подробного видения проблемы. Ограничимся рассмотрением уровня 6, поскольку он более удобен для записи и чтения, хотя на практике лучше работать с более подробным уровнем 7. Мы хотим отметить все, что выполняется во время использования. Нам нужно для этого перечислить все программы, их размеры и их авторов. Результаты сведены в табл. 6.1.
Теперь для приведения такой системы в порядок, для ее доводки нам нужны люди (системные аналитики и программисты), которые понимают, что должна делать каждая программа, как эти программы взаимодействуют между собой, каким образом все выполняемые машиной программы должны составить единую систему.
Мы не ждем, что А. Д. Джонсон, автор программы выписки чеков, будет понимать, каким образом СУБД выполняет возложенные на нее обязанности. Мы можем лишь требовать от него, чтобы он знал, что может делать СУБД, как обратиться к ней с требованием выполнить работу, как проверить, что работа выполнена.
То же самое относится и ко всем другим программам. Небольшая группа старших аналитиков должна иметь возможность просмотреть все данные и с помощью авторов и поставщиков программы найти ошибку или ошибки. Ошибка может находиться в этой подсистеме на шестом уровне, но может быть и в любой другой подсистеме процедур, людей и т. д. Конечно, ошибка может быть и в способе взаимодействия какой-нибудь подсистемы с одной или несколькими другими.
Все это сложно, очень сложно, но совершенно необходимо. За несколько часов мы можем «сделать» такую ведомость, что потом ее не удастся привести в нормальное состояние и за целую неделю, даже после стократного увеличения числа людей, занятых этой работой. Мы можем это же проделать и с системой управления авиалиниями, и с другими работами.
Зачем наряду с программными системами собственного производства мы используем еще и покупные? Такой подход повышает эффективность, он более экономичен, к тому же продаются уже готовые к использованию программы.
Система состоит из множества подсистем — одна из них обычно есть вычислительная система, например система наземного контроля. Но и во всех других подсистемах тоже могут быть и вычислительные машины, и программное обеспечение! (См. рис. 6.6.) Вычислительные машины и программное обеспечение могут входить в состав любой подсистемы как ее часть. Спутниковая подсистема может иметь в своем составе сразу несколько вычислительных машин, на каждой из которых имеется свой комплект программного обеспечения (см. рис. 6.7).
Один простой вопрос может сбить с толку всю организацию: «Кто должен отвечать за программное обеспечение?». Разумеется, для программного обеспечения наземного контроля необходим компетентный, очень квалифицированный руководитель разработки программного обеспечения проекта. Должен ли он отвечать и за то обеспечение, которое работает на самом спутнике? Возможно. А возможно, и нет.
Должен ли руководитель отдельной бортовой спутниковой подсистемы заниматься и вопросами программного обеспечения? Вероятно, нет. На эти весьма важные вопросы нет простого ответа.
На некоторое время постараемся забыть об аппаратуре и обратимся только к программному обеспечению. Но вот удастся ли нам отделить программное обеспечение от аппаратного? Хотя это подчас и затруднительно, но такое выделение возможно. Особое значение оно приобретает при определении границ работ различных организаций и ревизионных групп.
Рассмотрим для примера банковскую систему с диалоговыми терминалами, служащими для проведения банковских операций. Начать мы можем с рассмотрения ее подсистем. Чтобы не разбрасываться, мы будем принимать во внимание только три подсистемы: подсистему связи, аппаратную подсистему обработки данных и подсистему программного обеспечения, которая в свою очередь входит в подсистему обработки данных. Нам нужно определить, откуда возникает ограничение на количество подключаемых терминалов, которых может быть, скажем, не более 12.
Изучая подсистему связи, мы можем обнаружить, что линии, по которым происходит передача данных на обработку или после этой обработки, имеют ограниченную пропускную способность в 12 сообщений, что и является ограничивающим фактором. Если это действительно так, мы можем считать, что узкое место найдено. Но предположим, что линии связи способны передавать любой мыслимый объем информации.
Обратимся теперь к вычислительной машине. Может оказаться и так, что невозможность управления тринадцатым терминалом связана с ограниченной вычислительной мощностью машины, которая не может гарантировать обслуживание линий без потерь информации в периоды пиковой нагрузки. Поскольку этот вопрос упирается в деньги, он очень важен. Узким местом при этом становится мощность процессора.
Допустим теперь, что и линии связи, и процессор вполне способны управлять более чем двенадцатью терминалами. Программисты могли написать программы так, что они работают с 12 и только 12 терминалами, тем самым просто не существует программы, контактирующей с тринадцатым терминалом, даже несмотря на то что вся аппаратура имеет полную возможность для этого. Если узкое место найдено именно здесь, программистов можно попросить вникнуть в суть дела и модифицировать программы так, чтобы можно было работать с дополнительными терминалами. Это достаточно просто и не должно отнять много времени, конечно, в том случае, если программист, выполнявший первичную разработку, оставил после себя документацию на программу, все еще работает в этом банке и не занят в других критических разработках.