Análise e Design do Sistema - Guia Rápido

O desenvolvimento de sistemas é um processo sistemático que inclui fases como planejamento, análise, design, implantação e manutenção. Aqui, neste tutorial, vamos nos concentrar principalmente em -

• Análise de sistemas
• Projeto de sistemas

Análise de sistemas

É um processo de coleta e interpretação de fatos, identificação de problemas e decomposição de um sistema em seus componentes.

A análise do sistema é conduzida com o propósito de estudar um sistema ou suas partes, a fim de identificar seus objetivos. É uma técnica de solução de problemas que melhora o sistema e garante que todos os componentes do sistema funcionem de forma eficiente para cumprir seu propósito.

A análise especifica what the system should do.

Design de Sistemas

É um processo de planejamento de um novo sistema de negócios ou substituição de um sistema existente, definindo seus componentes ou módulos para satisfazer os requisitos específicos. Antes de planejar, você precisa entender o sistema antigo completamente e determinar como os computadores podem ser usados ​​da melhor maneira para operar com eficiência.

O Design do Sistema se concentra em how to accomplish the objective of the system.

Análise e Design de Sistema (SAD) se concentra principalmente em -

• Systems
• Processes
• Technology

O que é um sistema?

A palavra Sistema é derivada da palavra grega Systema, que significa um relacionamento organizado entre qualquer conjunto de componentes para alcançar alguma causa ou objetivo comum.

Um sistema é "um agrupamento ordenado de componentes interdependentes ligados entre si de acordo com um plano para atingir um objetivo específico."

Restrições de um sistema

Um sistema deve ter três restrições básicas -

• Um sistema deve ter algum structure and behavior que é projetado para atingir um objetivo predefinido.

• Interconnectivity e interdependence deve existir entre os componentes do sistema.

• o objectives of the organization tenha um higher priority do que os objetivos de seus subsistemas.

Por exemplo, sistema de gerenciamento de tráfego, sistema de folha de pagamento, sistema de biblioteca automática, sistema de informação de recursos humanos.

Propriedades de um sistema

Um sistema tem as seguintes propriedades -

Organização

Organização implica estrutura e ordem. É o arranjo de componentes que ajuda a atingir objetivos predeterminados.

Interação

É definido pela maneira como os componentes operam entre si.

Por exemplo, em uma organização, o departamento de compras deve interagir com o departamento de produção e a folha de pagamento com o departamento de pessoal.

Interdependência

Interdependência significa como os componentes de um sistema dependem uns dos outros. Para o funcionamento adequado, os componentes são coordenados e interligados de acordo com um plano especificado. A saída de um subsistema é exigida por outro subsistema como entrada.

Integração

A integração preocupa-se com a maneira como os componentes do sistema são conectados. Isso significa que as partes do sistema trabalham juntas dentro do sistema, mesmo que cada parte execute uma função exclusiva.

Objetivo Central

O objetivo do sistema deve ser central. Pode ser real ou declarado. Não é incomum para uma organização estabelecer um objetivo e operar para atingir outro.

Os usuários devem saber o objetivo principal de um aplicativo de computador no início da análise para um design e conversão bem-sucedidos.

Elementos de um sistema

O diagrama a seguir mostra os elementos de um sistema -

Saídas e Entradas

• O objetivo principal de um sistema é produzir uma saída que seja útil para o usuário.

• As entradas são as informações que entram no sistema para processamento.

• A saída é o resultado do processamento.

Processador (es)

• O processador é o elemento de um sistema que envolve a transformação real de entrada em saída.

• É o componente operacional de um sistema. Os processadores podem modificar a entrada total ou parcialmente, dependendo da especificação de saída.

• Conforme as especificações de saída mudam, o processamento também muda. Em alguns casos, a entrada também é modificada para permitir que o processador manipule a transformação.

Ao controle

• O elemento de controle guia o sistema.

• É o subsistema de tomada de decisão que controla o padrão de atividades que governam a entrada, o processamento e a saída.

• O comportamento de um sistema de computador é controlado pelo sistema operacional e software. A fim de manter o sistema em equilíbrio, o que e quanto input é necessário é determinado pelas Especificações de Saída.

Comentários

• O feedback fornece o controle em um sistema dinâmico.

• O feedback positivo é de rotina e incentiva o desempenho do sistema.

• O feedback negativo é de natureza informativa que fornece ao controlador informações para a ação.

Meio Ambiente

• O ambiente é o “supersistema” dentro do qual uma organização opera.

• É a fonte de elementos externos que atingem o sistema.

• Ele determina como um sistema deve funcionar. Por exemplo, fornecedores e concorrentes do ambiente da organização podem fornecer restrições que afetam o desempenho real do negócio.

Limites e interface

• Um sistema deve ser definido por seus limites. Fronteiras são os limites que identificam seus componentes, processos e inter-relacionamento quando faz interface com outro sistema.

• Cada sistema tem limites que determinam sua esfera de influência e controle.

• O conhecimento dos limites de um determinado sistema é crucial para determinar a natureza de sua interface com outros sistemas para um projeto bem-sucedido.

Tipos de sistemas

Os sistemas podem ser divididos nos seguintes tipos -

Sistemas Físicos ou Abstratos

• Os sistemas físicos são entidades tangíveis. Podemos tocá-los e senti-los.

• O sistema físico pode ser de natureza estática ou dinâmica. Por exemplo, mesas e cadeiras são as partes físicas do centro de informática que são estáticas. Um computador programado é um sistema dinâmico no qual programas, dados e aplicativos podem ser alterados de acordo com as necessidades do usuário.

• Sistemas abstratos são entidades não físicas ou conceituais que podem ser fórmulas, representação ou modelo de um sistema real.

Sistemas abertos ou fechados

• Um sistema aberto deve interagir com seu ambiente. Ele recebe entradas e fornece saídas para o exterior do sistema. Por exemplo, um sistema de informação que deve se adaptar às mudanças nas condições ambientais.

• Um sistema fechado não interage com seu ambiente. Ele está isolado das influências ambientais. Um sistema completamente fechado é raro na realidade.

Sistema Adaptativo e Não Adaptativo

• Adaptive System responde às mudanças no ambiente de forma a melhorar seu desempenho e sobreviver. Por exemplo, seres humanos, animais.

• Sistema não adaptativo é o sistema que não responde ao ambiente. Por exemplo, máquinas.

Sistema Permanente ou Temporário

• O Sistema Permanente persiste por muito tempo. Por exemplo, políticas de negócios.

• O Sistema Temporário é feito por tempo determinado e depois disso são demolidos. Por exemplo, um sistema de DJ é configurado para um programa e é desmontado após o programa.

Sistema Natural e Manufaturado

• Os sistemas naturais são criados pela natureza. Por exemplo, sistema solar, sistema sazonal.

• Sistema fabricado é o sistema feito pelo homem. Por exemplo, foguetes, barragens, trens.

Sistema Determinístico ou Probabilístico

• O sistema determinístico opera de maneira previsível e a interação entre os componentes do sistema é conhecida com certeza. Por exemplo, duas moléculas de hidrogênio e uma molécula de oxigênio produzem água.

• O sistema probabilístico mostra um comportamento incerto. A saída exata não é conhecida. Por exemplo, previsão do tempo, entrega de correio.

Sistema Social, Homem-Máquina, Máquina

• O sistema social é formado por pessoas. Por exemplo, clubes sociais, sociedades.

• No Sistema Homem-Máquina, humanos e máquinas estão envolvidos para realizar uma tarefa específica. Por exemplo, programação de computadores.

• O sistema da máquina é onde a interferência humana é negligenciada. Todas as tarefas são realizadas pela máquina. Por exemplo, um robô autônomo.

Sistemas de informação feitos pelo homem

• É um conjunto interconectado de recursos de informação para gerenciar dados de uma determinada organização, sob o Direct Management Control (DMC).

• Este sistema inclui hardware, software, comunicação, dados e aplicativos para a produção de informações de acordo com a necessidade de uma organização.

  Os sistemas de informação feitos pelo homem são divididos em três tipos -

• Formal Information System - Baseia-se no fluxo de informações na forma de memorandos, instruções, etc., do nível superior aos níveis inferiores de gestão.

• Informal Information System - Este é um sistema baseado em funcionários que resolve os problemas do dia a dia do trabalho.

• Computer Based System- Este sistema depende diretamente do computador para gerenciar aplicativos de negócios. Por exemplo, sistema de biblioteca automática, sistema de reserva ferroviária, sistema bancário, etc.

Modelos de Sistemas

Modelos Esquemáticos

• Um modelo esquemático é um gráfico 2-D que mostra os elementos do sistema e suas ligações.

• Setas diferentes são usadas para mostrar o fluxo de informações, fluxo de materiais e feedback de informações.

Modelos de sistema de fluxo

• Um modelo de sistema de fluxo mostra o fluxo ordenado de material, energia e informações que mantêm o sistema unido.

• A técnica de avaliação e revisão do programa (PERT), por exemplo, é usada para abstrair um sistema do mundo real na forma de modelo.

Modelos de sistema estático

• Eles representam um par de relacionamentos, como atividade-tempo ou custo-quantidade .

• O gráfico de Gantt, por exemplo, fornece uma imagem estática de uma relação atividade-tempo.

Modelos de Sistema Dinâmico

• As organizações empresariais são sistemas dinâmicos. Um modelo dinâmico aproxima o tipo de organização ou aplicativo com o qual os analistas lidam.

• Ele mostra um status do sistema em constante mudança. Consiste em -

  • Entradas que entram no sistema

  • O processador por meio do qual ocorre a transformação

  • O (s) programa (s) necessário (s) para o processamento

  • A (s) saída (s) que resultam do processamento.

Categorias de Informação

Existem três categorias de informações relacionadas aos níveis gerenciais e às decisões tomadas pelos gerentes.

Informação Estratégica

• Essas informações são exigidas pela alta administração para políticas de planejamento de longo prazo para os próximos anos. Por exemplo, tendências nas receitas, investimento financeiro e recursos humanos e crescimento populacional.

• Esse tipo de informação é obtido com o auxílio do Sistema de Apoio à Decisão (DSS).

Informação Gerencial

• Este tipo de informação é exigido pela média gerência para o planejamento de curto e médio prazo, que é em termos de meses. Por exemplo, análise de vendas, projeção de fluxo de caixa e demonstrações financeiras anuais.

• Isso é realizado com o auxílio de Sistemas de Informação Gerencial (MIS).

Informação operacional

• Esse tipo de informação é exigido pela baixa gestão para o planejamento diário e de curto prazo para reforçar as atividades operacionais do dia-a-dia. Por exemplo, manter registros de presença de funcionários, pedidos de compra em atraso e estoques atuais disponíveis.

• Isso é realizado com o auxílio de Sistemas de Processamento de Dados (DPS).

