Системный анализ и проектирование - Краткое руководство

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

• Системный анализ
• Системный дизайн

Системный анализ

Это процесс сбора и интерпретации фактов, выявления проблем и разложения системы на ее компоненты.

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

Анализ указывает what the system should do.

Системный дизайн

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

Системный дизайн фокусируется на how to accomplish the objective of the system.

Системный анализ и проектирование (SAD) в основном фокусируется на -

• Systems
• Processes
• Technology

Что такое система?

Слово «система» происходит от греческого слова «система», которое означает организованные отношения между любым набором компонентов для достижения некоторой общей причины или цели.

Система - это «упорядоченная группа взаимозависимых компонентов, связанных вместе в соответствии с планом достижения определенной цели».

Ограничения системы

Система должна иметь три основных ограничения:

• Система должна иметь structure and behavior который предназначен для достижения заранее определенной цели.

• Interconnectivity и interdependence должен существовать среди компонентов системы.

• В objectives of the organization есть higher priority чем цели его подсистем.

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

Свойства системы

Система имеет следующие свойства -

Организация

Организация подразумевает структуру и порядок. Именно расположение компонентов помогает достичь заранее поставленных целей.

Взаимодействие

Это определяется тем, как компоненты взаимодействуют друг с другом.

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

Взаимозависимость

Взаимозависимость означает, как компоненты системы зависят друг от друга. Для правильного функционирования компоненты скоординированы и связаны друг с другом в соответствии с заданным планом. Выход одной подсистемы требуется другой подсистеме в качестве входа.

Интеграция

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

Центральная цель

Цель системы должна быть центральной. Это может быть реальным или заявленным. Организации нередко ставят одну цель и действуют для ее достижения.

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

Элементы системы

На следующей схеме показаны элементы системы -

Выходы и входы

• Основная цель системы - получить результат, полезный для пользователя.

• Входы - это информация, которая поступает в систему для обработки.

• Выход - это результат обработки.

Процессор (ы)

• Процессор - это элемент системы, который включает фактическое преобразование ввода в вывод.

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

• По мере изменения выходных характеристик изменяется и обработка. В некоторых случаях ввод также изменяется, чтобы позволить процессору обрабатывать преобразование.

Контроль

• Элемент управления направляет систему.

• Это подсистема принятия решений, которая контролирует последовательность действий, управляющих вводом, обработкой и выводом.

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

Обратная связь

• Обратная связь обеспечивает управление в динамической системе.

• Положительная обратная связь по своей природе является рутинной и способствует повышению производительности системы.

• Отрицательная обратная связь носит информационный характер, предоставляя контроллеру информацию для действий.

Окружающая обстановка

• Среда - это «надсистема», в которой работает организация.

• Это источник внешних элементов, которые наносят удар по системе.

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

Границы и интерфейс

• Система должна определяться своими границами. Границы - это пределы, которые определяют его компоненты, процессы и взаимосвязь при взаимодействии с другой системой.

• Каждая система имеет границы, определяющие сферу ее влияния и контроля.

• Знание границ данной системы имеет решающее значение для определения характера ее взаимодействия с другими системами для успешного проектирования.

Типы систем

Системы можно разделить на следующие типы -

Физические или абстрактные системы

• Физические системы - это материальные сущности. Мы можем их потрогать и почувствовать.

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

• Абстрактные системы - это нефизические сущности или концептуальные объекты, которые могут быть формулами, представлением или моделью реальной системы.

Открытые или закрытые системы

• Открытая система должна взаимодействовать со своим окружением. Он получает входные данные и доставляет выходы за пределы системы. Например, информационная система, которая должна адаптироваться к меняющимся условиям окружающей среды.

• Закрытая система не взаимодействует со своим окружением. Он изолирован от воздействия окружающей среды. Полностью закрытая система в реальности встречается редко.

Адаптивная и неадаптивная система

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

• Неадаптивная система - это система, которая не реагирует на окружающую среду. Например, машины.

Постоянная или временная система

• Постоянная система сохраняется долгое время. Например, бизнес-политика.

• Временные системы изготавливаются на указанное время, после чего их сносят. Например, DJ-система настраивается для программы, и она разбирается после программы.

Натуральная и искусственная система

• Природные системы созданы самой природой. Например, Солнечная система, сезонная система.

• Производственная система - это система, созданная руками человека. Например, ракеты, дамбы, поезда.

Детерминированная или вероятностная система

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

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

Социальная, человеко-машинная, машинная система

• Социальная система состоит из людей. Например, социальные клубы, общества.

• В системе человек-машина и человек, и машины задействованы для выполнения определенной задачи. Например, компьютерное программирование.

• В Машинной системе пренебрегают вмешательством человека. Все задачи выполняет машина. Например, автономный робот.

Искусственные информационные системы

• Это взаимосвязанный набор информационных ресурсов для управления данными конкретной организации в рамках прямого управленческого контроля (DMC).

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

  Искусственные информационные системы делятся на три типа -

• Formal Information System - Он основан на потоке информации в виде памяток, инструкций и т. Д. От верхнего уровня к нижнему уровню управления.

• Informal Information System - Это система, ориентированная на сотрудников, которая решает повседневные рабочие проблемы.

• Computer Based System- Эта система напрямую зависит от компьютера для управления бизнес-приложениями. Например, автоматическая библиотечная система, система бронирования железнодорожных билетов, банковская система и т. Д.

Системные модели

Схематические модели

• Схематическая модель - это двухмерная диаграмма, на которой показаны элементы системы и их связи.

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

Модели систем потока

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

• Например, метод оценки и анализа программ (PERT) используется для абстрагирования реальной системы в виде модели.

Статические модели системы

• Они представляют собой одну пару отношений, таких как действие – время или стоимость – количество .

• Например, диаграмма Ганта дает статичную картину зависимости активности от времени.

Модели динамических систем

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

• Он показывает текущий, постоянно меняющийся статус системы. Он состоит из -

  • Входы, которые входят в систему

  • Процессор, через который происходит преобразование

  • Программа (ы), необходимая для обработки

  • Выходные данные, полученные в результате обработки.

Категории информации

Есть три категории информации, относящиеся к уровням управления и решениям, принимаемым менеджерами.

Стратегическая информация

• Эта информация требуется высшему руководству для разработки политики долгосрочного планирования на следующие несколько лет. Например, тенденции доходов, финансовых вложений, людских ресурсов и роста населения.

• Этот тип информации достигается с помощью системы поддержки принятия решений (DSS).

Управленческая информация

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

• Это достигается с помощью информационных систем управления (MIS).

Оперативная информация

• Этот тип информации требуется низкому руководству для ежедневного и краткосрочного планирования, чтобы обеспечить выполнение повседневной операционной деятельности. Например, ведение учета посещаемости сотрудников, просроченных заказов на покупку и текущих запасов.

• Это достигается с помощью систем обработки данных (DPS).

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

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

SDLC используется аналитиками для разработки информационной системы. SDLC включает в себя следующие действия -

• requirements
• design
• implementation
• testing
• deployment
• operations
• maintenance

Фазы SDLC

Жизненный цикл разработки систем - это систематический подход, который четко разбивает работу на этапы, необходимые для внедрения новой или измененной информационной системы.

Технико-экономическое обоснование или планирование

• Определите проблему и масштаб существующей системы.

• Обзор новой системы и определение ее целей.

• Подтвердите осуществимость проекта и составьте график проекта.

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

• В конце этого этапа создается технико-экономический отчет для всего проекта.

Анализ и спецификация

• Соберите, проанализируйте и подтвердите информацию.

• Определите требования и прототипы для новой системы.

• Оцените альтернативы и определите приоритеты требований.

• Изучите информационные потребности конечного пользователя и улучшите цель системы.

• В конце этого этапа подготавливается документ со спецификацией требований к программному обеспечению (SRS), в котором указываются требования к программному обеспечению, оборудованию, функциям и сети.

Системный дизайн

