Методология жизненного цикла разработки системы

Две известные методологии в системном анализе и дизайне —

1. Метод структурированного системного анализа и проектирования (SSADM).

2. Объектно-ориентированный системный анализ и проектирование (OOSADM).

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

SSADM — подход к водопаду. Поддержание работоспособности является объективным. Помещение SSAD заключается в том, что если вы потратите больше средств на анализ и проектирование, то система будет стоить меньше затрат (компании тратят большую часть бюджета на техническое обслуживание) и меньше коррекции на весь срок службы. Он также занимается созданием ИС, который может развиваться вместе с потребностями бизнеса. Многие другие методологии взяты из SSAD, таких как разработка программ Jackson …

. Основная вещь, которую нужно сделать, — «Большая сложная программа разбита на многие более мелкие легко обрабатываемые». SDLC в целом сложна; он разбит на многие отдельные компоненты, такие как планирование, внедрение, анализ, проектирование, обслуживание. Опять же, эти компоненты разбиты на многие процедуры, такие как определение проблемы, ввод данных …

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

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

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

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

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

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

1. Сначала объекты идентифицируются. Объекты включают всех людей, состояние существ …

Пример. Объектами информационной системы колледжа являются студенты, преподаватели, менеджеры; не преподавательский состав … объекты в основном являются существительными

2. Каждый объект имеет свои свойства, называемые атрибутами. Атрибуты — это все аспекты, связанные с объектом.

Пример. Студенты изучают, преподаватели преподают, управление поддерживает колледж, это их атрибут.

3. Все идентифицированные объекты сгруппированы в классы, также называемые типами объектов.

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

4. Класс задан со стандартными свойствами, и все объекты этого класса могут наследовать свойства класса, в котором он является членом.

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

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

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

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

Пример — Управление наймом нового персонала, подготовка отчетов о студенческих оценках …

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

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

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

SDLC -advantage для менеджера проекта

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

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

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

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

1. Распознавание проблем

Новые системы будут созданы, когда менеджер почувствует, что

o Новый бизнес нуждается в IS.

o Уже существующие потребности в бизнесе IS Для его управления. Ex — бизнес с денежным кредитованием, где важна документация, после того, как какой-то этап бизнеса выйдет из ручного этапа, там используется IS.

o Существующие ИС недостаточны для управления его бизнесом. Ex-студент IS имеет вместимость 1000 учеников, уже 900 изучают, и теперь, если новые партии собираются присоединиться, необходимы поправки.

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

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

2. ТЭО

Уже проблема известна. В этой тестовой задаче четко определено и определено, возможна ли новая система, означает, можно ли ее построить или нет. Многие вещи играют важную роль в экономическом статусе, техническом статусе …

Аналитик точно отметит, что нужно новому IS или что является проблемой с существующим IS.

EX- В примере этого студента IS, если 1000 — это емкость и 900 занятий. Если новая партия поступит через 1 год, то IS на следующие 6 лет с мощностью 6000 должны быть сделаны за 1 год.

4 возможности должны быть проанализированы-

Технические. Если объекты в организации могут поддерживать IS или нет

Операционная работа. У организации есть человеческий источник для фактической установки и поддержки ИС.

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

Планирование — временные рамки, необходимые для построения ИС.

Ex- Before new студенты должны быть готовы.

Во-вторых, он должен бросить сценарий развития постпостановки, то есть ситуация после того, как IS построен

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

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

3. Анализ

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

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

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

o Спецификация проблемы

o Прототип.

Теперь все эти результаты предоставляются руководству для доступа к производительности. Руководство решает продолжить или прервать проект.

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

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

Итоги этой фазы —

o Проектная спецификация

o Документация по дизайну

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

5. Детальный дизайн

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

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

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

6. Техническое обслуживание

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

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *