|
p align="left">Во многих отношениях управление ИТ деятельностью требует больше административных, чем технических навыков. Для того чтобы достичь совершенства в эксплуатации системы, руководство должно научиться отделять расходы на поддержание системы от инвестиций в новое аппаратно-программное обеспечение. Новые инвестиции следует оценивать как решения по капиталовложениям, а эксплуатацию - исходя из поставленных в области обслуживания и затрат целей. Отдел информационных технологий хорошо разбирается в бизнесе, а бизнес-подразделения - в программных системах и информационных технологиях Достаточно распространенным явлением бывает наличие в организации руководящего комитета и специальных процедур для интеграции информационных технологий с основными направлениями бизнеса. Но это не может заменить участие генерального директора и других руководителей в стратегии развития информационной системы предприятия. Опыт показывает, что высшее руководство процветающих компаний инициирует оживленные дискуссии об информационных технологиях среди руководителей основных направлений деятельности и технических руководителей. Важным результатом таких дискуссий является привлечение к информационным технологиям интереса тех людей, которые могут устранить разрыв между технологиями и бизнесом. Привлечь таких людей нелегко, но еще труднее порой бывает их удержать. В большинстве успешно использующих информационные технологии компаний менеджер по информатизации в первую очередь является бизнес-руководителем и только во вторую - техническим специалистом. Возможно, кажется очевидным, что менеджер по информатизации должен входить в круг высшего руководства. Однако во многих компаниях он подчиняется руководителю финансового отдела; в результате увеличивается вероятность того, что к информационным технологиям будут относиться не более, чем как к затратам, которые необходимо контролировать. В компаниях, успешно использующих информационные технологии, информационно-технический отдел тесно интегрирован с остальными подразделениями. Его сотрудники размещаются бок о бок с остальным персоналом, и работа над всеми усовершенствованиями осуществляется совместно. Основные отделы и отдел информационных технологий должны совместно работать над принятием решений в области информатизации, чтобы обеспечить их обоснованность, необходимую для успеха. Для этого сотрудники компании должны иметь базовые знания в области информационных технологий, а технические специалисты - знания об основной деятельности организации, однако большая часть такого обучения происходит в ходе совместной выработки решений. Поэтому ключевым моментом является привлечение основного персонала на стадии разработки и внедрения проекта. В организациях, успешно использующих информационные технологии, структура технических отделов проста. Небольшое число сотрудников занимается поддержкой, а основной упор сделан на производительность. Эти организации понимают, что они не могут держать специалистов по всем направлениям, которые им могут понадобиться, и имеют только тех, потребность в которых особенно значительна или важна, а за другими услугами обращаются к внешним организациям. Они следят за тем, чтобы поддерживать у сотрудников навыки по ключевым бизнес-процессам. 3. Виды программного обеспечения: общесистемное, сетевое и прикладное3.1 Общесистемное программное обеспечениеОбщесистемное ПО обеспечивает управление вычислительным процессом; вводом, выводом и обработкой данных и команд пользователя. В его состав входят:операционные системыинструментально-технологические средства разработки и языковые процессорыСУБДCASE-системы и др.3.2 Сетевое программное обеспечениеСетевое ПО обеспечивает взаимодействие локально или глобально распределенных компонентов компьютерной системы.3.3 Прикладное программное обеспечениеПрикладное ПО обеспечивает решение конкретных задач пользователей и включает:3.3.1 Независимые программы3.3.2 Библиотеки подпрограмм3.3.3 Языковые процессоры для решения общих прикладных задач3.3.4 Многофункциональные программы для решения ограниченного класса задач, различными алгоритмами3.3.5 Пакеты прикладных программОбеспечивают:решение класса задачвходной языкинформационная модель предметной областиприкладные программ - модулиуправление вычислительным процессомсистемная и функциональная компонентыППП могут быть:методо-ориентированные ПППпроблемно-ориентированные ПППмодельно-ориентированные ПППобъектно-ориентированные ППП3.3.6. Программные системы (комплексы)4. Типы программного обеспеченияТип ПО может быть следующим:Разрабатывающееся вновь;Имеющееся в готовом виде;Программно-аппаратное (встроенное);Автономное.Знову розроблювальне. Таке ПЗ вступає в процес Розробки із самого початку і для нього повинні бути розглянуті усі вимоги цього процесу.Наявне в готовому вигляді.Готове ПЗ може використовуватися одним з наступних способів.Використання ПЗ точно в тому виді як воно є. Таке ПЗ вже спроектоване, закодоване і тестоване. Додаткове тестування може знадобитися з урахуванням таких чинників як критичність і історія використання. Це ПЗ входить у процес Розробки не пізніше кваліфікаційного тестування. Повний процес Розробки може виявитися зайвим. Повинні бути оцінені працездатність, документація, права власності і подальшої підтримки ПЗ.Використання готового ПЗ без модифікації, але зі зміною параметрів конфігурації додатка (наприклад, формату дати, валюти або розміру сторінки). Таке ПЗ входить у процес Розробки, коли компоненти ПЗ тестуються й інтегруються після відповідної зміни параметрів. Повний процес Розробки може виявитися зайвим. Повинні бути оцінені працездатність, документація, права власності і подальшої підтримки ПЗ.Модифікація готового ПЗ (наприклад, зміна формату звітів або доробка документації). У процес Розробки входить на етапі кодування і тестування ПЗ. Повинні бути оцінені працездатність, документація, права власності і подальшої підтримки ПЗ.Вмонтоване ПЗ.ПЗ або програмно-апаратні засоби вбудовуються в систему. Оскільки таке ПЗ є частиною великої системи, усі дії рівня системи в процесі Розробки повинні бути враховані. Якщо ПЗ або програмно-апаратні засоби не вимагають подальшої модифікації, то треба старанно досліджувати питання про обсяг необхідної документації.Автономне ПЗ. Оскільки таке ПЗ не є частиною системи, усі дії рівня системи з процесу Розробки можуть бути виключені. Необхідно розглянути потреби в документації, особливо для супроводу системи.Великий проект, що включає десятки або сотні людей, подає значні труднощі для керування Великий проект або проект із багатьма субпідрядниками вимагає проведення ретельного контролю. Такий контроль досягається використанням процесів спільної оцінки, аудита, верифікації, валідації і забезпечення якості. Для невеликих проектів усі ці типи контролю можуть виявитися зайвими.Чим більше система залежить від того чи правильно працює ПЗ і чи закінчена його розробка вчасно, тим більше гласності і контролю необхідно. З іншої сторони надмірний контроль у тих випадках коли в ньому ні необхідності, є неефективним.Розробка ПЗ може бути сполучена з технічним ризиком. Якщо використовується незріла технологія розробки, якщо розроблювальне ПЗ не має прецедентів або дуже складне, якщо до ПЗ подаються специфічні вимоги по безпеці, захищеності, тоді потрібні дуже ретельні специфікації, проектування, тестування й оцінка. У цьому випадку можуть бути важливі незалежна верифікація і валідація.5. Общие требования к программным системам5.1. Максимум удобств пользователяобщение на языке, близком к естественномунаглядное представление данных, возможность редактированиябыстрота ознакомления с работой, легкость осваиванияотсутствие жестких ограничений на структуру и объем исходных данныхдоступность общениявозможность адаптации к требованиям пользователяполнота и доступность программной документации5.2. Адаптируемость ПО - приспособляемость к функционированию в различных условиях5.3. Гибкость - возможность легко вводить изменения, дополнения и исправления в ПО5.4. Мобильность - переносимость на различные вычислительные платформы и операционные среды5.5. Масштабируемость, расширяемость и модифицируемость5.6. Эффективность работы6. Принципы построения программного обеспечения6.1. Модульность ПО - проведение декомпозиции алгоритмов и программ на модули с целью выделения общих типовых функций и компонентов.6.2. Интеллектуальность ПО - наличие знаний о предметной области и умение использовать их при решении задач.6.3. Черный ящик - ПО должно скрывать от пользователей сложный механизм организации и взаимодействия программ.6.4. Умолчание - умолчание однажды заданных параметров, если они имеют смысл в других аналогичных задачах.7. Критические вопросы процесса разработки программного обеспеченияКачествоЛюдям свойственно ошибаться. Каждая ошибка, когда она найдена, является сюрпризом, исправление которого или дорого стоит, или выбивает из ритма разработки.Если контроль качества в организации ослаблен, требуется запланировать в самом процессе разработки ряд инспекций проектной документации и инспекций кодов, разрабатывая планы качества, систему измерений, программу тестирования, т.е. более интенсивную работу по Подтверждению качества программного обеспечения (Software Quality Assurance).Продуктивность технологии.Очень часто при новых разработках не ясно, как разработать алгоритм, достичь целей разработки или ограничить функциональность. Поскольку позднее "латание дырок" может быть безуспешным или трудоемким, или приводит к срывам темпов разработки, разумно в процессе предусмотреть заранее эксперименты для получения нужных сведений. Последующая разработка будет развиваться более упорядоченным и эффективным образом.Нестабильность (изменчивость) требований.Для того, чтобы спроектировать, построить и оттестировать требуемую программу нужно, чтобы ее функции, интерфейсы и системный базис должны были стабильны. Поскольку возможны изменения во время разработки, эти изменения должны быть временно заморожены. В планируемые периоды могут быть рассмотрены пакеты изменений и, соответственно, подработана программа. Если таким путем не управлять изменениями, процесс разработки становится нестабильным.Существуют три основных типа изменений требований.Неизвестные требования. Пользователь думает, что он знает, чего хочет, но во время начального использования открывает для себя, что реальные потребности иные, нежели он думал. Это нормальное явление при автоматизации человеческой деятельности. С ним можно бороться или ранним прототипированием или планированием множества релизов, которые постепенно разрабатываются, используются, оцениваются и наращиваются до уровня следующего релиза.Нестабильные требования. В то время как общие требования известны, частности продолжают "плавать". В бортовых системах, для которых hardware и software часто проектируется одновременно, изменения в hardware приводят к изменению требований к программному обеспечению. Изменение hardware, диктуемое программными изменениями, является нонсенсом, аналогичным требованиям поменять фундамент при постройке здания. Тем не менее, с данным явлением можно бороться путем предвидения нестабильностей и изоляции их.Непонятные требования. Даже если требования известны и стабильны, разработчики часто не понимают их настолько детально, чтобы сделать удовлетворительный программный продукт. Типичным примером является пользовательский интерфейс. Здесь полезно тестирование пользователем прототипов интерфейса или ранних версий пользовательской документации.Сложность.Программы приложений часто легче разработать, чем системы, поскольку их платформа и окружение более стабильны. Это не означает, что разработка приложений требует меньшей квалификации. Это означает, что имеется меньше источников для одновременных изменений.Например, во время разработки новой операционной системы все ее элементы находятся в состоянии постоянных изменений: управляющая программа, компиляторы, система управления данными и т.д., в том числе и архитектура компьютера.Для того, чтобы достичь хотя бы какого-то результата, требуется обеспечить хотя бы промежуточную стабильность. Обычно стабильность достигается путем использования приемов модульного программирования, в частности, выделения модулей и определения интерфейсов. Далее управление изменениями позволяет для каждого модуля иметь осязаемые и стабильные требования на определенном интервале между изменениями.
Страницы: 1, 2, 3
|