• Включает дизайн приложений, сети, баз данных, пользовательских интерфейсов и системных интерфейсов.

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

• Составьте план действий на случай непредвиденных обстоятельств, обучения, обслуживания и эксплуатации.

• Просмотрите предложенный дизайн. Убедитесь, что окончательный проект должен соответствовать требованиям, изложенным в документе SRS.

• Наконец, подготовьте проектный документ, который будет использоваться на следующих этапах.

Реализация

• Внедрите дизайн в исходный код посредством кодирования.

• Объедините все модули вместе в обучающую среду, которая выявляет ошибки и дефекты.

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

• Интегрируйте информационную систему в ее среду и установите новую систему.

Обслуживание / Поддержка

• Включите все действия, такие как поддержка по телефону или физическая поддержка на месте для пользователей, которые необходимы после установки системы.

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

• Это также включает обработку остаточных ошибок и решение любых проблем, которые могут существовать в системе даже после фазы тестирования.

• Обслуживание и поддержка могут потребоваться в течение длительного времени для больших систем и в течение короткого времени для небольших систем.

Жизненный цикл системного анализа и проектирования

На следующей диаграмме показан полный жизненный цикл системы на этапе анализа и проектирования.

Роль системного аналитика

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

Он стремится согласовать цели информационной системы с целью организации.

Основные роли

• Определение и понимание требований пользователя с помощью различных методов поиска фактов.

• Приоритезация требований путем получения согласия пользователей.

• Сбор фактов или информации и получение мнений пользователей.

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

• Предлагает множество гибких альтернативных решений, выбирает лучшее решение и дает количественную оценку затрат и выгод.

• Составьте определенные спецификации, понятные пользователям и программистам, в точной и подробной форме.

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

• Планируйте периодичность оценки после того, как она использовалась в течение некоторого времени, и при необходимости измените систему.

Атрибуты системного аналитика

На следующем рисунке показаны атрибуты, которыми должен обладать системный аналитик.

Навыки межличностного общения

• Интерфейс с пользователями и программистом.
• Содействуйте группам и возглавляйте небольшие команды.
• Управление ожиданиями.
• Хорошее понимание, коммуникабельность, навыки продаж и обучения.
• Мотиватор, уверенный в решении запросов.

Аналитические навыки

• Системное изучение и организационные знания
• Выявление проблем, анализ проблем и решение проблем
• Здравый смысл
• Возможность доступа к компромиссу
• Любопытство узнать о новой организации

Навыки управления

• Изучите жаргон и практику пользователей.
• Управление ресурсами и проектами.
• Управление изменениями и рисками.
• Тщательно разбирайтесь в функциях управления.

Технические навыки

• Знание компьютеров и программного обеспечения.
• Будьте в курсе современных разработок.
• Знать инструменты проектирования систем.
• Глубокие знания о новых технологиях.

Что такое определение требований?

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

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

Основные мероприятия по определению требований

Требования Предвидение

• Он прогнозирует характеристики системы на основе предыдущего опыта, который включает определенные проблемы или функции и требования для новой системы.

• Это может привести к анализу областей, которые иначе остались бы незамеченными неопытным аналитиком. Но если будут взяты ярлыки и введен предвзятость при проведении расследования, то требование «Предвкушение» может оказаться недооцененным.

Исследование требований

• Он изучает текущую систему и документирует ее особенности для дальнейшего анализа.

• Он лежит в основе системного анализа, когда аналитик документирует и описывает функции системы с помощью методов установления фактов, создания прототипов и компьютерных инструментов.

Требования Технические характеристики

• Он включает анализ данных, которые определяют спецификацию требований, описание функций для новой системы и определение требований к информации, которые будут предоставлены.

• Он включает анализ фактических данных, определение основных требований и выбор стратегий выполнения требований.

Методы сбора информации

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

Идеальный документ SRS должен -

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

Существуют различные методы сбора информации -

Интервью

Системный аналитик собирает информацию от отдельных лиц или групп путем интервью. Аналитик может быть формальным, сторонником закона, играть в политику или быть неформальным; поскольку успех интервью зависит от навыков аналитика как интервьюера.

Это можно сделать двумя способами -

• Unstructured Interview - Системный аналитик проводит сессию вопросов и ответов, чтобы получить основную информацию о системе.

• Structured Interview - В нем есть стандартные вопросы, на которые пользователь должен ответить в закрытом (объективном) или открытом (описательном) формате.

Advantages of Interviewing

• Этот метод часто является лучшим источником сбора качественной информации.

• Это полезно для тех, кто не может эффективно общаться в письменной форме или у которых может не быть времени на заполнение анкеты.

• Информацию можно легко проверить и сразу же перепроверить.

• Он может справиться со сложными предметами.

• Узнать ключевую проблему легко, изучив мнения.

• Он заполняет пробелы в недоразумениях и сводит к минимуму проблемы в будущем.

Анкеты

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

Есть два типа анкет -

• Open-ended Questionnaires- Он состоит из вопросов, которые можно легко и правильно интерпретировать. Они могут изучить проблему и найти конкретное направление ответа.

• Closed-ended Questionnaires - Он состоит из вопросов, которые используются, когда системный аналитик эффективно перечисляет все возможные ответы, которые являются взаимоисключающими.

Advantages of questionnaires

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

• В ситуации полезно знать, какая часть данной группы одобряет или не одобряет определенную особенность предлагаемой системы.

• Прежде чем давать какое-либо конкретное направление системному проекту, полезно определить общее мнение.

• Он более надежен и обеспечивает высокую конфиденциальность честных ответов.

• Это подходит для выбора фактической информации и для сбора статистических данных, которые могут быть отправлены по электронной почте или по почте.

Обзор записей, процедур и форм

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

Advantages

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

• Это помогает документировать текущие операции за короткий промежуток времени, так как инструкции и формы по процедурам описывают формат и функции существующей системы.

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

• Это может помочь аналитику понять систему с точки зрения операций, которые необходимо поддерживать.

• В нем описывается проблема, ее затронутые части и предлагаемое решение.

Наблюдение

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

Advantages

• Это прямой метод сбора информации.

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

• It produces more accurate and reliable data.

• It produces all the aspect of documentation that are incomplete and outdated.

Joint Application Development (JAD)

It is a new technique developed by IBM which brings owners, users, analysts, designers, and builders to define and design the system using organized and intensive workshops. JAD trained analyst act as facilitator for workshop who has some specialized skills.

Advantages of JAD

• It saves time and cost by replacing months of traditional interviews and follow-up meetings.

• It is useful in organizational culture which supports joint problem solving.

• Fosters formal relationships among multiple levels of employees.

• It can lead to development of design creatively.

• It Allows rapid development and improves ownership of information system.

Secondary Research or Background Reading

This method is widely used for information gathering by accessing the gleaned information. It includes any previously gathered information used by the marketer from any internal or external source.

Advantages

• It is more openly accessed with the availability of internet.

• It provides valuable information with low cost and time.

• It act as forerunner to primary research and aligns the focus of primary research.

• It is used by the researcher to conclude if the research is worth it as it is available with procedures used and issues in collecting them.

Feasibility Study

Feasibility Study can be considered as preliminary investigation that helps the management to take decision about whether study of system should be feasible for development or not.

• It identifies the possibility of improving an existing system, developing a new system, and produce refined estimates for further development of system.

• It is used to obtain the outline of the problem and decide whether feasible or appropriate solution exists or not.

• The main objective of a feasibility study is to acquire problem scope instead of solving the problem.

• The output of a feasibility study is a formal system proposal act as decision document which includes the complete nature and scope of the proposed system.

Steps Involved in Feasibility Analysis

The following steps are to be followed while performing feasibility analysis −

• Form a project team and appoint a project leader.

• Develop system flowcharts.

• Identify the deficiencies of current system and set goals.

• Enumerate the alternative solution or potential candidate system to meet goals.