Um ciclo de vida de desenvolvimento de sistema (SDLC) eficaz deve resultar em um sistema de alta qualidade que atenda às expectativas do cliente, alcance a conclusão dentro das avaliações de tempo e custo e funcione de forma eficaz e eficiente na infraestrutura de Tecnologia da Informação atual e planejada.

Ciclo de vida de desenvolvimento de sistema (SDLC) é um modelo conceitual que inclui políticas e procedimentos para desenvolver ou alterar sistemas ao longo de seus ciclos de vida.

SDLC é usado por analistas para desenvolver um sistema de informação. SDLC inclui as seguintes atividades -

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

Fases de SDLC

O Ciclo de Vida de Desenvolvimento de Sistemas é uma abordagem sistemática que divide explicitamente o trabalho em fases que são necessárias para implementar um Sistema de Informação novo ou modificado.

Estudo de Viabilidade ou Planejamento

• Defina o problema e o escopo do sistema existente.

• Faça uma visão geral do novo sistema e determine seus objetivos.

• Confirme a viabilidade do projeto e produza o cronograma do projeto.

• Durante esta fase, ameaças, restrições, integração e segurança do sistema também são consideradas.

• Um relatório de viabilidade para todo o projeto é criado ao final desta fase.

Análise e Especificação

• Reúna, analise e valide as informações.

• Defina os requisitos e protótipos para o novo sistema.

• Avalie as alternativas e priorize os requisitos.

• Examine as necessidades de informação do usuário final e aprimore o objetivo do sistema.

• Um documento de Especificação de Requisitos de Software (SRS), que especifica os requisitos de software, hardware, funcionais e de rede do sistema, é preparado no final desta fase.

Projeto de sistema

• Inclui o design de aplicativos, rede, bancos de dados, interfaces de usuário e interfaces de sistema.

• Transforme o documento SRS em uma estrutura lógica, que contém um conjunto detalhado e completo de especificações que podem ser implementadas em uma linguagem de programação.

• Crie um plano de contingência, treinamento, manutenção e operação.

• Revise o design proposto. Certifique-se de que o projeto final deve atender aos requisitos declarados no documento SRS.

• Finalmente, prepare um documento de design que será usado nas próximas fases.

Implementação

• Implemente o design no código-fonte por meio da codificação.

• Combine todos os módulos em um ambiente de treinamento que detecta erros e defeitos.

• Um relatório de teste que contém erros é preparado por meio de um plano de teste que inclui tarefas relacionadas ao teste, como geração de casos de teste, critérios de teste e alocação de recursos para teste.

• Integre o sistema de informação em seu ambiente e instale o novo sistema.

Manutenção / Suporte

• Inclui todas as atividades, como suporte por telefone ou suporte físico no local para usuários, que é necessário após a instalação do sistema.

• Implemente as mudanças pelas quais o software pode passar durante um período de tempo ou implemente quaisquer novos requisitos depois que o software for implantado no local do cliente.

• Também inclui lidar com os erros residuais e resolver quaisquer problemas que possam existir no sistema, mesmo após a fase de teste.

• A manutenção e o suporte podem ser necessários por mais tempo para sistemas grandes e por pouco tempo para sistemas menores.

Ciclo de vida da análise e design do sistema

O diagrama a seguir mostra o ciclo de vida completo do sistema durante a fase de análise e design.

Papel do Analista de Sistema

O analista de sistema é uma pessoa que está totalmente ciente do sistema e orienta o projeto de desenvolvimento do sistema dando as instruções adequadas. Ele é um especialista com habilidades técnicas e interpessoais para realizar as tarefas de desenvolvimento exigidas em cada fase.

Ele busca combinar os objetivos do sistema de informação com a meta da organização.

Principais funções

• Definir e compreender os requisitos do usuário por meio de várias técnicas de descoberta de fatos.

• Priorizando os requisitos obtendo consenso do usuário.

• Coleta os fatos ou informações e adquire as opiniões dos usuários.

• Mantém análise e avaliação para chegar a um sistema adequado e mais amigável.

• Sugere muitas soluções alternativas flexíveis, escolha a melhor solução e quantifique custos e benefícios.

• Desenhe certas especificações que são facilmente entendidas por usuários e programadores de forma precisa e detalhada.

• Implementado o projeto lógico do sistema que deve ser modular.

• Planeje a periodicidade da avaliação após ter sido usada por algum tempo e modifique o sistema conforme necessário.

Atributos de um analista de sistemas

A figura a seguir mostra os atributos que um analista de sistemas deve possuir -

Habilidades interpessoais

• Interface com usuários e programador.
• Facilite grupos e lidere equipes menores.
• Gerenciando expectativas.
• Boa capacidade de compreensão, comunicação, vendas e ensino.
• Motivador com confiança para solucionar dúvidas.

Habilidades analíticas

• Estudo do sistema e conhecimento organizacional
• Identificação de problemas, análise de problemas e solução de problemas
• Bom senso comum
• Capacidade de acessar trade-off
• Curiosidade para aprender sobre a nova organização

Habilidades gerenciais

• Compreenda o jargão e as práticas dos usuários.
• Gerenciamento de recursos e projetos.
• Gerenciamento de mudanças e riscos.
• Compreenda completamente as funções de gerenciamento.

Habilidades técnicas

• Conhecimento de computadores e software.
• Mantenha-se atualizado com o desenvolvimento moderno.
• Conhecer ferramentas de design de sistema.
• Amplo conhecimento sobre novas tecnologias.

O que é determinação de requisitos?

Um requisito é uma característica vital de um novo sistema que pode incluir processamento ou captura de dados, controle das atividades do negócio, produção de informação e suporte à gestão.

A determinação de requisitos envolve estudar o sistema existente e reunir detalhes para descobrir quais são os requisitos, como funcionam e onde as melhorias devem ser feitas.

Principais atividades na determinação de requisitos

Antecipação de Requisitos

• Ele prevê as características do sistema com base na experiência anterior, que inclui certos problemas ou recursos e requisitos para um novo sistema.

• Pode levar à análise de áreas que, de outra forma, passariam despercebidas por analistas inexperientes. Mas se atalhos são tomados e preconceitos são introduzidos na condução da investigação, então a Antecipação de requisitos pode ser incompleta.

Investigação de Requisitos

• Ele está estudando o sistema atual e documentando seus recursos para análise posterior.

• É o centro da análise do sistema, onde o analista documenta e descreve os recursos do sistema usando técnicas de descoberta de fatos, prototipagem e ferramentas assistidas por computador.

Especificações de Requisitos

• Inclui a análise dos dados que determinam a especificação dos requisitos, a descrição dos recursos do novo sistema e a especificação de quais requisitos de informações serão fornecidos.

• Inclui análise de dados factuais, identificação de requisitos essenciais e seleção de estratégias de atendimento de requisitos.

Técnicas de coleta de informações

O principal objetivo das técnicas de descoberta de fatos é determinar os requisitos de informação de uma organização usados ​​por analistas para preparar um SRS preciso compreendido pelo usuário.

O documento SRS ideal deve -

• ser completo, inequívoco e sem jargões.
• especificar requisitos de informações operacionais, táticos e estratégicos.
• resolver possíveis disputas entre usuários e analista.
• use recursos gráficos que simplificam a compreensão e o design.

Existem várias técnicas de coleta de informações -

Entrevistando

O analista de sistemas coleta informações de indivíduos ou grupos por meio de entrevistas. O analista pode ser formal, legalista, brincalhão de política ou informal; já que o sucesso de uma entrevista depende da habilidade do analista como entrevistador.

Isso pode ser feito de duas maneiras -

• Unstructured Interview - O analista de sistema conduz uma sessão de perguntas e respostas para adquirir informações básicas do sistema.

• Structured Interview - Possui perguntas padrão que o usuário precisa responder em formato fechado (objetivo) ou aberto (descritivo).

Advantages of Interviewing

• Este método é freqüentemente a melhor fonte de coleta de informações qualitativas.

• É útil para eles, que não se comunicam bem por escrito ou que podem não ter tempo para preencher o questionário.

• As informações podem ser facilmente validadas e verificadas imediatamente.

• Ele pode lidar com assuntos complexos.

• É fácil descobrir o problema principal buscando opiniões.

• Ele preenche as lacunas nas áreas de mal-entendidos e minimiza problemas futuros.

Questionários

Este método é usado pelo analista para reunir informações sobre vários problemas do sistema de um grande número de pessoas.

Existem dois tipos de questionários -

• Open-ended Questionnaires- É composto por questões que podem ser interpretadas de forma fácil e correta. Eles podem explorar um problema e levar a uma direção específica de resposta.

• Closed-ended Questionnaires - Consiste em perguntas que são utilizadas quando o analista de sistemas lista efetivamente todas as respostas possíveis, que são mutuamente exclusivas.

Advantages of questionnaires

• É muito eficaz no levantamento de interesses, atitudes, sentimentos e crenças dos usuários que não estão co-localizados.

• É útil saber que proporção de um determinado grupo aprova ou desaprova um determinado recurso do sistema proposto.

• É útil determinar a opinião geral antes de dar qualquer direção específica ao projeto do sistema.

• É mais confiável e fornece alta confidencialidade de respostas honestas.

• É apropriado para a seleção de informações factuais e para a coleta de dados estatísticos que podem ser enviados por e-mail e pelo correio.

Revisão de registros, procedimentos e formulários

A revisão dos registros, procedimentos e formulários existentes ajuda a buscar informações sobre um sistema que descreve os recursos do sistema atual, suas operações ou atividades.

Advantages

• Ele ajuda o usuário a obter algum conhecimento sobre a organização ou as operações por si mesmos, antes de impor aos outros.

• Ele ajuda a documentar as operações atuais em um curto espaço de tempo, pois os manuais e formulários de procedimento descrevem o formato e as funções do sistema atual.

• Ele pode fornecer um entendimento claro sobre as transações que são tratadas na organização, identificando entradas para processamento e avaliando o desempenho.

• Pode ajudar um analista a entender o sistema em termos das operações que devem ser suportadas.

• Ele descreve o problema, suas partes afetadas e a solução proposta.

Observação

Este é um método de coleta de informações observando e observando as pessoas, eventos e objetos. O analista visita a organização para observar o funcionamento do sistema atual e entender os requisitos do sistema.

Advantages

• É um método direto para coletar informações.

• É útil em situações em que a autenticidade dos dados coletados está em questão ou quando a complexidade de certos aspectos do sistema impede uma explicação clara por parte dos usuários finais.

• Ele produz dados mais precisos e confiáveis.

• Ele produz todos os aspectos da documentação que estão incompletos e desatualizados.

Desenvolvimento de aplicativos conjuntos (JAD)

