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

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

Что будем исследовать? Если вас позвали автоматизировать какой-то процесс - значит он уже работает, но без применения (или с минимальным использованием) компьютеров. " Процесс работает" - значит, есть какие-то регламенты. правила, описания технологических процессов, приказы, руководства и т.п., то есть - нормативные документы. В них многое написано. Кроме того, есть входящие и исходящие документы, как в печатном, так и в электронном виде, сообщения электронной почты, и т.д. и т.п., вкоторых явно просматривается структура данных. Именно разнообразные документы являются в данном случае объектом исследования. Предметом же исследования является состав данных в этих документах (для написания требований к данным), и регламент создания, передачи, изменения и уничтожения этих документов - для написания требований к интерфейсам программы и процессам обмена данными.

Цитата из Мацяшека: " Изучение документов и программных систем является неоценимым методом выявления как требований, связанных с прецедентами использования, так и требований, относящихся к предметной области. Этот метод используется всегда, хотя он может касаться только отдельных сторон системы. Требования, связанные с прецедентами использования (use case requirements), выявляются посредством изучения существующих организационных документов, а также системных форм и отчетов (если существует компьютерная система, что типично для больших организаций). Одним из наиболее полезных способов постижения сути требований, связанных с прецедентами использования, является фиксация дефектов (естественно, при их наличии) и формирование запросов на изменение существующей системы. К организационным документам, подлежащим изучению, относятся: формы деловых документов (по возможности — заполненные), описания рабочих процедур, должностные обязанности, методические руководства, бизнес-планы, схемы организационных структур, внутренняя корреспонденция, протоколы совещаний, учетные записи, внешняя корреспонденция, жалобы клиентов и т.д. Системные формы и отчеты, подлежащие изучению, включают копии экранов и отчеты вместе с соответствующей документацией (системные руководства по эксплуатации, пользовательская документация, техническая документация, системные модели анализа и проектирования). Требования, основанные на знании проблемной области, выясняются посредством изучения журналов и учебников, которые относятся к данной сфере. Изучение патентованных программных продуктов наподобие систем ERP (Enterprise Resource Planning Systems — системы планирования ресурсов предприятия) и CRM (Customer Relationship Management — системы управления взаимоотношениями с заказчиками) также может стать богатым источником знаний о проблемной области."

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

Фактически, ТЗ - это своего рода договор между заказчиком и программистом. В России, где Гражданский Кодекс требует заключения формального договора, ТЗ часто выступает приложением к договору. ТЗ - документ, имеющий определенный шаблон, варьирующий от организации к организации, в зависимости от используемых стандартов (особенно касается государственных заказчиков). В любом случае, ядром ТЗ является изложение (формулировка) требований.

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

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

Этап планирования и анализа требований

Цель:
- получение требований;
- выработка производных от них требований для этапа оценки безопасности.
Входные данные:
- требования к системе, аппаратный интерфейс, архитектура системы;
- план разработки ПО;
- стандарты на требования к ПО.

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

Проектирование – процесс ЖЦ ИС, во время которого исследуется ее структура и взаимосвязи элементов. Основной решаемый вопрос – «Как система будет удовлетворять полученным требованиям?»

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

Проектирование ПО должно проводиться на двух уровнях

1) Проектирование архитектуры ПО (проектирование «в большом»). Архитектура программного продукта – это его представление как системы, состоящей из некоторой совокупности взаимодействующих подсистем (отдельных программ, модулей) (декомпозиция системы). Здесь необходимо определить основные компоненты ПО и их взаимосвязи.

2) Детальное проектирование ПО (проектирование программных модулей(компонентов), проектирование «в малом»).

Основными принципами проектирования ПО являются:

1. Принцип системного единства. Все программы, входящие в систему, должны представлять единое целое.

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

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

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

Результатом анализа и проектировния должен стать проект, содержащий достаточное количество информации для реализации системы на его основе. Должна быть получена детальная модель разрабатываемого ПО вместе с описанием его компонентов. Тип модели зависит от выбранного подхода (структурный, объектный или компонентный) и конкретной технологии проектирования. Их различие состоит в разных способах декомпозиции систем.

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

Проектирования ПО при структурном подходе (Самостоятельно).

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

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

В нашем курсе мы будем знакомиться только со структурной т.к. у

вас будет дисциплина «Объектно-ориентированное программирование», где вы познакомитесь с объектно-ориентированой методологией.

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

Различают два аспекта проектирования:

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

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

Первый уровень - проектирование архитектуры (проектирование «в большом») для структурной методологии включает следующие основные методы:

1.метод нисходящего проектирования (сверху – вниз)

2.метод восходящего проектирования (снизу – вверх)

Метод нисходящего проектирования (сверху – вниз) представляет собой подход функциональной декомпозиции на основе следующих двух стратегий:

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

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

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

Основыми методами проектирования модулей (второй уровень, т.е. проектирование в «малом») для структурной методологии являются:

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

- Структурные карты;

- Диаграммы деятельности

- Диаграммы переходов состояний

- Блок-схемы;

- Снимки экранов;

- структурограммы;

- Псевдокод

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

Псевдокод Алгоритм Евклида нахождения Наибольшего общего делителя A и B

Начало

Пока A< > B повторять

Начало

Если A > B то A = A – B

Иначе

B = B – A

Конец если

Конец

Вывод A

Стоп

Конец

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

1.процедурно-ориентированные подходы, в которых первично проектирование функциональных компонентов

2.подходы, ориентированные на данные. Для них первичны входные и выходные данные, а функциональные (процедурные) компоненты вторичны

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

Конкретными подходами являются:

- Подход Йордана и Де Марко

- Подход Гейна-Сарсона

- Подход Константайна.

- Подход Джексона

- Подход Варнье-Орра

- Подход Мартина

- Подход промышленного метода Oracle

ПРОЕКТИРОВАНИЕ ПО в зависимости от решаемой задачи включает в себя: построение не только функциональной, информационной, но и математической моделей задачи, разработку алгоритма.

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

МАТЕМАТИЧЕСКАЯ МОДЕЛЬ объекта позволяет поставить задачу математически и тем самым свести решение реальной задачи к решению задачи математической.

Построение математических моделей - целая наука. Будут также специальные дисциплины. Мы же пока должны усвоить, что построение математической модели реальной задачи состоит из трех основных этапов(шагов):

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

2) Определение того, что считается входными данными модели, а что выходными-результатами.

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