• Determine the feasibility of each alternative such as technical feasibility, operational feasibility, etc.

• Weight the performance and cost effectiveness of each candidate system.

• Rank the other alternatives and select the best candidate system.

• Prepare a system proposal of final project directive to management for approval.

Types of Feasibilities

Economic Feasibility

• It is evaluating the effectiveness of candidate system by using cost/benefit analysis method.

• It demonstrates the net benefit from the candidate system in terms of benefits and costs to the organization.

• The main aim of Economic Feasibility Analysis (EFS) is to estimate the economic requirements of candidate system before investments funds are committed to proposal.

• It prefers the alternative which will maximize the net worth of organization by earliest and highest return of funds along with lowest level of risk involved in developing the candidate system.

Technical Feasibility

• It investigates the technical feasibility of each implementation alternative.

• It analyzes and determines whether the solution can be supported by existing technology or not.

• The analyst determines whether current technical resources be upgraded or added it that fulfill the new requirements.

• It ensures that the candidate system provides appropriate responses to what extent it can support the technical enhancement.

Operational Feasibility

• It determines whether the system is operating effectively once it is developed and implemented.

• It ensures that the management should support the proposed system and its working feasible in the current organizational environment.

• It analyzes whether the users will be affected and they accept the modified or new business methods that affect the possible system benefits.

• It also ensures that the computer resources and network architecture of candidate system are workable.

Behavioral Feasibility

• It evaluates and estimates the user attitude or behavior towards the development of new system.

• It helps in determining if the system requires special effort to educate, retrain, transfer, and changes in employee’s job status on new ways of conducting business.

Schedule Feasibility

• It ensures that the project should be completed within given time constraint or schedule.

• It also verifies and validates whether the deadlines of project are reasonable or not.

Analysts use various tools to understand and describe the information system. One of the ways is using structured analysis.

What is Structured Analysis?

Structured Analysis is a development method that allows the analyst to understand the system and its activities in a logical way.

It is a systematic approach, which uses graphical tools that analyze and refine the objectives of an existing system and develop a new system specification which can be easily understandable by user.

It has following attributes −

• It is graphic which specifies the presentation of application.

• It divides the processes so that it gives a clear picture of system flow.

• It is logical rather than physical i.e., the elements of system do not depend on vendor or hardware.

• It is an approach that works from high-level overviews to lower-level details.

Structured Analysis Tools

During Structured Analysis, various tools and techniques are used for system development. They are −

• Data Flow Diagrams
• Data Dictionary
• Decision Trees
• Decision Tables
• Structured English
• Pseudocode

Data Flow Diagrams (DFD) or Bubble Chart

It is a technique developed by Larry Constantine to express the requirements of system in a graphical form.

• It shows the flow of data between various functions of system and specifies how the current system is implemented.

• It is an initial stage of design phase that functionally divides the requirement specifications down to the lowest level of detail.

• Its graphical nature makes it a good communication tool between user and analyst or analyst and system designer.

• It gives an overview of what data a system processes, what transformations are performed, what data are stored, what results are produced and where they flow.

Basic Elements of DFD

DFD is easy to understand and quite effective when the required design is not clear and the user wants a notational language for communication. However, it requires a large number of iterations for obtaining the most accurate and complete solution.

The following table shows the symbols used in designing a DFD and their significance −

Symbol Name	Symbol	Meaning
Square		Source or Destination of Data
Arrow		Data flow
Circle		Process transforming data flow
Open Rectangle		Data Store

Types of DFD

DFDs are of two types: Physical DFD and Logical DFD. The following table lists the points that differentiate a physical DFD from a logical DFD.

Physical DFD	Logical DFD
It is implementation dependent. It shows which functions are performed.	It is implementation independent. It focuses only on the flow of data between processes.
It provides low level details of hardware, software, files, and people.	It explains events of systems and data required by each event.
It depicts how the current system operates and how a system will be implemented.	It shows how business operates; not how the system can be implemented.

Context Diagram

A context diagram helps in understanding the entire system by one DFD which gives the overview of a system. It starts with mentioning major processes with little details and then goes onto giving more details of the processes with the top-down approach.

The context diagram of mess management is shown below.

Data Dictionary

A data dictionary is a structured repository of data elements in the system. It stores the descriptions of all DFD data elements that is, details and definitions of data flows, data stores, data stored in data stores, and the processes.

A data dictionary improves the communication between the analyst and the user. It plays an important role in building a database. Most DBMSs have a data dictionary as a standard feature. For example, refer the following table −

Sr.No.	Data Name	Description	No. of Characters
1	ISBN	ISBN Number	10
2	TITLE	title	60
3	SUB	Book Subjects	80
4	ANAME	Author Name	15

Decision Trees

Decision trees are a method for defining complex relationships by describing decisions and avoiding the problems in communication. A decision tree is a diagram that shows alternative actions and conditions within horizontal tree framework. Thus, it depicts which conditions to consider first, second, and so on.

Decision trees depict the relationship of each condition and their permissible actions. A square node indicates an action and a circle indicates a condition. It forces analysts to consider the sequence of decisions and identifies the actual decision that must be made.

The major limitation of a decision tree is that it lacks information in its format to describe what other combinations of conditions you can take for testing. It is a single representation of the relationships between conditions and actions.

For example, refer the following decision tree −

Decision Tables

Decision tables are a method of describing the complex logical relationship in a precise manner which is easily understandable.

• It is useful in situations where the resulting actions depend on the occurrence of one or several combinations of independent conditions.

• It is a matrix containing row or columns for defining a problem and the actions.

Components of a Decision Table

• Condition Stub − It is in the upper left quadrant which lists all the condition to be checked.

• Action Stub − It is in the lower left quadrant which outlines all the action to be carried out to meet such condition.

• Condition Entry − It is in upper right quadrant which provides answers to questions asked in condition stub quadrant.

• Action Entry − It is in lower right quadrant which indicates the appropriate action resulting from the answers to the conditions in the condition entry quadrant.

The entries in decision table are given by Decision Rules which define the relationships between combinations of conditions and courses of action. In rules section,

• Y shows the existence of a condition.
• N represents the condition, which is not satisfied.
• A blank - against action states it is to be ignored.
• X (or a check mark will do) against action states it is to be carried out.

For example, refer the following table −

CONDITIONS	Rule 1	Rule 2	Rule 3	Rule 4
Advance payment made	Y	N	N	N
Purchase amount = Rs 10,000/-	-	Y	Y	N
Regular Customer	-	Y	N	-
ACTIONS
Give 5% discount	X	X	-	-
Give no discount	-	-	X	X

Structured English

Structure English is derived from structured programming language which gives more understandable and precise description of process. It is based on procedural logic that uses construction and imperative sentences designed to perform operation for action.

• It is best used when sequences and loops in a program must be considered and the problem needs sequences of actions with decisions.

• It does not have strict syntax rule. It expresses all logic in terms of sequential decision structures and iterations.

For example, see the following sequence of actions −

if customer pays advance 
   then 
      Give 5% Discount 
   else 
      if purchase amount >=10,000 
         then 
            if  the customer is a regular customer 
               then Give 5% Discount 
            else  No Discount
         end if 
      else No Discount  
   end if 
end if

Pseudocode

A pseudocode does not conform to any programming language and expresses logic in plain English.

• It may specify the physical programming logic without actual coding during and after the physical design.

• It is used in conjunction with structured programming.

• It replaces the flowcharts of a program.

Guidelines for Selecting Appropriate Tools

Use the following guidelines for selecting the most appropriate tool that would suit your requirements −

• Use DFD at high or low level analysis for providing good system documentations.

• Use data dictionary to simplify the structure for meeting the data requirement of the system.

• Use structured English if there are many loops and actions are complex.

• Use decision tables when there are a large number of conditions to check and logic is complex.

• Use decision trees when sequencing of conditions is important and if there are few conditions to be tested.

System design is the phase that bridges the gap between problem domain and the existing system in a manageable way. This phase focuses on the solution domain, i.e. “how to implement?”