É uma nova técnica desenvolvida pela IBM que traz proprietários, usuários, analistas, designers e construtores para definir e projetar o sistema usando workshops organizados e intensivos. O analista treinado pela JAD atua como facilitador do workshop e possui algumas habilidades especializadas.

Advantages of JAD

• Isso economiza tempo e custos ao substituir meses de entrevistas tradicionais e reuniões de acompanhamento.

• É útil na cultura organizacional que apóia a resolução conjunta de problemas.

• Promove relacionamentos formais entre vários níveis de funcionários.

• Pode levar ao desenvolvimento do design de forma criativa.

• Permite rápido desenvolvimento e melhora a propriedade do sistema de informação.

Pesquisa secundária ou leitura de fundo

Este método é amplamente utilizado para coleta de informações, acessando as informações coletadas. Inclui todas as informações coletadas anteriormente usadas pelo comerciante de qualquer fonte interna ou externa.

Advantages

• O acesso é mais aberto com a disponibilidade de internet.

• Ele fornece informações valiosas com baixo custo e tempo.

• Ele atua como um precursor da pesquisa primária e alinha o foco da pesquisa primária.

• É usado pelo pesquisador para concluir se a pesquisa vale a pena, pois está disponível com os procedimentos usados ​​e as questões na coleta deles.

Estudo de viabilidade

O Estudo de Viabilidade pode ser considerado uma investigação preliminar que auxilia a administração na tomada de decisão sobre se o estudo do sistema deve ser viável para desenvolvimento ou não.

• Ele identifica a possibilidade de melhorar um sistema existente, desenvolver um novo sistema e produzir estimativas refinadas para o desenvolvimento posterior do sistema.

• É usado para obter o esboço do problema e decidir se existe ou não uma solução viável ou apropriada.

• O principal objetivo de um estudo de viabilidade é adquirir o escopo do problema em vez de resolvê-lo.

• O resultado de um estudo de viabilidade é um ato formal de proposta de sistema como documento de decisão que inclui a natureza e o escopo completos do sistema proposto.

Etapas envolvidas na análise de viabilidade

As seguintes etapas devem ser seguidas durante a realização da análise de viabilidade -

• Forme uma equipe de projeto e indique um líder de projeto.

• Desenvolva fluxogramas do sistema.

• Identifique as deficiências do sistema atual e estabeleça metas.

• Enumere a solução alternativa ou o sistema candidato potencial para atender às metas.

• Determine a viabilidade de cada alternativa, como viabilidade técnica, viabilidade operacional, etc.

• Avalie o desempenho e a economia de cada sistema candidato.

• Classifique as outras alternativas e selecione o melhor sistema candidato.

• Preparar uma proposta de sistema de diretiva final de projeto para a gerência para aprovação.

Tipos de viabilidades

Viabilidade economica

• É avaliar a eficácia do sistema candidato usando o método de análise de custo / benefício.

• Ele demonstra o benefício líquido do sistema candidato em termos de benefícios e custos para a organização.

• O principal objetivo da Análise de Viabilidade Econômica (EFS) é estimar os requisitos econômicos do sistema candidato antes que os fundos de investimento sejam comprometidos com a proposta.

• Ele prefere a alternativa que maximizará o valor líquido da organização pelo retorno mais rápido e mais alto dos fundos, juntamente com o nível mais baixo de risco envolvido no desenvolvimento do sistema candidato.

Viabilidade técnica

• Investiga a viabilidade técnica de cada alternativa de implementação.

• Ele analisa e determina se a solução pode ser suportada pela tecnologia existente ou não.

• O analista determina se os recursos técnicos atuais serão atualizados ou adicionados para atender aos novos requisitos.

• Ele garante que o sistema candidato forneça respostas apropriadas até que ponto ele pode suportar o aprimoramento técnico.

Viabilidade Operacional

• Ele determina se o sistema está operando de forma eficaz depois de desenvolvido e implementado.

• Assegura que a gestão deve apoiar o sistema proposto e sua viabilidade de funcionamento no ambiente organizacional atual.

• Ele analisa se os usuários serão afetados e eles aceitam os métodos de negócios modificados ou novos que afetam os possíveis benefícios do sistema.

• Também garante que os recursos do computador e a arquitetura de rede do sistema candidato sejam viáveis.

Viabilidade Comportamental

• Ele avalia e estima a atitude ou comportamento do usuário em relação ao desenvolvimento de um novo sistema.

• Ajuda a determinar se o sistema requer esforço especial para educar, retreinar, transferir e mudanças no status de trabalho do funcionário sobre novas maneiras de conduzir os negócios.

Viabilidade do cronograma

• Isso garante que o projeto seja concluído dentro de uma determinada restrição de tempo ou cronograma.

• Também verifica e valida se os prazos do projeto são razoáveis ​​ou não.

Os analistas usam várias ferramentas para compreender e descrever o sistema de informações. Uma das maneiras é usar a análise estruturada.

O que é análise estruturada?

A Análise Estruturada é um método de desenvolvimento que permite ao analista compreender o sistema e suas atividades de forma lógica.

É uma abordagem sistemática, que usa ferramentas gráficas que analisam e refinam os objetivos de um sistema existente e desenvolvem uma nova especificação de sistema que pode ser facilmente compreendida pelo usuário.

Possui os seguintes atributos -

• É um gráfico que especifica a apresentação do aplicativo.

• Ele divide os processos de forma a dar uma imagem clara do fluxo do sistema.

• É mais lógico do que físico, ou seja, os elementos do sistema não dependem do fornecedor ou do hardware.

• É uma abordagem que funciona desde visões gerais de alto nível até detalhes de nível inferior.

Ferramentas de análise estruturada

Durante a Análise Estruturada, várias ferramentas e técnicas são usadas para o desenvolvimento do sistema. Eles são -

• Diagramas de fluxo de dados
• Dicionário de dados
• Árvores de decisão
• Tabelas de Decisão
• Inglês Estruturado
• Pseudocode

Diagramas de fluxo de dados (DFD) ou gráfico de bolhas

É uma técnica desenvolvida por Larry Constantine para expressar os requisitos do sistema de forma gráfica.

• Mostra o fluxo de dados entre várias funções do sistema e especifica como o sistema atual é implementado.

• É um estágio inicial da fase de design que divide funcionalmente as especificações dos requisitos até o nível de detalhe mais baixo.

• Sua natureza gráfica o torna uma boa ferramenta de comunicação entre usuário e analista ou analista e designer de sistema.

• Ele fornece uma visão geral de quais dados um sistema processa, quais transformações são realizadas, quais dados são armazenados, quais resultados são produzidos e para onde fluem.

Elementos básicos do DFD

O DFD é fácil de entender e bastante eficaz quando o design necessário não é claro e o usuário deseja uma linguagem de notação para comunicação. Entretanto, requer um grande número de iterações para obter a solução mais precisa e completa.

A tabela a seguir mostra os símbolos usados ​​na concepção de um DFD e seu significado -

Nome do Símbolo	Símbolo	Significado
Quadrado		Fonte ou destino dos dados
Seta		Fluxo de dados
Círculo		Processo de transformação do fluxo de dados
Retângulo Aberto		Banco de dados

Tipos de DFD

Os DFDs são de dois tipos: DFD físico e DFD lógico. A tabela a seguir lista os pontos que diferenciam um DFD físico de um DFD lógico.

DFD físico	DFD lógico
É dependente da implementação. Mostra quais funções são executadas.	É independente de implementação. Ele se concentra apenas no fluxo de dados entre os processos.
Ele fornece detalhes de baixo nível de hardware, software, arquivos e pessoas.	Ele explica eventos de sistemas e dados exigidos por cada evento.
Ele descreve como o sistema atual opera e como um sistema será implementado.	Mostra como os negócios funcionam; não como o sistema pode ser implementado.

Diagrama de Contexto

Um diagrama de contexto ajuda a compreender todo o sistema por um DFD que dá a visão geral de um sistema. Ele começa mencionando os processos principais com poucos detalhes e, em seguida, fornece mais detalhes dos processos com a abordagem de cima para baixo.

O diagrama de contexto do gerenciamento de mensagens é mostrado abaixo.

Dicionário de dados

Um dicionário de dados é um repositório estruturado de elementos de dados no sistema. Ele armazena as descrições de todos os elementos de dados DFD, ou seja, detalhes e definições de fluxos de dados, armazenamentos de dados, dados armazenados em armazenamentos de dados e os processos.

Um dicionário de dados melhora a comunicação entre o analista e o usuário. Ele desempenha um papel importante na construção de um banco de dados. A maioria dos DBMSs tem um dicionário de dados como recurso padrão. Por exemplo, consulte a seguinte tabela -

Sr. Não.	Nome de Dados	Descrição	No. de personagens
1	ISBN	Número ISBN	10
2	TÍTULO	título	60
3	SUB	Assuntos de livros	80
4	UM NOME	Nome do autor	15

Árvores de decisão

Árvores de decisão são um método para definir relacionamentos complexos, descrevendo as decisões e evitando os problemas de comunicação. Uma árvore de decisão é um diagrama que mostra ações e condições alternativas dentro da estrutura de árvore horizontal. Assim, ele descreve quais condições considerar primeiro, segundo e assim por diante.

As árvores de decisão representam a relação de cada condição e suas ações permitidas. Um nó quadrado indica uma ação e um círculo indica uma condição. Força os analistas a considerar a sequência de decisões e identifica a decisão real que deve ser tomada.

A principal limitação de uma árvore de decisão é que ela carece de informações em seu formato para descrever quais outras combinações de condições você pode usar para teste. É uma representação única das relações entre condições e ações.

Por exemplo, consulte a seguinte árvore de decisão -

Tabelas de Decisão

As tabelas de decisão são um método de descrever o relacionamento lógico complexo de uma maneira precisa e facilmente compreensível.

• É útil em situações em que as ações resultantes dependem da ocorrência de uma ou várias combinações de condições independentes.

• É uma matriz que contém linhas ou colunas para definir um problema e as ações.

Componentes de uma mesa de decisão

• Condition Stub - É no quadrante superior esquerdo que lista todas as condições a serem verificadas.

• Action Stub - É no quadrante inferior esquerdo que delineia todas as ações a serem realizadas para atender tal condição.

• Condition Entry - Está no quadrante superior direito que fornece respostas às perguntas feitas no quadrante stub de condição.

• Action Entry - Está no quadrante inferior direito que indica a ação apropriada resultante das respostas às condições no quadrante de entrada da condição.

As entradas na tabela de decisão são fornecidas por Regras de Decisão que definem as relações entre combinações de condições e cursos de ação. Na seção de regras,

• Y mostra a existência de uma condição.
• N representa a condição, que não é satisfeita.
• Uma ação em branco contra afirma que deve ser ignorada.
• X (ou uma marca de verificação serve) contra os estados de ação que devem ser executados.

Por exemplo, consulte a seguinte tabela -

CONDIÇÕES	Regra 1	Regra 2	Regra 3	Regra 4
Pagamento antecipado feito	Y	N	N	N
Valor da compra = Rs 10.000 / -	-	Y	Y	N
Cliente regular	-	Y	N	-
ACTIONS
Dê 5% de desconto	X	X	-	-
Não dê desconto	-	-	X	X

Inglês Estruturado

Estrutura O inglês é derivado de uma linguagem de programação estruturada que fornece uma descrição mais compreensível e precisa do processo. É baseado na lógica procedimental que usa construção e sentenças imperativas projetadas para realizar operação para ação.

• É melhor usado quando sequências e loops em um programa devem ser considerados e o problema precisa de sequências de ações com decisões.

• Não possui regra de sintaxe estrita. Ele expressa toda a lógica em termos de estruturas de decisão sequenciais e iterações.

Por exemplo, veja a seguinte sequência de ações -

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

Pseudo-código

Um pseudocódigo não está em conformidade com nenhuma linguagem de programação e expressa a lógica em inglês simples.

• Ele pode especificar a lógica de programação física sem codificação real durante e após o design físico.

• É usado em conjunto com a programação estruturada.

• Ele substitui os fluxogramas de um programa.

Diretrizes para selecionar ferramentas apropriadas

Use as seguintes diretrizes para selecionar a ferramenta mais apropriada que atenderia aos seus requisitos -

• Use o DFD em análises de alto ou baixo nível para fornecer boas documentações do sistema.

• Use o dicionário de dados para simplificar a estrutura para atender aos requisitos de dados do sistema.

• Use inglês estruturado se houver muitos loops e as ações forem complexas.

• Use tabelas de decisão quando houver um grande número de condições a serem verificadas e a lógica for complexa.

• Use árvores de decisão quando o sequenciamento das condições for importante e se houver poucas condições a serem testadas.

System designé a fase que preenche a lacuna entre o domínio do problema e o sistema existente de uma forma gerenciável. Esta fase se concentra no domínio da solução, ou seja, "como implementar?"

É a fase em que o documento SRS é convertido em um formato que pode ser implementado e decide como o sistema irá operar.

Nesta fase, a complexa atividade de desenvolvimento do sistema é dividida em várias subatividades menores, que se coordenam entre si para atingir o objetivo principal do desenvolvimento do sistema.

Entradas para o projeto do sistema

O design do sistema leva as seguintes entradas -

• Declaração de trabalho

• Plano de determinação de requisitos

• Análise da situação atual

• Requisitos de sistema propostos, incluindo um modelo de dados conceituais, DFDs modificados e metadados (dados sobre dados).

Saídas para Design de Sistema

O projeto do sistema fornece os seguintes resultados -

• Infraestrutura e mudanças organizacionais para o sistema proposto.

• Um esquema de dados, geralmente um esquema relacional.

• Metadados para definir as tabelas / arquivos e colunas / itens de dados.

• Um diagrama de hierarquia de funções ou mapa de página da web que descreve graficamente a estrutura do programa.

• Real ou pseudocódigo para cada módulo do programa.

• Um protótipo para o sistema proposto.

Tipos de projeto de sistema

Design Lógico

O design lógico refere-se a uma representação abstrata do fluxo de dados, entradas e saídas do sistema. Ele descreve as entradas (fontes), saídas (destinos), bancos de dados (armazenamentos de dados), procedimentos (fluxos de dados), tudo em um formato que atenda aos requisitos do usuário.

Ao preparar o design lógico de um sistema, o analista de sistema especifica as necessidades do usuário em nível de detalhe que virtualmente determina o fluxo de informações para dentro e para fora do sistema e as fontes de dados necessárias. Diagrama de fluxo de dados, modelagem de diagrama ER são usados.

Desenho Físico

O projeto físico está relacionado aos processos reais de entrada e saída do sistema. Ele se concentra em como os dados são inseridos em um sistema, verificados, processados ​​e exibidos como saída.

Ele produz o sistema de trabalho definindo a especificação de design que especifica exatamente o que o sistema candidato faz. Ele se preocupa com o design da interface do usuário, design de processos e design de dados.

Consiste nas seguintes etapas -

• Especificando a mídia de entrada / saída, projetando o banco de dados e especificando procedimentos de backup.

• Implementação do sistema de planejamento.

• Elaborar um plano de teste e implementação e especificar qualquer novo hardware e software.

• Atualizando custos, benefícios, datas de conversão e restrições do sistema.

Projeto arquitetônico

Também é conhecido como design de alto nível que se concentra no design da arquitetura do sistema. Ele descreve a estrutura e o comportamento do sistema. Ele define a estrutura e o relacionamento entre vários módulos do processo de desenvolvimento do sistema.

Projeto Detalhado

Ele segue o projeto arquitetônico e se concentra no desenvolvimento de cada módulo.

Modelagem de Dados Conceituais

É a representação de dados organizacionais que incluem todas as principais entidades e relacionamentos. Os analistas de sistema desenvolvem um modelo conceitual de dados para o sistema atual que suporta o escopo e os requisitos do sistema proposto.

O principal objetivo da modelagem conceitual de dados é capturar o máximo de significado possível dos dados. A maioria das organizações hoje usa modelagem de dados conceituais usando o modelo ER que usa notação especial para representar o máximo possível de significado sobre os dados.

Modelo de relacionamento de entidade

É uma técnica usada no design de banco de dados que ajuda a descrever o relacionamento entre várias entidades de uma organização.

Termos usados ​​no modelo ER

• ENTITY- Ele especifica itens distintos do mundo real em um aplicativo. Por exemplo: fornecedor, item, aluno, curso, professores, etc.

• RELATIONSHIP- Eles são as dependências significativas entre entidades. Por exemplo, itens de suprimentos de fornecedores, professores ministram cursos e, em seguida, suprimentos e cursos são relacionamento.

• ATTRIBUTES- Ele especifica as propriedades dos relacionamentos. Por exemplo, código do fornecedor, nome do aluno. Símbolos usados ​​no modelo ER e seus respectivos significados -

A tabela a seguir mostra os símbolos usados ​​no modelo ER e seu significado -

Símbolo	Significado
	Entidade
	Entidade Fraca
	Relação
	Relacionamento de Identidade
	Atributos
	Chaves de atributo
	Multivalorado
	Atributo Composto
	Atributos Derivados
	Participação total de E2 em R
	Razão de cardinalidade 1: N para E1: E2 em R

Podem existir três tipos de relacionamento entre dois conjuntos de dados: um para um, um para muitos e muitos para muitos.

Organização de Arquivos

Ele descreve como os registros são armazenados em um arquivo.

Existem quatro métodos de organização de arquivos -

• Serial - Os registros são armazenados em ordem cronológica (na ordem em que são inseridos ou ocorrem). Examples - Gravação de tarifas telefônicas, transações em caixas eletrônicos, filas telefônicas.

• Sequential - Os registros são armazenados em ordem com base em um campo-chave que contém um valor que identifica exclusivamente um registro. Examples - Diretórios telefônicos.

• Direct (relative)- Cada registro é armazenado com base em um endereço físico ou localização no dispositivo. O endereço é calculado a partir do valor armazenado no campo-chave do registro. A rotina de randomização ou algoritmo de hash faz a conversão.

• Indexed - Os registros podem ser processados ​​tanto sequencialmente quanto não sequencialmente usando índices.

Comparação

Acesso ao arquivo

Pode-se acessar um arquivo usando o Acesso Sequencial ou o Acesso Aleatório. Os métodos de acesso a arquivos permitem que os programas de computador leiam ou gravem registros em um arquivo.

Acesso Sequencial

Cada registro no arquivo é processado começando com o primeiro registro até que o Fim do Arquivo (EOF) seja alcançado. É eficiente quando um grande número de registros no arquivo precisa ser acessado a qualquer momento. Os dados armazenados em uma fita (acesso sequencial) podem ser acessados ​​apenas sequencialmente.

Acesso direto (aleatório)

Os registros são localizados sabendo-se suas localizações físicas ou endereços no dispositivo, em vez de suas posições em relação a outros registros. Os dados armazenados em um dispositivo de CD (acesso direto) podem ser acessados ​​sequencialmente ou aleatoriamente.

Tipos de arquivos usados ​​em um sistema de organização

A seguir estão os tipos de arquivos usados ​​em um sistema de organização -

• Master file- Contém as informações atuais de um sistema. Por exemplo, arquivo do cliente, arquivo do aluno, lista telefônica.

• Table file- É um tipo de arquivo mestre que muda raramente e é armazenado em um formato tabular. Por exemplo, armazenar o CEP.

• Transaction file- Contém as informações do dia-a-dia geradas nas atividades comerciais. Ele é usado para atualizar ou processar o arquivo mestre. Por exemplo, endereços dos funcionários.

• Temporary file - É criado e usado sempre que necessário por um sistema.

• Mirror file- Eles são as duplicatas exatas de outros arquivos. Ajude a minimizar o risco de tempo de inatividade nos casos em que o original se tornar inutilizável. Eles devem ser modificados cada vez que o arquivo original for alterado.

• Log files- Eles contêm cópias dos registros mestre e de transação para registrar todas as alterações feitas no arquivo mestre. Facilita a auditoria e fornece mecanismo de recuperação em caso de falha do sistema.

• Archive files - Arquivos de backup que contêm versões históricas de outros arquivos.

Controle de Documentação

A documentação é um processo de registro das informações para qualquer referência ou propósito operacional. Ajuda usuários, gerentes e equipe de TI que precisam. É importante que o documento preparado seja atualizado regularmente para rastrear facilmente o progresso do sistema.

Após a implantação do sistema, se o sistema estiver funcionando incorretamente, a documentação ajuda o administrador a entender o fluxo de dados no sistema para corrigir as falhas e fazer o sistema funcionar.

Os programadores ou analistas de sistemas geralmente criam a documentação do programa e do sistema. Os analistas de sistemas geralmente são responsáveis ​​por preparar a documentação para ajudar os usuários a aprender o sistema. Em grandes empresas, uma equipe de suporte técnico que inclui redatores técnicos pode auxiliar na preparação da documentação do usuário e dos materiais de treinamento.

Vantagens

• Pode reduzir o tempo de inatividade do sistema, cortar custos e acelerar as tarefas de manutenção.

• Ele fornece uma descrição clara do fluxo formal do sistema atual e ajuda a entender o tipo de dados de entrada e como a saída pode ser produzida.

• Ele fornece uma forma eficaz e eficiente de comunicação entre usuários técnicos e não técnicos sobre o sistema.

• Facilita o treinamento do novo usuário para que ele possa entender facilmente o fluxo do sistema.

• Auxilia o usuário na solução de problemas como solução de problemas e auxilia o gestor a tomar melhores decisões finais do sistema organizacional.

• Ele fornece melhor controle para o funcionamento interno ou externo do sistema.

Tipos de Documentação

Quando se trata de Design do Sistema, existem quatro documentações principais a seguir -

• Documentação do programa
• Documentação do sistema
• Documentação de operações
• Documentação do usuário

Documentação do programa

• Ele descreve entradas, saídas e lógica de processamento para todos os módulos do programa.

• O processo de documentação do programa começa na fase de análise do sistema e continua durante a implementação.

• Esta documentação orienta os programadores, que constroem módulos que são bem suportados por comentários internos e externos e descrições que podem ser compreendidos e mantidos facilmente.

Documentação de Operações

A documentação de operações contém todas as informações necessárias para o processamento e distribuição da saída online e impressa. A documentação de operações deve ser clara, concisa e disponível online, se possível.

Inclui as seguintes informações -

• Programa, analista de sistemas, programador e identificação do sistema.

• Informações de programação para saída impressa, como relatório, frequência de execução e prazos.

• Arquivos de entrada, sua origem, arquivos de saída e seus destinos.

• E-mail e listas de distribuição de relatórios.

• Formulários especiais necessários, incluindo formulários online.

• Mensagens de erro e informativas para operadores e procedimentos de reinicialização.

• Instruções especiais, como requisitos de segurança.

Documentação do usuário

Inclui instruções e informações aos usuários que irão interagir com o sistema. Por exemplo, manuais do usuário, guias de ajuda e tutoriais. A documentação do usuário é valiosa no treinamento de usuários e para fins de referência. Deve ser claro, compreensível e facilmente acessível aos usuários em todos os níveis.

Os usuários, proprietários de sistemas, analistas e programadores, todos colocaram esforços combinados para desenvolver um guia do usuário.

A documentação do usuário deve incluir -

• Uma visão geral do sistema que descreve claramente todos os principais recursos, capacidades e limitações do sistema.

• Descrição do conteúdo do documento de origem, preparação, processamento e amostras.

• Visão geral do menu e opções de tela de entrada de dados, conteúdo e instruções de processamento.

• Exemplos de relatórios produzidos regularmente ou disponíveis a pedido do usuário, incluindo amostras.

• Segurança e informações de trilha de auditoria.

• Explicação da responsabilidade por requisitos específicos de entrada, saída ou processamento.

• Procedimentos para solicitar mudanças e relatar problemas.

• Exemplos de exceções e situações de erro.

• Perguntas mais frequentes (FAQs).

• Explicação de como obter ajuda e procedimentos para atualizar o manual do usuário.

Documentação do sistema

A documentação do sistema serve como especificações técnicas para o SI e como os objetivos do SI são alcançados. Usuários, gerentes e proprietários de SI nunca precisam consultar a documentação do sistema. A documentação do sistema fornece a base para a compreensão dos aspectos técnicos do SI quando as modificações são feitas.

• Ele descreve cada programa dentro do SI e todo o SI em si.

• Ele descreve as funções do sistema, a maneira como são implementadas, o propósito de cada programa em todo o SI com relação à ordem de execução, as informações passadas de e para os programas e o fluxo geral do sistema.

• Inclui entradas de dicionário de dados, diagramas de fluxo de dados, modelos de objetos, layouts de tela, documentos de origem e a solicitação de sistema que iniciou o projeto.

• A maior parte da documentação do sistema é preparada durante as fases de análise e projeto do sistema.

• Durante a implementação dos sistemas, um analista deve revisar a documentação do sistema para verificar se está completa, precisa e atualizada, incluindo todas as alterações feitas durante o processo de implementação.

Estratégia de cima para baixo

A estratégia de cima para baixo usa a abordagem modular para desenvolver o design de um sistema. É assim chamado porque começa do módulo de nível superior ou de nível mais alto e segue em direção aos módulos de nível mais baixo.

Nesta técnica, o módulo de nível mais alto ou módulo principal para desenvolver o software é identificado. O módulo principal é dividido em vários submódulos ou segmentos menores e mais simples com base na tarefa executada por cada módulo. Então, cada submódulo é subdividido em vários submódulos do próximo nível inferior. Este processo de divisão de cada módulo em vários submódulos continua até que os módulos de nível mais baixo, que não podem ser subdivididos posteriormente, não sejam identificados.

Estratégia Bottom-Up

A Estratégia Bottom-Up segue a abordagem modular para desenvolver o design do sistema. É assim chamado porque começa a partir dos módulos de nível inferior ou mais básico e avança para os módulos de nível mais alto.

Nesta técnica,

• Os módulos no nível mais básico ou mais baixo são identificados.

• Esses módulos são agrupados com base na função executada por cada módulo para formar os próximos módulos de nível superior.

• Em seguida, esses módulos são combinados para formar os próximos módulos de nível superior.

• Este processo de agrupar vários módulos mais simples para formar módulos de nível superior continua até que o módulo principal do processo de desenvolvimento do sistema seja alcançado.

Projeto Estruturado

O projeto estruturado é uma metodologia baseada em fluxo de dados que ajuda a identificar a entrada e a saída do sistema em desenvolvimento. O principal objetivo do projeto estruturado é minimizar a complexidade e aumentar a modularidade de um programa. O projeto estruturado também ajuda a descrever os aspectos funcionais do sistema.

No projeto estruturado, as especificações do sistema atuam como uma base para representar graficamente o fluxo de dados e a sequência de processos envolvidos no desenvolvimento de um software com a ajuda de DFDs. Depois de desenvolver os DFDs para o sistema de software, a próxima etapa é desenvolver o gráfico de estrutura.

Modularização

O design estruturado divide o programa em módulos pequenos e independentes. Eles são organizados de cima para baixo com os detalhes mostrados na parte inferior.

Assim, o design estruturado usa uma abordagem chamada Modularização ou decomposição para minimizar a complexidade e gerenciar o problema subdividindo-o em segmentos menores.

Advantages

• As interfaces críticas são testadas primeiro.
• Ele fornece abstração.
• Ele permite que vários programadores trabalhem simultaneamente.
• Ele permite a reutilização de código.
• Ele fornece controle e melhora o moral.
• Facilita a identificação da estrutura.

Gráficos Estruturados

Os gráficos estruturados são uma ferramenta recomendada para projetar sistemas modulares de cima para baixo que definem os vários módulos de desenvolvimento do sistema e a relação entre cada módulo. Mostra o módulo do sistema e sua relação entre eles.

Consiste em um diagrama que consiste em caixas retangulares que representam os módulos, setas de conexão ou linhas.

• Control Module - É um módulo de nível superior que direciona os módulos de nível inferior, chamados subordinate modules.

• Library Module - É um módulo reutilizável e pode ser chamado a partir de mais de um ponto no gráfico.

Temos duas abordagens diferentes para projetar um gráfico estruturado -

• Transform-Centered Structured Charts - Eles são usados ​​quando todas as transações seguem o mesmo caminho.

• Transaction–Centered Structured Charts - Eles são usados ​​quando todas as transações não seguem o mesmo caminho.

Objetivos do uso de fluxogramas de estrutura

• Para encorajar um design de cima para baixo.

• Para apoiar o conceito de módulos e identificar os módulos apropriados.

• Para mostrar o tamanho e a complexidade do sistema.

• Para identificar o número de funções e módulos prontamente identificáveis ​​em cada função.

• Para descrever se cada função identificável é uma entidade gerenciável ou deve ser dividida em componentes menores.

Fatores que afetam a complexidade do sistema

Para desenvolver um software de sistema de boa qualidade, é necessário desenvolver um bom design. Portanto, o foco principal durante o desenvolvimento do design do sistema é a qualidade do design do software. Um projeto de software de boa qualidade é aquele que minimiza a complexidade e os gastos de custo no desenvolvimento de software.

Os dois conceitos importantes relacionados ao desenvolvimento do sistema que ajudam a determinar a complexidade de um sistema são coupling e cohesion.

Acoplamento

O acoplamento é a medida da independência dos componentes. Ele define o grau de dependência de cada módulo de desenvolvimento do sistema em relação ao outro. Na prática, isso significa que quanto mais forte for o acoplamento entre os módulos em um sistema, mais difícil será implementar e manter o sistema.

Cada módulo deve ter uma interface simples e limpa com outros módulos, e que o número mínimo de elementos de dados deve ser compartilhado entre os módulos.

Alto acoplamento

Esses tipos de sistemas têm interconexões com unidades de programa dependentes umas das outras. Mudanças em um subsistema causam alto impacto no outro subsistema.

Baixo acoplamento

Esses tipos de sistemas são constituídos por componentes independentes ou quase independentes. Uma mudança em um subsistema não afeta nenhum outro subsistema.

Medidas de acoplamento

• Content Coupling - Quando um componente realmente modifica outro, o componente modificado é completamente dependente da modificação de um.

• Common Coupling - Quando a quantidade de acoplamento é reduzida de alguma forma, organizando o design do sistema de forma que os dados sejam acessíveis a partir de um armazenamento de dados comum.

• Control Coupling - Quando um componente passa parâmetros para controlar a atividade de outro componente.

• Stamp Coupling - Quando as estruturas de dados são usadas para passar informações de um componente para outro.

• Data Coupling - Quando apenas os dados são passados, os componentes são conectados por este acoplamento.

Coesão

A coesão é a medida da proximidade da relação entre seus componentes. Ele define a quantidade de dependência entre os componentes de um módulo. Na prática, isso significa que o designer de sistemas deve garantir que -

• Eles não dividem processos essenciais em módulos fragmentados.

• Eles não reúnem processos não relacionados representados como processos no DFD em módulos sem sentido.

Os melhores módulos são aqueles funcionalmente coesos. Os piores módulos são aqueles que são coincidentemente coesos.

O pior grau de coesão

A coesão coincidente é encontrada em um componente cujas partes não estão relacionadas a outro.

• Logical Cohesion - É onde várias funções ou elementos de dados relacionados logicamente são colocados no mesmo componente.

• Temporal Cohesion - É quando um componente que é usado para inicializar um sistema ou definir variáveis ​​executa várias funções em sequência, mas as funções estão relacionadas pelo tempo envolvido.

• Procedurally Cohesion - É quando as funções são agrupadas em um componente apenas para garantir essa ordem.

• Sequential Cohesion - É quando a saída de uma parte de um componente é a entrada para a próxima parte dele.

Design de entrada

Em um sistema de informação, entrada são os dados brutos que são processados ​​para produzir saída. Durante o design de entrada, os desenvolvedores devem considerar os dispositivos de entrada, como PC, MICR, OMR, etc.

Portanto, a qualidade da entrada do sistema determina a qualidade da saída do sistema. Os formulários e telas de entrada bem projetados têm as seguintes propriedades -

