![]() Главная страница Случайная страница КАТЕГОРИИ: АвтомобилиАстрономияБиологияГеографияДом и садДругие языкиДругоеИнформатикаИсторияКультураЛитератураЛогикаМатематикаМедицинаМеталлургияМеханикаОбразованиеОхрана трудаПедагогикаПолитикаПравоПсихологияРелигияРиторикаСоциологияСпортСтроительствоТехнологияТуризмФизикаФилософияФинансыХимияЧерчениеЭкологияЭкономикаЭлектроника |
Исследование
Приятная новость для всех, в ком погиб ученый-исследователь и первооткрыватель: для составления ТЗ вам предстоит изучить деятельность, которую вы собираетесь автоматизировать, зачастую лучше, чем те, кто её осуществляют. Крайне распространенный случай, когда программист после написания нескольких программ в какой-либо области становится специалистом уже не в программировании, а в той области, которую он автоматизировал. Что будем исследовать? Если вас позвали автоматизировать какой-то процесс - значит он уже работает, но без применения (или с минимальным использованием) компьютеров. " Процесс работает" - значит, есть какие-то регламенты. правила, описания технологических процессов, приказы, руководства и т.п., то есть - нормативные документы. В них многое написано. Кроме того, есть входящие и исходящие документы, как в печатном, так и в электронном виде, сообщения электронной почты, и т.д. и т.п., вкоторых явно просматривается структура данных. Именно разнообразные документы являются в данном случае объектом исследования. Предметом же исследования является состав данных в этих документах (для написания требований к данным), и регламент создания, передачи, изменения и уничтожения этих документов - для написания требований к интерфейсам программы и процессам обмена данными. Цитата из Мацяшека: " Изучение документов и программных систем является неоценимым методом выявления как требований, связанных с прецедентами использования, так и требований, относящихся к предметной области. Этот метод используется всегда, хотя он может касаться только отдельных сторон системы. Требования, связанные с прецедентами использования (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) Получение математических соотношений, связывающих выходные данные с входными с учетом принятых допущений и ограничений.
|