It is the phase where the SRS document is converted into a format that can be implemented and decides how the system will operate.

In this phase, the complex activity of system development is divided into several smaller sub-activities, which coordinate with each other to achieve the main objective of system development.

Inputs to System Design

System design takes the following inputs −

• Statement of work

• Requirement determination plan

• Current situation analysis

• Proposed system requirements including a conceptual data model, modified DFDs, and Metadata (data about data).

Outputs for System Design

System design gives the following outputs −

• Infrastructure and organizational changes for the proposed system.

• A data schema, often a relational schema.

• Metadata to define the tables/files and columns/data-items.

• A function hierarchy diagram or web page map that graphically describes the program structure.

• Actual or pseudocode for each module in the program.

• A prototype for the proposed system.

Types of System Design

Logical Design

Logical design pertains to an abstract representation of the data flow, inputs, and outputs of the system. It describes the inputs (sources), outputs (destinations), databases (data stores), procedures (data flows) all in a format that meets the user requirements.

While preparing the logical design of a system, the system analyst specifies the user needs at level of detail that virtually determines the information flow into and out of the system and the required data sources. Data flow diagram, E-R diagram modeling are used.

Physical Design

Physical design relates to the actual input and output processes of the system. It focuses on how data is entered into a system, verified, processed, and displayed as output.

It produces the working system by defining the design specification that specifies exactly what the candidate system does. It is concerned with user interface design, process design, and data design.

It consists of the following steps −

• Specifying the input/output media, designing the database, and specifying backup procedures.

• Planning system implementation.

• Devising a test and implementation plan, and specifying any new hardware and software.

• Updating costs, benefits, conversion dates, and system constraints.

Architectural Design

It is also known as high level design that focuses on the design of system architecture. It describes the structure and behavior of the system. It defines the structure and relationship between various modules of system development process.

Detailed Design

It follows Architectural design and focuses on development of each module.

Conceptual Data Modeling

It is representation of organizational data which includes all the major entities and relationship. System analysts develop a conceptual data model for the current system that supports the scope and requirement for the proposed system.

The main aim of conceptual data modeling is to capture as much meaning of data as possible. Most organization today use conceptual data modeling using E-R model which uses special notation to represent as much meaning about data as possible.

Entity Relationship Model

It is a technique used in database design that helps describe the relationship between various entities of an organization.

Terms used in E-R model

• ENTITY − It specifies distinct real world items in an application. For example: vendor, item, student, course, teachers, etc.

• RELATIONSHIP − They are the meaningful dependencies between entities. For example, vendor supplies items, teacher teaches courses, then supplies and course are relationship.

• ATTRIBUTES − It specifies the properties of relationships. For example, vendor code, student name. Symbols used in E-R model and their respective meanings −

The following table shows the symbols used in E-R model and their significance −

Symbol	Meaning
	Entity
	Weak Entity
	Relationship
	Identity Relationship
	Attributes
	Key Attributes
	Multivalued
	Composite Attribute
	Derived Attributes
	Total Participation of E2 in R
	Cardinality Ratio 1:N for E1:E2 in R

Three types of relationships can exist between two sets of data: one-to-one, one-to-many, and many-to-many.

File Organization

It describes how records are stored within a file.

There are four file organization methods −

• Serial − Records are stored in chronological order (in order as they are input or occur). Examples − Recording of telephone charges, ATM transactions, Telephone queues.

• Sequential − Records are stored in order based on a key field which contains a value that uniquely identifies a record. Examples − Phone directories.

• Direct (relative) − Each record is stored based on a physical address or location on the device. Address is calculated from the value stored in the record’s key field. Randomizing routine or hashing algorithm does the conversion.

• Indexed − Records can be processed both sequentially and non-sequentially using indexes.

Comparision

File Access

One can access a file using either Sequential Access or Random Access. File Access methods allow computer programs read or write records in a file.

Sequential Access

Every record on the file is processed starting with the first record until End of File (EOF) is reached. It is efficient when a large number of the records on the file need to be accessed at any given time. Data stored on a tape (sequential access) can be accessed only sequentially.

Direct (Random) Access

Records are located by knowing their physical locations or addresses on the device rather than their positions relative to other records. Data stored on a CD device (direct-access) can be accessed either sequentially or randomly.

Типы файлов, используемых в системе организации

Ниже приведены типы файлов, используемых в системе организации.

• Master file- Он содержит текущую информацию о системе. Например, файл клиента, файл студента, телефонный справочник.

• Table file- Это тип мастер-файла, который редко изменяется и хранится в табличном формате. Например, сохранение почтового индекса.

• Transaction file- Он содержит повседневную информацию, полученную в результате деловой активности. Он используется для обновления или обработки главного файла. Например, Адреса сотрудников.

• Temporary file - Он создается и используется системой, когда это необходимо.

• Mirror file- Они являются точными копиями других файлов. Помогите минимизировать риск простоя в случаях, когда оригинал приходит в негодность. Их необходимо изменять каждый раз, когда изменяется исходный файл.

• Log files- Они содержат копии основных записей и записей транзакций для регистрации любых изменений, внесенных в основной файл. Это облегчает аудит и обеспечивает механизм восстановления в случае сбоя системы.

• Archive files - Файлы резервных копий, содержащие исторические версии других файлов.

Контроль документации

Документация - это процесс записи информации для справочных или рабочих целей. Он помогает пользователям, менеджерам и ИТ-специалистам, которым это необходимо. Важно, чтобы подготовленный документ регулярно обновлялся, чтобы легко отслеживать ход работы системы.

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

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

Преимущества

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

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

• Он обеспечивает эффективный и действенный способ общения между техническими и нетехническими пользователями о системе.

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

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

• Он обеспечивает лучший контроль внутренней или внешней работы системы.

Типы документации

Когда дело доходит до системного дизайна, есть следующие четыре основных документа:

• Программная документация
• Системная документация
• Операционная документация
• Пользовательская документация

Программная документация

• Он описывает входы, выходы и логику обработки для всех программных модулей.

• Процесс документирования программы начинается на этапе анализа системы и продолжается во время реализации.

• Эта документация служит руководством для программистов, которые создают модули, которые хорошо поддерживаются внутренними и внешними комментариями и описаниями, которые можно легко понять и поддерживать.

Операционная документация

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

Он включает в себя следующую информацию -

• Программа, системный аналитик, программист и системная идентификация.

• Информация о расписании для вывода на печать, например отчет, частота выполнения и сроки.

• Входные файлы, их источники, выходные файлы и места назначения.

• Списки рассылки электронной почты и отчетов.

• Требуются специальные формы, включая онлайн-формы.

• Сообщения об ошибках и информационные сообщения для операторов и процедуры перезапуска.

• Особые инструкции, например, требования безопасности.

Пользовательская документация

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

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

Пользовательская документация должна включать -

• Обзор системы, в котором четко описаны все основные функции, возможности и ограничения системы.

• Описание содержания, подготовки, обработки и образцов исходного документа.

• Обзор опций меню и экрана ввода данных, содержания и инструкций по обработке.

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

• Информация о безопасности и контрольном журнале.

• Объяснение ответственности за конкретные требования к вводу, выводу или обработке.

• Процедуры запроса изменений и сообщения о проблемах.

• Примеры исключений и ошибочных ситуаций.

• Часто задаваемые вопросы (FAQ).

• Объяснение того, как получить помощь, и процедуры обновления руководства пользователя.

Системная документация

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

• Он описывает каждую программу в рамках ИС и всю ИС в целом.

• В нем описываются функции системы, способ их реализации, цель каждой программы в рамках всей ИБ в отношении порядка выполнения, информации, передаваемой в программы и из программ, и общего потока системы.

• Он включает в себя записи словаря данных, диаграммы потоков данных, объектные модели, макеты экранов, исходные документы и системные запросы, инициирующие проект.