• Deve servir a um propósito específico de forma eficaz, como armazenar, registrar e recuperar as informações.

• Ele garante um preenchimento adequado com precisão.

• Deve ser fácil de preencher e direto.

• Deve se concentrar na atenção do usuário, consistência e simplicidade.

• Todos esses objetivos são obtidos usando o conhecimento dos princípios básicos de design sobre -

  • Quais são as entradas necessárias para o sistema?

  • Como os usuários finais respondem a diferentes elementos de formulários e telas.

Objetivos para Design de Entrada

Os objetivos do design de entrada são -

• Para projetar a entrada de dados e procedimentos de entrada

• Para reduzir o volume de entrada

• Para projetar documentos de origem para captura de dados ou conceber outros métodos de captura de dados

• Para projetar registros de dados de entrada, telas de entrada de dados, telas de interface do usuário, etc.

• Para usar verificações de validação e desenvolver controles de entrada eficazes.

Métodos de entrada de dados

É importante projetar métodos de entrada de dados apropriados para evitar erros ao inserir dados. Esses métodos dependem se os dados são inseridos pelos clientes em formulários manualmente e posteriormente inseridos pelos operadores de entrada de dados, ou se os dados são inseridos diretamente pelos usuários nos PCs.

Um sistema deve evitar que o usuário cometa erros por -

• Design de formulário claro, deixando espaço suficiente para escrever de forma legível.
• Instruções claras para preencher o formulário.
• Design de formulário claro.
• Reduzindo batidas de tecla.
• Feedback de erro imediato.

Alguns dos métodos de entrada de dados populares são -

• Método de entrada em lote (método de entrada de dados offline)
• Método de entrada de dados online
• Formulários legíveis por computador
• Entrada de dados interativos

Controles de integridade de entrada

Os controles de integridade de entrada incluem vários métodos para eliminar erros comuns de entrada pelos usuários finais. Eles também incluem verificações no valor de campos individuais; tanto para formato quanto para a integridade de todas as entradas.

Trilhas de auditoria para entrada de dados e outras operações do sistema são criadas usando logs de transações que fornecem um registro de todas as mudanças introduzidas no banco de dados para fornecer segurança e meios de recuperação em caso de qualquer falha.

Design de Saída

O design da saída é a tarefa mais importante de qualquer sistema. Durante o design de saída, os desenvolvedores identificam o tipo de saída necessária e consideram os controles de saída e layouts de relatório de protótipo necessários.

Objetivos do Design de Saída

Os objetivos do design de entrada são -

• Para desenvolver um design de saída que atenda ao propósito pretendido e elimine a produção de saída indesejada.

• Para desenvolver o design de saída que atenda aos requisitos dos usuários finais.

• Para entregar a quantidade apropriada de produção.

• Para formar a saída em formato apropriado e direcioná-la para a pessoa certa.

• Para disponibilizar o resultado a tempo de tomar boas decisões.

Vamos agora examinar vários tipos de resultados -

Saídas Externas

Os fabricantes criam e projetam saídas externas para impressoras. As saídas externas permitem que o sistema deixe as ações de gatilho por parte de seus destinatários ou confirme as ações para seus destinatários.

Algumas das saídas externas são projetadas como saídas de parada, que são implementadas como um formulário e entram novamente no sistema como uma entrada.

Saídas internas

As saídas internas estão presentes dentro do sistema e são usadas por usuários finais e gerentes. Eles apóiam a gestão na tomada de decisões e relatórios.

Existem três tipos de relatórios produzidos por informações gerenciais -

• Detailed Reports - Contêm informações atuais que quase não têm filtragem ou restrição gerada para auxiliar no planejamento e controle da gestão.

• Summary Reports - Eles contêm tendências e problemas potenciais que são categorizados e resumidos que são gerados para gerentes que não desejam detalhes.

• Exception Reports - Contêm exceções, dados filtrados a alguma condição ou padrão antes de apresentá-lo ao gestor, como informação.

Controles de integridade de saída

Os controles de integridade de saída incluem códigos de roteamento para identificar o sistema de recebimento e mensagens de verificação para confirmar o recebimento bem-sucedido de mensagens tratadas pelo protocolo de rede.

Relatórios impressos ou em formato de tela devem incluir uma data / hora para a impressão do relatório e os dados. Os relatórios de várias páginas contêm o título ou a descrição do relatório e a paginação. Os formulários pré-impressos geralmente incluem um número de versão e data efetiva.

Design de formulários

Os formulários e relatórios são produtos do design de entrada e saída e são documentos comerciais que consistem em dados especificados. A principal diferença é que os formulários fornecem campos para entrada de dados, mas os relatórios são usados ​​exclusivamente para leitura. Por exemplo, formulários de pedido, emprego e aplicação de crédito, etc.

• Durante a concepção do formulário, os designers devem saber -

  • quem vai usá-los

  • onde eles seriam entregues

  • a finalidade do formulário ou relatório

• Durante o design do formulário, as ferramentas de design automatizadas aumentam a capacidade do desenvolvedor de criar protótipos de formulários e relatórios e apresentá-los aos usuários finais para avaliação.

Objetivos do design de boa forma

Um bom design de formulário é necessário para garantir o seguinte -

• Para manter a tela simples, fornecendo a sequência adequada, informações e legendas claras.

• Para atender à finalidade pretendida, usando formulários apropriados.

• Para garantir o preenchimento do formulário com precisão.

• Para manter as formas atraentes usando ícones, vídeo inverso ou cursores piscando etc.

• Para facilitar a navegação.

Tipos de formulários

Flat Forms

• É um formulário de cópia única elaborado manualmente ou por máquina e impresso em papel. Para cópias adicionais do original, papéis carbono são inseridos entre as cópias.

• It is a simplest and inexpensive form to design, print, and reproduce, which uses less volume.

Unit Set/Snap out Forms

• These are papers with one-time carbons interleaved into unit sets for either handwritten or machine use.

• Carbons may be either blue or black, standard grade medium intensity. Generally, blue carbons are best for handwritten forms while black carbons are best for machine use.

Continuous strip/Fanfold Forms

• These are multiple unit forms joined in a continuous strip with perforations between each pair of forms.

• It is a less expensive method for large volume use.

No Carbon Required (NCR) Paper

• They use carbonless papers which have two chemical coatings (capsules), one on the face and the other on the back of a sheet of paper.

• When pressure is applied, the two capsules interact and create an image.

The software system needs to be checked for its intended behavior and direction of progress at each development stage to avoid duplication of efforts, time and cost overruns, and to assure completion of the system within stipulated time.The software system needs to be checked for its intended behavior and direction of progress at each development stage to avoid duplication of efforts, time and cost overruns, and to assure completion of the system within stipulated time.

System testing and quality assurance come to aid for checking the system. It includes −

• Product level quality (Testing)
• Process level quality.

Let us go through them briefly −

Testing

Testing is the process or activity that checks the functionality and correctness of software according to specified user requirements in order to improve the quality and reliability of system. It is an expensive, time consuming, and critical approach in system development which requires proper planning of overall testing process.

A successful test is one that finds the errors. It executes the program with explicit intention of finding error, i.e., making the program fail. It is a process of evaluating system with an intention of creating a strong system and mainly focuses on the weak areas of the system or software.

Characteristics of System Testing

System testing begins at the module level and proceeds towards the integration of the entire software system. Different testing techniques are used at different times while testing the system. It is conducted by the developer for small projects and by independent testing groups for large projects.

Stages of System Testing

The following stages are involved in testing −

Test Strategy

It is a statement that provides information about the various levels, methods, tools, and techniques used for testing the system. It should satisfy all the needs of an organization.

Test Plan

It provides a plan for testing the system and verifies that the system under testing fulfils all the design and functional specifications. The test plan provides the following information −

• Objectives of each test phase
• Approaches and tools used for testing
• Responsibilities and time required for each testing activity
• Availability of tools, facilities, and test libraries
• Procedures and standards required for planning and conducting the tests
• Factors responsible for successful completion of testing process

Test Case Design

• A number of test cases are identified for each module of the system to be tested.

• Each test case will specify how the implementation of a particular requirement or design decision is to be tested and the criteria for the success of the test.

• The test cases along with the test plan are documented as a part of a system specification document or in a separate document called test specification or test description.

Test Procedures

It consists of the steps that should be followed to execute each of the test cases. These procedures are specified in a separate document called test procedure specification. This document also specifies any special requirements and formats for reporting the result of testing.

Test Result Documentation

Test result file contains brief information about the total number of test cases executed, the number of errors, and nature of errors. These results are then assessed against criteria in the test specification to determine the overall outcome of the test.

Types of Testing

Testing can be of various types and different types of tests are conducted depending on the kind of bugs one seeks to discover −

Unit Testing

Also known as Program Testing, it is a type of testing where the analyst tests or focuses on each program or module independently. It is carried out with the intention of executing each statement of the module at least once.

• In unit testing, accuracy of program cannot be assured and it is difficult to conduct testing of various input combination in detail.

• It identifies maximum errors in a program as compared to other testing techniques.

Integration Testing

In Integration Testing, the analyst tests multiple module working together. It is used to find discrepancies between the system and its original objective, current specifications, and systems documentation.

• Here the analysts are try to find areas where modules have been designed with different specifications for data length, type, and data element name.

• It verifies that file sizes are adequate and that indices have been built properly.

Functional Testing

Function testing determines whether the system is functioning correctly according to its specifications and relevant standards documentation. Functional testing typically starts with the implementation of the system, which is very critical for the success of the system.

Functional testing is divided into two categories −

• Positive Functional Testing − It involves testing the system with valid inputs to verify that the outputs produced are correct.

• Negative Functional Testing − It involves testing the software with invalid inputs and undesired operating conditions.

Rules for System Testing

To carry out system testing successfully, you need to follow the given rules −

• Testing should be based on the requirements of user.

• Before writing testing scripts, understand the business logic should be understood thoroughly.

• Test plan should be done as soon as possible.

• Testing should be done by the third party.

• It should be performed on static software.

• Testing should be done for valid and invalid input conditions.

• Testing should be reviewed and examined to reduce the costs.

• Both static and dynamic testing should be conducted on the software.

• Documentation of test cases and test results should be done.

Quality Assurance

It is the review of system or software products and its documentation for assurance that system meets the requirements and specifications.

• Purpose of QA is to provide confidence to the customers by constant delivery of product according to specification.

• Software quality Assurance (SQA) is a techniques that includes procedures and tools applied by the software professionals to ensure that software meet the specified standard for its intended use and performance.

• The main aim of SQA is to provide proper and accurate visibility of software project and its developed product to the administration.

• It reviews and audits the software product and its activities throughout the life cycle of system development.

Objectives of Quality Assurance

The objectives of conducting quality assurance are as follows −