• Большая часть системной документации готовится на этапах системного анализа и проектирования системы.

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

Стратегия сверху вниз

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

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

Стратегия снизу вверх

Стратегия «снизу-вверх» следует модульному подходу к разработке системы. Он называется так, потому что начинается с модулей самого нижнего или самого базового уровня и движется к модулям самого высокого уровня.

В этой технике

• Идентифицируются модули на самом базовом или самом низком уровне.

• Эти модули затем группируются вместе на основе функции, выполняемой каждым модулем, для формирования следующих модулей более высокого уровня.

• Затем эти модули объединяются в следующие модули более высокого уровня.

• Этот процесс группирования нескольких более простых модулей для формирования модулей более высокого уровня продолжается до тех пор, пока не будет достигнут основной модуль процесса разработки системы.

Структурированный дизайн

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

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

Модуляризация

Структурированный дизайн разбивает программу на небольшие независимые модули. Они организованы сверху вниз, а детали показаны внизу.

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

Advantages

• В первую очередь тестируются критически важные интерфейсы.
• Это обеспечивает абстракцию.
• Это позволяет нескольким программистам работать одновременно.
• Это позволяет повторно использовать код.
• Это обеспечивает контроль и повышает моральный дух.
• Это упрощает идентификацию структуры.

Структурированные диаграммы

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

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

• Control Module - Это модуль более высокого уровня, который управляет модулями более низкого уровня, называемыми subordinate modules.

• Library Module - Это многоразовый модуль, который можно вызывать более чем из одной точки на графике.

У нас есть два разных подхода к созданию структурированной диаграммы:

• Transform-Centered Structured Charts - Они используются, когда все транзакции проходят по одному и тому же пути.

• Transaction–Centered Structured Charts - Они используются, когда все транзакции не проходят по одному и тому же пути.

Цели использования структурных блок-схем

• Поощрять нисходящий дизайн.

• Поддерживать концепцию модулей и определять соответствующие модули.

• Чтобы показать размер и сложность системы.

• Чтобы определить количество легко идентифицируемых функций и модулей в каждой функции.

• Чтобы показать, является ли каждая идентифицируемая функция управляемым объектом или должна быть разбита на более мелкие компоненты.

Факторы, влияющие на сложность системы

Для разработки системного программного обеспечения хорошего качества необходимо разработать хороший дизайн. Поэтому при разработке дизайна системы основное внимание уделяется качеству разработки программного обеспечения. Качественный дизайн программного обеспечения - это такой дизайн, который сводит к минимуму сложность и затраты на разработку программного обеспечения.

Двумя важными концепциями, связанными с разработкой системы, которые помогают определить сложность системы, являются: coupling и cohesion.

Связь

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

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

Высокое сцепление

Системы такого типа имеют взаимосвязи с программными модулями, зависящими друг от друга. Изменения в одной подсистеме сильно влияют на другую подсистему.

Низкое сцепление

Системы этого типа состоят из независимых или почти независимых компонентов. Изменение одной подсистемы не влияет на другие подсистемы.

Меры сцепления

• Content Coupling - Когда один компонент фактически изменяет другой, то измененный компонент полностью зависит от изменения одного.

• Common Coupling - Когда степень связи несколько снижается за счет организации системного дизайна так, чтобы данные были доступны из общего хранилища данных.

• Control Coupling - Когда один компонент передает параметры для управления активностью другого компонента.

• Stamp Coupling - Когда структуры данных используются для передачи информации от одного компонента к другому.

• Data Coupling - Когда передаются только данные, компоненты соединяются этой связью.

Сплоченность

Сплоченность - это мера близости отношений между ее составляющими. Он определяет степень зависимости компонентов модуля друг от друга. На практике это означает, что разработчик системы должен гарантировать, что:

• Они не разделяют важные процессы на фрагментированные модули.

• Они не собирают вместе несвязанные процессы, представленные как процессы на DFD, в бессмысленные модули.

Лучшие модули - это те, которые функционально связаны. Худшие модули - это те, которые по совпадению связаны.

Худшая степень сплоченности

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

• Logical Cohesion - Здесь несколько логически связанных функций или элементов данных помещаются в один и тот же компонент.

• Temporal Cohesion - Это когда компонент, который используется для инициализации системы или установки переменных, выполняет несколько функций последовательно, но функции связаны по времени.

• Procedurally Cohesion - Это когда функции группируются в компонент, чтобы обеспечить этот порядок.

• Sequential Cohesion - Это когда выход одной части компонента является входом для следующей его части.

Дизайн ввода

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

Следовательно, качество ввода системы определяет качество вывода системы. Хорошо продуманные формы ввода и экраны имеют следующие свойства:

• Он должен эффективно служить конкретной цели, такой как хранение, запись и получение информации.

• Это обеспечивает правильное завершение с точностью.

• Он должен быть простым и простым для заполнения.

• Он должен фокусироваться на внимании пользователя, последовательности и простоте.

• Все эти цели достигаются с использованием знания основных принципов проектирования, касающихся:

  • Какие входы необходимы для системы?

  • Как конечные пользователи реагируют на различные элементы форм и экранов.

Цели для дизайна ввода

Цели входного дизайна:

• Для разработки процедур ввода и ввода данных

• Чтобы уменьшить входную громкость

• Для разработки исходных документов для сбора данных или разработки других методов сбора данных

• Для разработки записей входных данных, экранов ввода данных, экранов пользовательского интерфейса и т. Д.

• Использовать проверки достоверности и разрабатывать эффективные средства управления вводом.

Методы ввода данных

Важно разработать соответствующие методы ввода данных, чтобы предотвратить ошибки при вводе данных. Эти методы зависят от того, вводятся ли данные в формы вручную клиентами, а затем вводятся операторами ввода данных, или данные вводятся непосредственно пользователями на ПК.

Система должна предотвращать ошибки пользователя:

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

Некоторые из популярных методов ввода данных:

• Пакетный метод ввода (автономный метод ввода данных)
• Метод ввода данных онлайн
• Машиночитаемые формы
• Интерактивный ввод данных

Контроль целостности ввода

Контроль целостности ввода включает в себя ряд методов для устранения типичных ошибок ввода конечными пользователями. Они также включают проверки значений отдельных полей; как для формата, так и для полноты всех входных данных.

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

Дизайн вывода

Дизайн вывода - важнейшая задача любой системы. Во время проектирования выходных данных разработчики определяют тип необходимых выходных данных и рассматривают необходимые элементы управления выходными данными и макеты прототипов отчетов.

Цели дизайна вывода

Цели входного дизайна:

• Разработать дизайн вывода, который служит намеченной цели и исключает производство нежелательной продукции.

• Разработать выходной дизайн, отвечающий требованиям конечных пользователей.

• Доставить необходимое количество продукции.

• Сформировать вывод в соответствующем формате и направить его нужному человеку.

• Своевременно предоставлять продукцию для принятия правильных решений.

Давайте теперь рассмотрим различные типы выходов -

Внешние выходы

Производители создают и проектируют внешние выходы для принтеров. Внешние выходы позволяют системе оставлять триггерные действия со стороны их получателей или подтверждать действия их получателям.

Некоторые из внешних выходов спроектированы как оборотные выходы, которые реализованы в виде формы и повторно входят в систему как вход.

Внутренние выходы

Внутренние выходы присутствуют внутри системы и используются конечными пользователями и менеджерами. Они поддерживают руководство в принятии решений и отчетности.

Есть три типа отчетов, производимых с помощью управленческой информации:

• Detailed Reports - Они содержат текущую информацию, которая почти не фильтруется или не ограничивается, чтобы облегчить планирование и контроль управления.

• Summary Reports - Они содержат тенденции и потенциальные проблемы, которые классифицируются и резюмируются для менеджеров, которым не нужны подробности.

• Exception Reports - Они содержат исключения, отфильтрованные данные по какому-либо условию или стандарту перед их представлением менеджеру в качестве информации.

Контроль целостности вывода

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

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

Формы Дизайн

И формы, и отчеты являются продуктом дизайна ввода и вывода и представляют собой бизнес-документ, состоящий из определенных данных. Основное отличие состоит в том, что формы предоставляют поля для ввода данных, а отчеты используются исключительно для чтения. Например, формы заказов, заявки на трудоустройство и кредит и т. Д.

• При разработке формы дизайнеры должны знать:

  • кто будет их использовать

  • куда бы они были доставлены

  • цель формы или отчета

• Во время проектирования форм инструменты автоматического проектирования расширяют возможности разработчика по созданию прототипов форм и отчетов и их представления конечным пользователям для оценки.

Цели хорошего дизайна формы

Хороший дизайн формы необходим, чтобы обеспечить следующее:

• Чтобы экран был простым, давая правильную последовательность, информацию и четкие подписи.

• Для достижения поставленной цели с помощью соответствующих форм.

• Для обеспечения точности заполнения формы.

• Чтобы форма оставалась привлекательной, используйте значки, инвертированное видео, мигающие курсоры и т. Д.

• Для облегчения навигации.

Типы форм

Flat Forms

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

• Это самая простая и недорогая форма для дизайна, печати и воспроизведения, которая требует меньшего объема.

Unit Set/Snap out Forms

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

• Угольки могут быть как синими, так и черными, стандартного сорта средней интенсивности. Как правило, синие угли лучше всего подходят для рукописных форм, а черные - для машинного использования.

Continuous strip/Fanfold Forms

• Это несколько отдельных форм, соединенных в непрерывную полосу с перфорацией между каждой парой форм.

• Это менее затратный метод для использования в больших объемах.

No Carbon Required (NCR) Paper

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

• Когда прикладывается давление, две капсулы взаимодействуют и создают образ.

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

Системное тестирование и обеспечение качества помогают при проверке системы. Он включает -

• Качество продукта на уровне (тестирование)
• Качество на уровне процесса.

Разберем их вкратце -

Тестирование

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

Успешный тест - это тот, который обнаруживает ошибки. Он выполняет программу с явным намерением найти ошибку, т. Е. Вывести программу из строя. Это процесс оценки системы с целью создания сильной системы, который в основном фокусируется на слабых местах системы или программного обеспечения.

Характеристики системного тестирования

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

Этапы тестирования системы

В тестировании участвуют следующие этапы -

Test Strategy

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

Test Plan

Он предоставляет план тестирования системы и подтверждает, что тестируемая система соответствует всем проектным и функциональным спецификациям. План тестирования предоставляет следующую информацию -

• Цели каждого этапа тестирования
• Подходы и инструменты, используемые для тестирования
• Обязанности и время, необходимое для каждого действия по тестированию
• Доступность инструментов, средств и тестовых библиотек
• Процедуры и стандарты, необходимые для планирования и проведения испытаний
• Факторы, ответственные за успешное завершение процесса тестирования

Test Case Design

• Для каждого модуля тестируемой системы определен ряд тестовых примеров.

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

• Тестовые примеры вместе с планом тестирования документируются как часть документа спецификации системы или в отдельном документе под названием test specification или же test description.

Test Procedures

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

Test Result Documentation

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

Типы тестирования

Тестирование может быть разных типов, и разные типы тестов проводятся в зависимости от типа ошибок, которые вы пытаетесь обнаружить -

Модульное тестирование

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

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

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

Интеграционное тестирование

В Integration Testing аналитик тестирует несколько модулей, работающих вместе. Он используется для поиска расхождений между системой и ее первоначальной целью, текущими спецификациями и системной документацией.

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

• Он проверяет, соответствуют ли размеры файлов и правильно ли построены индексы.

Функциональное тестирование

Функциональное тестирование определяет, правильно ли работает система в соответствии с ее спецификациями и соответствующей стандартной документацией. Функциональное тестирование обычно начинается с внедрения системы, что очень важно для успеха системы.

Функциональное тестирование делится на две категории -

• Positive Functional Testing - Это включает в себя тестирование системы с действительными входными данными для проверки правильности полученных выходных данных.

• Negative Functional Testing - Это включает в себя тестирование программного обеспечения с недопустимыми входными данными и нежелательными условиями работы.

Правила тестирования системы

Для успешного проведения тестирования системы вам необходимо следовать данным правилам -

• Тестирование должно основываться на требованиях пользователя.

• Прежде чем писать сценарии тестирования, необходимо тщательно понять бизнес-логику.

• План тестирования должен быть выполнен как можно скорее.

• Тестирование должно проводиться третьей стороной.

• Это должно выполняться на статическом ПО.

• Тестирование должно проводиться на допустимые и недопустимые входные условия.

• Тестирование должно быть пересмотрено и изучено, чтобы снизить затраты.

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

• Должна быть сделана документация тестовых примеров и результатов тестирования.

Гарантия качества

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

• Цель QA - обеспечить доверие клиентов путем постоянной поставки продукта в соответствии со спецификацией.

• Обеспечение качества программного обеспечения (SQA) - это методика, которая включает процедуры и инструменты, применяемые профессионалами в области программного обеспечения для обеспечения соответствия программного обеспечения установленным стандартам для предполагаемого использования и производительности.

• Основная цель SQA - обеспечить надлежащую и точную видимость проекта программного обеспечения и разрабатываемого продукта для администрации.

• Он проверяет и проверяет программный продукт и его действия на протяжении всего жизненного цикла разработки системы.

Цели обеспечения качества

Цели обеспечения качества заключаются в следующем:

• Для мониторинга процесса разработки программного обеспечения и окончательного разрабатываемого программного обеспечения.

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

• Для уведомления групп и отдельных лиц о деятельности SQA и результатах этой деятельности.

• Гарантировать, что проблемы, которые не решаются в программном обеспечении, решаются высшим руководством.

• Выявить недостатки в продукте, процессе или стандартах и ​​исправить их.

Уровни гарантии качества

Существует несколько уровней контроля качества и тестирования, которые необходимо выполнить для сертификации программного продукта.

Level 1 − Code Walk-through

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

Level 2 − Compilation and Linking

На этом уровне проверяется, может ли программа компилировать и связывать все официальные платформы и операционные системы.

Level 3 − Routine Running

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

Level 4 − Performance test

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

Внедрение - это процесс обеспечения работоспособности информационной системы. Это включает в себя -

• Создание новой системы с нуля
• Построение новой системы из существующей.

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

Тренировка

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

Операторы систем обучения

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

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

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

Обучение пользователей

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

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

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

Рекомендации по обучению

• Установление измеримых целей
• Используя соответствующие методы обучения
• Выбор подходящих сайтов для обучения
• Использование понятных учебных материалов

Методы обучения

Обучение под руководством инструктора

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

Virtual Classroom

На этом тренинге инструкторы должны встречаться со слушателями в одно и то же время, но не обязаны находиться в одном месте. Основные используемые здесь инструменты: видеоконференцсвязь, текстовые инструменты интернет-чата, пакеты виртуальной реальности и т. Д.

Normal Classroom

Тренеры должны встречаться со слушателями в одно и то же время и в одном месте. Основными используемыми здесь инструментами являются школьная доска, диапроекторы, ЖК-проекторы и т. Д.

Самостоятельное обучение

В нем участвуют как инструкторы, так и стажеры, которым не нужно встречаться в одном месте или в одно время. Стажеры осваивают навыки самостоятельно, посещая курсы в удобное для них время. Он бывает двух типов -

Multimedia Training

В этом тренинге курсы представлены в мультимедийном формате и сохранены на CD-ROM. Это сводит к минимуму затраты на разработку внутреннего курса обучения без помощи внешних программистов.

Web-based Training

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

Преобразование

Это процесс перехода от старой системы к новой. Он обеспечивает понятный и структурированный подход для улучшения взаимодействия между руководством и командой проекта.

План конверсии