• To monitor the software development process and the final software developed.

• To ensure whether the software project is implementing the standards and procedures set by the management.

• To notify groups and individuals about the SQA activities and results of these activities.

• To ensure that the issues, which are not solved within the software are addressed by the upper management.

• To identify deficiencies in the product, process, or the standards, and fix them.

Levels of Quality Assurance

There are several levels of QA and testing that need to be performed in order to certify a software product.

Level 1 − Code Walk-through

At this level, offline software is examined or checked for any violations of the official coding rules. In general, the emphasis is placed on examination of the documentation and level of in-code comments.

Level 2 − Compilation and Linking

At this level, it is checked that the software can compile and link all official platforms and operating systems.

Level 3 − Routine Running

At this level, it is checked that the software can run properly under a variety of conditions such as certain number of events and small and large event sizes etc.

Level 4 − Performance test

At this final level, it is checked that the performance of the software satisfies the previously specified performance level.

Implementation is a process of ensuring that the information system is operational. It involves −

• Constructing a new system from scratch
• Constructing a new system from the existing one.

Implementation allows the users to take over its operation for use and evaluation. It involves training the users to handle the system and plan for a smooth conversion.

Training

The personnel in the system must know in detail what their roles will be, how they can use the system, and what the system will or will not do. The success or failure of welldesigned and technically elegant systems can depend on the way they are operated and used.

Training Systems Operators

Systems operators must be trained properly such that they can handle all possible operations, both routine and extraordinary. The operators should be trained in what common malfunctions may occur, how to recognize them, and what steps to take when they come.

Training involves creating troubleshooting lists to identify possible problems and remedies for them, as well as the names and telephone numbers of individuals to contact when unexpected or unusual problems arise.

Training also involves familiarization with run procedures, which involves working through the sequence of activities needed to use a new system.

User Training

• End-user training is an important part of the computer-based information system development, which must be provided to employees to enable them to do their own problem solving.

• User training involves how to operate the equipment, troubleshooting the system problem, determining whether a problem that arose is caused by the equipment or software.

• Most user training deals with the operation of the system itself. The training courses must be designed to help the user with fast mobilization for the organization.

Training Guidelines

• Establishing measurable objectives
• Using appropriate training methods
• Selecting suitable training sites
• Employing understandable training materials

Training Methods

Instructor-led training

It involves both trainers and trainees, who have to meet at the same time, but not necessarily at the same place. The training session could be one-on-one or collaborative. It is of two types −

Virtual Classroom

In this training, trainers must meet the trainees at the same time, but are not required to be at the same place. The primary tools used here are: video conferencing, text based Internet relay chat tools, or virtual reality packages, etc.

Normal Classroom

The trainers must meet the trainees at the same time and at the same place. They primary tools used here are blackboard, overhead projectors, LCD projector, etc.

Self-Paced Training

It involves both trainers and trainees, who do not need to meet at the same place or at the same time. The trainees learn the skills themselves by accessing the courses at their own convenience. It is of two types −

Multimedia Training

In this training, courses are presented in multimedia format and stored on CD-ROM. It minimizes the cost in developing an in-house training course without assistance from external programmers.

Web-based Training

In this training, courses are often presented in hyper media format and developed to support internet and intranet. It provides just–in-time training for end users and allow organization to tailor training requirements.

Conversion

It is a process of migrating from the old system to the new one. It provides understandable and structured approach to improve the communication between management and project team.

Conversion Plan

It contains description of all the activities that must occur during implementation of the new system and put it into operation. It anticipates possible problems and solutions to deal with them.

It includes the following activities −

• Name all files for conversions.
• Identifying the data requirements to develop new files during conversion.
• Listing all the new documents and procedures that are required.
• Identifying the controls to be used in each activity.
• Identifying the responsibility of person for each activity.
• Verifying conversion schedules.

Conversion Methods

The four methods of conversion are −

• Parallel Conversion
• Direct Cutover Conversion
• Pilot Approach
• Phase-In Method

Method	Description	Advantages	Disadvantages
Parallel Conversion	Old and new systems are used simultaneously.	Provides fallback when new system fails. Offers greatest security and ultimately testing of new system.	Causes cost overruns. New system may not get fair trail.
Direct Cutover Conversion	New system is implemented and old system is replaced completely.	Forces users to make new system work Immediate benefit from new methods and control.	No fall back if problems arise with new system Requires most careful planning
Pilot Approach	Supports phased approach that gradually implement system across all users	Allows training and installation without unnecessary use of resources. Avoid large contingencies from risk management.	A long term phasein causes a problem of whether conversion goes well or not.
Phase-In Method	Working version of system implemented in one part of organization based on feedback, it is installed throughout the organization all alone or stage by stage.	Provides experience and line test before implementation When preferred new system involves new technology or drastic changes in performance.	Gives impression that old system is erroneous and it is not reliable.

File Conversion

It is a process of converting one file format into another. For example, file in WordPerfect format can be converted into Microsoft Word.

For successful conversion, a conversion plan is required, which includes −

• Knowledge of the target system and understanding of the present system
• Teamwork
• Automated methods, testing and parallel operations
• Continuous support for correcting problems
• Updating systems/user documentation, etc

Many popular applications support opening and saving to other file formats of the same type. For example, Microsoft Word can open and save files in many other word processing formats.

Post-Implementation Evaluation Review (PIER)

PIER is a tool or standard approach for evaluating the outcome of the project and determine whether the project is producing the expected benefits to the processes, products or services. It enables the user to verify that the project or system has achieved its desired outcome within specified time period and planned cost.

PIER ensures that the project has met its goals by evaluating the development and management processes of the project.

Objectives of PIER

The objectives of having a PIER are as follows −

• To determine the success of a project against the projected costs, benefits, and timelines.

• To identify the opportunities to add additional value to the project.

• To determine strengths and weaknesses of the project for future reference and appropriate action.

• To make recommendations on the future of the project by refining cost estimating techniques.

The following staff members should be included in the review process −

• Project team and Management
• User staff
• Strategic Management Staff
• External users

System Maintenance / Enhancement

Maintenance means restoring something to its original conditions. Enhancement means adding, modifying the code to support the changes in the user specification. System maintenance conforms the system to its original requirements and enhancement adds to system capability by incorporating new requirements.

Thus, maintenance changes the existing system, enhancement adds features to the existing system, and development replaces the existing system. It is an important part of system development that includes the activities which corrects errors in system design and implementation, updates the documents, and tests the data.

Maintenance Types

System maintenance can be classified into three types −

• Corrective Maintenance − Enables user to carry out the repairing and correcting leftover problems.

• Adaptive Maintenance − Enables user to replace the functions of the programs.

• Perfective Maintenance − Enables user to modify or enhance the programs according to the users’ requirements and changing needs.

System Audit

It is an investigation to review the performance of an operational system. The objectives of conducting a system audit are as follows −

• To compare actual and planned performance.

• To verify that the stated objectives of system are still valid in current environment.

• To evaluate the achievement of stated objectives.

• To ensure the reliability of computer based financial and other information.

• To ensure all records included while processing.

• To ensure protection from frauds.

Audit of Computer System Usage

Data processing auditors audits the usage of computer system in order to control it. The auditor need control data which is obtained by computer system itself.

The System Auditor

The role of auditor begins at the initial stage of system development so that resulting system is secure. It describes an idea of utilization of system that can be recorded which helps in load planning and deciding on hardware and software specifications. It gives an indication of wise use of the computer system and possible misuse of the system.

Audit Trial

An audit trial or audit log is a security record which is comprised of who has accessed a computer system and what operations are performed during a given period of time. Audit trials are used to do detailed tracing of how data on the system has changed.

It provides documentary evidence of various control techniques that a transaction is subject to during its processing. Audit trials do not exist independently. They are carried out as a part of accounting for recovering lost transactions.

Audit Methods

Auditing can be done in two different ways −

Auditing around the Computer

• Take sample inputs and manually apply processing rules.
• Compare outputs with computer outputs.

Auditing through the Computer

• Establish audit trial which allows examining selected intermediate results.
• Control totals provide intermediate checks.

Audit Considerations

Audit considerations examine the results of the analysis by using both the narratives and models to identify the problems caused due to misplaced functions, split processes or functions, broken data flows, missing data, redundant or incomplete processing, and nonaddressed automation opportunities.

The activities under this phase are as follows −

• Identification of the current environment problems
• Identification of problem causes
• Identification of alternative solutions
• Evaluation and feasibility analysis of each solution
• Selection and recommendation of most practical and appropriate solution
• Project cost estimation and cost benefit analysis

Security

System security refers to protecting the system from theft, unauthorized access and modifications, and accidental or unintentional damage. In computerized systems, security involves protecting all the parts of computer system which includes data, software, and hardware. Systems security includes system privacy and system integrity.

• System privacy deals with protecting individuals systems from being accessed and used without the permission/knowledge of the concerned individuals.

• System integrity is concerned with the quality and reliability of raw as well as processed data in the system.

Control Measures

There are variety of control measures which can be broadly classified as follows −

Backup

• Regular backup of databases daily/weekly depending on the time criticality and size.

• Incremental back up at shorter intervals.

• Backup copies kept in safe remote location particularly necessary for disaster recovery.

• Duplicate systems run and all transactions mirrored if it is a very critical system and cannot tolerate any disruption before storing in disk.

Physical Access Control to Facilities

• Physical locks and Biometric authentication. For example, finger print
• ID cards or entry passes being checked by security staff.
• Identification of all persons who read or modify data and logging it in a file.

Using Logical or Software Control

• Password system.
• Encrypting sensitive data/programs.
• Training employees on data care/handling and security.
• Antivirus software and Firewall protection while connected to internet.

Risk Analysis

A risk is the possibility of losing something of value. Risk analysis starts with planning for secure system by identifying the vulnerability of system and impact of this. The plan is then made to manage the risk and cope with disaster. It is done to accesses the probability of possible disaster and their cost.

A análise de risco é um trabalho em equipe de especialistas com diferentes experiências, como produtos químicos, erro humano e equipamentos de processo.

As etapas a seguir devem ser seguidas durante a realização da análise de risco -

• Identificação de todos os componentes do sistema informático.

• Identificação de todas as ameaças e perigos que cada um dos componentes enfrenta.

• Quantifique os riscos, ou seja, avaliação de perdas caso as ameaças se tornem realidade.

Análise de risco - etapas principais

Como os riscos ou ameaças estão mudando e a perda potencial também está mudando, o gerenciamento de risco deve ser realizado periodicamente pelos gerentes seniores.

A gestão de riscos é um processo contínuo e envolve as seguintes etapas -

• Identificação de medidas de segurança.

• Cálculo do custo de implementação de medidas de segurança.

• Comparação do custo das medidas de segurança com a perda e probabilidade de ameaças.