Он содержит описание всех действий, которые должны произойти во время внедрения новой системы и ввода ее в действие. Он предвидит возможные проблемы и способы их решения.

Он включает в себя следующие мероприятия -

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

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

Четыре метода преобразования:

• Параллельное преобразование
• Прямое преобразование с переключением
• Пилотный подход
• Метод фазового ввода

Метод	Описание	Преимущества	Недостатки
Параллельное преобразование	Старые и новые системы используются одновременно.	Обеспечивает откат при выходе из строя новой системы. Предлагает максимальную безопасность и, в конечном итоге, тестирование новой системы.	Вызывает перерасход средств. Новая система может не получить должного внимания.
Прямое преобразование с переключением	Внедрена новая система, а старая полностью заменена.	Заставляет пользователей заставить новую систему работать Мгновенная выгода от новых методов и контроля.	Не отступать, если возникнут проблемы с новой системой Требуется самое тщательное планирование
Пилотный подход	Поддерживает поэтапный подход, который постепенно внедряет систему для всех пользователей	Позволяет обучение и установку без излишнего использования ресурсов. Избегайте крупных непредвиденных обстоятельств из-за управления рисками.	Длительное поэтапное внедрение вызывает проблему, идет ли конверсия успешно или нет.
Метод фазового ввода	Рабочая версия системы, реализованная в одной части организации на основе обратной связи, устанавливается по всей организации самостоятельно или поэтапно.	Предоставляет опыт и тестирование линии перед внедрением Когда предпочтение отдается новой системе, включающей новые технологии или радикальные изменения в характеристиках.	Создается впечатление, что старая система ошибочна и ненадежна.

Преобразование файлов

Это процесс преобразования одного формата файла в другой. Например, файл в формате WordPerfect можно преобразовать в Microsoft Word.

Для успешного преобразования требуется план преобразования, который включает:

• Знание целевой системы и понимание существующей системы
• Teamwork
• Автоматизированные методы, тестирование и параллельные операции
• Постоянная поддержка для исправления проблем
• Обновление системной / пользовательской документации и т. Д.

Многие популярные приложения поддерживают открытие и сохранение в файлы других форматов того же типа. Например, Microsoft Word может открывать и сохранять файлы во многих других форматах обработки текста.

Обзор оценки после внедрения (PIER)

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

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

Цели PIER

Цели наличия PIER заключаются в следующем:

• Чтобы определить успех проекта относительно прогнозируемых затрат, выгод и сроков.

• Выявить возможности добавить проекту дополнительную ценность.

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

• Дать рекомендации относительно будущего проекта путем уточнения методик оценки затрат.

Следующие сотрудники должны быть включены в процесс проверки:

• Команда и руководство проекта
• Персонал пользователя
• Персонал стратегического управления
• Внешние пользователи

Сопровождение / улучшение системы

Техническое обслуживание означает восстановление чего-либо в исходное состояние. Улучшение означает добавление, изменение кода для поддержки изменений в пользовательской спецификации. Обслуживание системы приводит систему в соответствие с ее первоначальными требованиями, а усовершенствования расширяют возможности системы за счет включения новых требований.

Таким образом, техническое обслуживание изменяет существующую систему, расширение добавляет функции к существующей системе, а разработка заменяет существующую систему. Это важная часть разработки системы, которая включает действия по исправлению ошибок при проектировании и реализации системы, обновлению документов и тестированию данных.

Типы обслуживания

Системное обслуживание можно разделить на три типа:

• Corrective Maintenance - Позволяет пользователю выполнять ремонт и исправление оставшихся проблем.

• Adaptive Maintenance - Позволяет пользователю заменять функции программ.

• Perfective Maintenance - Позволяет пользователю изменять или улучшать программы в соответствии с требованиями пользователей и меняющимися потребностями.

Системный аудит

Это расследование для проверки производительности операционной системы. Цели проведения системного аудита следующие:

• Сравнить фактическую и планируемую производительность.

• Проверить, что заявленные цели системы по-прежнему актуальны в текущей среде.

• Оценить достижение поставленных целей.

• Для обеспечения надежности компьютерной финансовой и другой информации.

• Чтобы обеспечить включение всех записей в обработку.

• Для защиты от мошенничества.

Аудит использования компьютерных систем

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

Системный аудитор

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

Аудиторское испытание

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

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

Методы аудита

Аудит можно проводить двумя разными способами:

Аудит вокруг компьютера

• Возьмите образцы входных данных и вручную примените правила обработки.
• Сравните выходные данные с компьютерными.

Аудит через компьютер

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

Рекомендации по аудиту

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

Действия на этом этапе следующие:

• Выявление текущих проблем окружающей среды
• Выявление причин проблемы
• Выявление альтернативных решений
• Оценка и технико-экономический анализ каждого решения
• Выбор и рекомендация наиболее практичного и подходящего решения
• Оценка стоимости проекта и анализ рентабельности

Безопасность

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

• System privacy занимается защитой отдельных систем от доступа и использования без разрешения / ведома заинтересованных лиц.

• System integrity касается качества и надежности необработанных и обработанных данных в системе.

Меры контроля

Существует множество мер контроля, которые можно в общих чертах классифицировать следующим образом:

Резервное копирование

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

• Инкрементное резервное копирование с более короткими интервалами.

• Резервные копии, хранящиеся в безопасном удаленном месте, особенно необходимы для аварийного восстановления.

• Работают дублирующие системы, и все транзакции зеркалируются, если это очень важная система и не допускает сбоев перед сохранением на диске.

Физический контроль доступа к объектам

• Физические замки и биометрическая аутентификация. Например, отпечаток пальца
• Удостоверения личности или пропуски проверяются сотрудниками службы безопасности.
• Идентификация всех лиц, читающих или изменяющих данные, и запись их в файл.

Использование логического или программного управления

• Система паролей.
• Шифрование конфиденциальных данных / программ.
• Обучение сотрудников работе с данными и безопасности.
• Антивирусное программное обеспечение и защита брандмауэра при подключении к Интернету.

Анализ риска

Риск - это возможность потерять что-то ценное. Анализ рисков начинается с планирования безопасной системы путем определения уязвимости системы и ее воздействия. Затем составляется план управления риском и преодоления бедствия. Это делается для оценки вероятности возможных катастроф и их стоимости.

Анализ рисков - это совместная работа экспертов с различным опытом, например, с химическими веществами, человеческими ошибками и технологическим оборудованием.

При проведении анализа рисков необходимо соблюдать следующие шаги:

• Идентификация всех компонентов компьютерной системы.

• Выявление всех угроз и опасностей, с которыми сталкивается каждый из компонентов.

• Количественная оценка рисков, т.е. оценка потерь в случае, если угрозы станут реальностью.

Анализ рисков - основные шаги

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

Управление рисками - это непрерывный процесс, который включает в себя следующие шаги:

• Определение мер безопасности.

• Расчет стоимости внедрения мер безопасности.

• Сравнение стоимости мер безопасности с убытком и вероятностью угроз.

• Подбор и реализация мер безопасности.

• Обзор выполнения мер безопасности.

В объектно-ориентированном подходе основное внимание уделяется фиксации структуры и поведения информационных систем в небольших модулях, которые объединяют как данные, так и процессы. Основная цель объектно-ориентированного проектирования (ООД) - повысить качество и продуктивность системного анализа и проектирования, сделав их более удобными.

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

ОО-модель выгодна следующими способами:

• Это облегчает внесение изменений в систему при невысокой стоимости.

• Это способствует повторному использованию компонентов.

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

• Это упрощает проектирование распределенных систем.

Элементы объектно-ориентированной системы

Давайте пройдемся по характеристикам OO System -

• Objects- Объект - это то, что существует в проблемной области и может быть идентифицировано данными (атрибутом) или поведением. Все материальные объекты (студент, пациент) и некоторые нематериальные объекты (банковский счет) моделируются как объект.

• Attributes - Они описывают информацию об объекте.

• Behavior- Он указывает, что объект может делать. Он определяет операцию, выполняемую над объектами.

• Class- Класс инкапсулирует данные и их поведение. Объекты со схожим значением и назначением, сгруппированные в класс.

• Methods- Методы определяют поведение класса. Это не что иное, как действие, которое может выполнить объект.

• Message- Сообщение - это вызов функции или процедуры от одного объекта к другому. Это информация, отправляемая объектам для запуска методов. По сути, сообщение - это вызов функции или процедуры от одного объекта к другому.

Особенности объектно-ориентированной системы

Объектно-ориентированная система имеет несколько замечательных функций, которые обсуждаются ниже.

Инкапсуляция

Инкапсуляция - это процесс сокрытия информации. Это просто объединение процесса и данных в единое целое. Данные объекта скрыты от остальной системы и доступны только через службы класса. Он позволяет улучшать или модифицировать методы, используемые объектами, не затрагивая другие части системы.

Абстракция

Это процесс выбора или выбора необходимого метода и атрибутов для указания объекта. Он фокусируется на основных характеристиках объекта с точки зрения пользователя.

Отношения

Все классы в системе связаны друг с другом. Объекты не существуют изолированно, они существуют во взаимосвязи с другими объектами.

Есть три типа объектных отношений -

• Aggregation - Он указывает на отношения между целым и его частями.

• Association - В этом случае два класса связаны или связаны каким-либо образом, например, один класс работает с другим для выполнения задачи или один класс действует на другой класс.

• Generalization- Дочерний класс основан на родительском классе. Это означает, что два класса похожи, но имеют некоторые различия.

Наследование

Наследование - отличная функция, которая позволяет создавать подклассы из существующего класса путем наследования атрибутов и / или операций существующих классов.

Полиморфизм и динамическое связывание

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

В полиморфной операции операция может выполняться по-разному для разных классов объектов. Это позволяет нам манипулировать объектами разных классов, зная только их общие свойства.

Структурированный подход против Объектно-ориентированный подход

В следующей таблице объясняется, чем объектно-ориентированный подход отличается от традиционного структурного подхода.

Структурированный подход	Объектно-ориентированный подход
Он работает с подходом сверху вниз.	Он работает с подходом снизу вверх.
Программа разделена на ряд подмодулей или функций.	Программа организована по количеству классов и объектов.
Используется вызов функции.	Используется передача сообщений.
Повторное использование программного обеспечения невозможно.	Возможно повторное использование.
Программирование структурированного дизайна обычно длится до конца.	Программирование объектно-ориентированного дизайна выполняется одновременно с другими этапами.
Структурированный дизайн больше подходит для офшоринга.	Подходит для собственной разработки.
Он показывает четкий переход от дизайна к реализации.	Не очень понятный переход от дизайна к реализации.
Он подходит для систем реального времени, встроенных систем и проектов, где объекты не являются наиболее полезным уровнем абстракции.	Он подходит для большинства бизнес-приложений и проектов разработки игр, которые предполагается настраивать или расширять.
Диаграмма DFD и ER моделирует данные.	Диаграмма классов, диаграмма последовательности, диаграмма диаграммы состояний и варианты использования - все это вносит свой вклад.
В этом случае проектами можно легко управлять благодаря четко обозначенным этапам.	При таком подходе проектами может быть сложно управлять из-за неопределенных переходов между фазами.

Единый язык моделирования (UML)

UML - это визуальный язык, который позволяет моделировать процессы, программное обеспечение и системы для выражения дизайна системной архитектуры. Это стандартный язык для проектирования и документирования системы объектно-ориентированным образом, который позволяет техническим архитекторам общаться с разработчиком.

Он определяется как набор спецификаций, созданных и распространяемых Object Management Group. UML является расширяемым и масштабируемым.

Цель UML - предоставить общий словарь объектно-ориентированных терминов и методов построения диаграмм, достаточно богатый для моделирования любого проекта разработки систем от анализа до реализации.

UML состоит из -

• Diagrams - Это графические изображения процесса, системы или какой-то ее части.

• Notations - Он состоит из элементов, которые работают вместе в диаграмме, таких как соединители, символы, примечания и т. Д.

Пример обозначения UML для класса

Схема экземпляров-нотация UML

Операции, выполняемые над объектами

С объектами выполняются следующие операции -

• Constructor/Destructor- Создание новых экземпляров класса и удаление существующих экземпляров класса. Например, добавление нового сотрудника.

• Query- Доступ к состоянию без изменения значения, не имеет побочных эффектов. Например, поиск адреса конкретного сотрудника.

• Update - Изменяет значение одного или нескольких атрибутов и влияет на состояние объекта. Например, изменение адреса сотрудника.

Использование UML

UML весьма полезен для следующих целей -

• Моделирование бизнес-процесса
• Описание архитектуры системы
• Отображение структуры приложения
• Регистрация поведения системы
• Моделирование структуры данных
• Создание подробных спецификаций системы
• Наброски идей
• Генерация программного кода

Статические модели

Статические модели показывают структурные характеристики системы, описывают ее системную структуру и делают акцент на частях, составляющих систему.

• Они используются для определения имен классов, атрибутов, методов, сигнатур и пакетов.

• Диаграммы UML, представляющие статическую модель, включают диаграмму классов, диаграмму объектов и диаграмму вариантов использования.

Динамические модели

Динамические модели показывают поведенческие характеристики системы, т. Е. То, как система ведет себя в ответ на внешние события.

• Динамические модели определяют необходимый объект и то, как они работают вместе, с помощью методов и сообщений.

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

• Диаграммы UML представляют динамическую модель, включая диаграмму последовательности, диаграмму связи, диаграмму состояний, диаграмму активности.

Жизненный цикл разработки объектно-ориентированной системы

Он состоит из трех макросов -

• Объектно-ориентированный анализ (OOA)
• Объектно-ориентированный дизайн (ООД)
• Объектно-ориентированная реализация (OOI)

Деятельность по разработке объектно-ориентированных систем

Разработка объектно-ориентированных систем включает следующие этапы:

• Объектно-ориентированный анализ
• Объектно-ориентированный дизайн
• Prototyping
• Implementation
• Пошаговое тестирование

Объектно-ориентированный анализ

Этот этап касается определения системных требований и понимания системных требований для создания use-case model. Вариант использования - это сценарий для описания взаимодействия между пользователем и компьютерной системой. Эта модель представляет потребности пользователя или представление пользователя о системе.

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

Объектно-ориентированный дизайн

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

Прототипирование

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

Это также может дать пользователям возможность прокомментировать удобство использования и полезность дизайна. Он может дополнительно определить вариант использования и значительно упростить моделирование вариантов использования.

Реализация

Он использует либо компонентную разработку (CBD), либо быструю разработку приложений (RAD).

Компонентная разработка (CBD)

CODD - это индустриальный подход к процессу разработки программного обеспечения с использованием различных технологий, таких как инструменты CASE. Разработка приложений переходит от индивидуальной разработки к сборке предварительно созданных, предварительно протестированных и повторно используемых программных компонентов, которые взаимодействуют друг с другом. Разработчик CBD может собрать компоненты для построения полной программной системы.

Быстрая разработка приложений (RAD)

RAD - это набор инструментов и методов, которые можно использовать для создания приложения быстрее, чем это обычно возможно с помощью традиционных методов. Он не заменяет SDLC, а дополняет его, поскольку он больше ориентирован на описание процесса и может идеально сочетаться с объектно-ориентированным подходом.

Его задача - быстро построить приложение и постепенно реализовать дизайн требований пользователя с помощью таких инструментов, как Visual Basic, Power Builder и т. Д.

Инкрементальное тестирование

Разработка программного обеспечения и вся его деятельность, включая тестирование, - это итеративный процесс. Следовательно, если мы откладываем тестирование продукта только после его полной разработки, это может оказаться дорогостоящим делом. Здесь появляется инкрементное тестирование, когда продукт тестируется на различных этапах его разработки.