• Seleção e implementação de medidas de segurança.

• Revisão da implementação de medidas de segurança.

Na abordagem orientada a objetos, o foco está em capturar a estrutura e o comportamento dos sistemas de informação em pequenos módulos que combinam dados e processos. O objetivo principal do Projeto Orientado a Objetos (OOD) é melhorar a qualidade e a produtividade da análise e projeto do sistema, tornando-o mais utilizável.

Na fase de análise, os modelos OO são usados ​​para preencher a lacuna entre o problema e a solução. Ele tem um bom desempenho em situações em que os sistemas estão passando por um projeto, adaptação e manutenção contínuos. Ele identifica os objetos no domínio do problema, classificando-os em termos de dados e comportamento.

O modelo OO é benéfico das seguintes maneiras -

• Facilita mudanças no sistema com baixo custo.

• Promove o reaproveitamento de componentes.

• Isso simplifica o problema de integração de componentes para configurar grandes sistemas.

• Ele simplifica o projeto de sistemas distribuídos.

Elementos do sistema orientado a objetos

Vamos examinar as características do Sistema OO -

• Objects- Um objeto é algo que existe no domínio do problema e pode ser identificado por dados (atributo) ou comportamento. Todas as entidades tangíveis (aluno, paciente) e algumas entidades intangíveis (conta bancária) são modeladas como objeto.

• Attributes - Eles descrevem informações sobre o objeto.

• Behavior- Especifica o que o objeto pode fazer. Ele define a operação realizada em objetos.

• Class- Uma classe encapsula os dados e seu comportamento. Objetos com significado e propósito semelhantes agrupados como classe.

• Methods- Os métodos determinam o comportamento de uma classe. Eles nada mais são do que uma ação que um objeto pode realizar.

• Message- Uma mensagem é uma chamada de função ou procedimento de um objeto para outro. Eles são informações enviadas a objetos para acionar métodos. Essencialmente, uma mensagem é uma função ou chamada de procedimento de um objeto para outro.

Características do Sistema Orientado a Objetos

Um sistema orientado a objetos vem com vários recursos excelentes que são discutidos a seguir.

Encapsulamento

O encapsulamento é um processo de ocultação de informações. É simplesmente a combinação de processo e dados em uma única entidade. Os dados de um objeto são ocultados do resto do sistema e estão disponíveis apenas por meio dos serviços da classe. Ele permite a melhoria ou modificação de métodos usados ​​por objetos sem afetar outras partes de um sistema.

Abstração

É um processo de obtenção ou seleção de métodos e atributos necessários para especificar o objeto. Ele se concentra nas características essenciais de um objeto em relação à perspectiva do usuário.

Relacionamentos

Todas as classes do sistema estão relacionadas entre si. Os objetos não existem isoladamente, eles existem em relação com outros objetos.

Existem três tipos de relacionamentos de objeto -

• Aggregation - Indica relação entre um todo e suas partes.

• Association - Neste, duas classes estão relacionadas ou conectadas de alguma forma, tal como uma classe trabalha com outra para realizar uma tarefa ou uma classe atua sobre outra classe.

• Generalization- A classe filha é baseada na classe pai. Isso indica que duas classes são semelhantes, mas têm algumas diferenças.

Herança

Herança é um ótimo recurso que permite criar subclasses de uma classe existente, herdando os atributos e / ou operações de classes existentes.

Polimorfismo e ligação dinâmica

Polimorfismo é a capacidade de assumir muitas formas diferentes. Isso se aplica a objetos e operações. Um objeto polimórfico é aquele cujo tipo verdadeiro se esconde em uma superclasse ou classe pai.

Na operação polimórfica, a operação pode ser realizada de forma diferente por diferentes classes de objetos. Ele nos permite manipular objetos de diferentes classes, conhecendo apenas suas propriedades comuns.

Abordagem Estruturada vs. Abordagem Orientada a Objetos

A tabela a seguir explica como a abordagem orientada a objetos difere da abordagem estruturada tradicional -

Abordagem estruturada	Abordagem Orientada a Objetos
Funciona com abordagem de cima para baixo.	Funciona com a abordagem Bottom-up.
O programa é dividido em vários submódulos ou funções.	O programa é organizado por ter um número de classes e objetos.
A chamada de função é usada.	A passagem de mensagens é usada.
A reutilização de software não é possível.	A reutilização é possível.
A programação de design estruturado geralmente fica para as fases finais.	Programação de projeto orientada a objetos feita simultaneamente com outras fases.
O projeto estruturado é mais adequado para offshoring.	É adequado para desenvolvimento interno.
Mostra uma transição clara do design à implementação.	Transição não tão clara do design à implementação.
É adequado para sistemas de tempo real, sistemas embarcados e projetos onde os objetos não são o nível de abstração mais útil.	É adequado para a maioria dos aplicativos de negócios, projetos de desenvolvimento de jogos, que devem ser personalizados ou estendidos.
Diagrama DFD e ER modelam os dados.	Diagrama de classes, diagrama de seqüência, diagrama de gráfico de estado e casos de uso contribuem.
Neste, os projetos podem ser gerenciados facilmente devido a fases claramente identificáveis.	Nessa abordagem, os projetos podem ser difíceis de gerenciar devido às transições incertas entre as fases.

Linguagem de modelagem unificada (UML)

UML é uma linguagem visual que permite modelar processos, software e sistemas para expressar o design da arquitetura do sistema. É uma linguagem padrão para projetar e documentar um sistema de uma maneira orientada a objetos que permite que os arquitetos técnicos se comuniquem com o desenvolvedor.

É definido como um conjunto de especificações criadas e distribuídas pelo Object Management Group. UML é extensível e escalonável.

O objetivo da UML é fornecer um vocabulário comum de termos orientados a objetos e técnicas de diagramação que seja rico o suficiente para modelar qualquer projeto de desenvolvimento de sistemas, desde a análise até a implementação.

UML é composta por -

• Diagrams - É uma representação pictórica de processo, sistema ou alguma parte dele.

• Notations - Consiste em elementos que funcionam juntos em um diagrama, como conectores, símbolos, notas, etc.

Exemplo de notação UML para classe

Diagrama de instância - notação UML

Operações realizadas em objetos

As seguintes operações são realizadas nos objetos -

• Constructor/Destructor- Criação de novas instâncias de uma classe e exclusão de instâncias existentes de uma classe. Por exemplo, adicionar um novo funcionário.

• Query- Acessar o estado sem alterar o valor, não tem efeitos colaterais. Por exemplo, encontrar o endereço de um determinado funcionário.

• Update - Altera o valor de um ou mais atributos e afeta o estado do objeto. Por exemplo, alterando o endereço de um funcionário.

Usos de UML

UML é bastante útil para os seguintes propósitos -

• Modelando o processo de negócios
• Descrevendo a arquitetura do sistema
• Mostrando a estrutura do aplicativo
• Capturando o comportamento do sistema
• Modelando a estrutura de dados
• Construindo as especificações detalhadas do sistema
• Esboçando as ideias
• Gerando o código do programa

Modelos estáticos

Os modelos estáticos mostram as características estruturais de um sistema, descrevem a estrutura do sistema e enfatizam as partes que compõem o sistema.

• Eles são usados ​​para definir nomes de classes, atributos, métodos, assinatura e pacotes.

• Os diagramas UML que representam o modelo estático incluem diagrama de classe, diagrama de objeto e diagrama de caso de uso.

Modelos Dinâmicos

Os modelos dinâmicos mostram as características comportamentais de um sistema, ou seja, como o sistema se comporta em resposta a eventos externos.

• Os modelos dinâmicos identificam o objeto necessário e como eles funcionam juntos por meio de métodos e mensagens.

• Eles são usados ​​para projetar a lógica e o comportamento do sistema.

• Os diagramas UML representam o modelo dinâmico, incluindo diagrama de sequência, diagrama de comunicação, diagrama de estado e diagrama de atividades.

Ciclo de vida de desenvolvimento de sistema orientado a objetos

Consiste em três processos macro -

• Análise Orientada a Objetos (OOA)
• Design orientado a objetos (OOD)
• Implementação orientada a objetos (OOI)

Atividades de desenvolvimento de sistemas orientados a objetos

O desenvolvimento de sistemas orientados a objetos inclui os seguintes estágios -

• Análise orientada a objetos
• Design orientado a objetos
• Prototyping
• Implementation
• Teste incremental

Análise Orientada a Objetos

Esta fase se preocupa em determinar os requisitos do sistema e entender os requisitos do sistema, construir um use-case model. Um caso de uso é um cenário para descrever a interação entre o usuário e o sistema de computador. Este modelo representa as necessidades do usuário ou visão do usuário do sistema.

Também inclui a identificação das classes e seus relacionamentos com as outras classes no domínio do problema, que constituem um aplicativo.

Design Orientado a Objetos

O objetivo desta fase é projetar e refinar as classes, atributos, métodos e estruturas que são identificados durante a fase de análise, interface do usuário e acesso aos dados. Esta fase também identifica e define as classes ou objetos adicionais que suportam a implementação do requisito.

Prototipagem

A prototipagem permite compreender totalmente como será fácil ou difícil implementar alguns dos recursos do sistema.

Ele também pode dar aos usuários a chance de comentar sobre a usabilidade e utilidade do design. Ele pode definir ainda mais um caso de uso e tornar a modelagem de caso de uso muito mais fácil.

Implementação

Ele usa Desenvolvimento Baseado em Componentes (CBD) ou Desenvolvimento Rápido de Aplicativos (RAD).

Desenvolvimento baseado em componentes (CBD)

CODD é uma abordagem industrializada para o processo de desenvolvimento de software usando várias tecnologias como ferramentas CASE. O desenvolvimento de aplicativos passa do desenvolvimento personalizado à montagem de componentes de software pré-construídos, pré-testados e reutilizáveis ​​que operam entre si. Um desenvolvedor de CBD pode montar componentes para construir um sistema de software completo.

Desenvolvimento rápido de aplicativos (RAD)

RAD é um conjunto de ferramentas e técnicas que podem ser usadas para construir um aplicativo mais rápido do que normalmente é possível com os métodos tradicionais. Ele não substitui o SDLC, mas o complementa, pois foca mais na descrição do processo e pode ser combinado perfeitamente com a abordagem orientada a objetos.

Sua tarefa é construir o aplicativo de forma rápida e implementar de forma incremental o design de requisitos do usuário por meio de ferramentas como visual basic, power builder, etc.

Teste Incremental

O desenvolvimento de software e todas as suas atividades, incluindo testes, são um processo iterativo. Portanto, pode ser caro se esperarmos para testar um produto somente após seu desenvolvimento completo. Aqui entra em cena o teste incremental, em que o produto é testado durante vários estágios de seu desenvolvimento.