Importância Do Documento De Especificação Para A Análise Estruturada

Importância do documento de especificação para a análise estruturada

Introdução

A análise de sistemas surgiu da necessidade do controle das práticas administrativas em grandes empresas. Da necessidade de manipulação racional e eficiente de grande quantidade de dados. Tal necessidade se tornou mais evidente depois da primeira guerra, com o crescimento das organizações.

A definição de sistema sugerida pelo American National Standards Institute (ANSI) é: “Sistema, para processamento de dados, é o conjunto de pessoas, máquinas e métodos organizados de modo a cumprir um certo número de funções específicas.”

Antes da segunda revolução industrial, ou a informatização da sociedade, os computadores eram de domínio de cientistas e militares. Foram duas as principais mudanças sociais e econômicas após esta revolução:

concentração da produção e aumento da capacidade produtiva com o domínio da energia e o maior aproveitamento das máquinas e processos.

Consequente a isso, surgiu a necessidade de uma gestão mais integrada e descentralizada. Para descentralizar, dividiram-se as tarefas da organização: produção, contábil, relacionamento com clientes, finanças, pessoal, etc. Para promover a integração, foi necessário evoluir a comunicação. Pois, no começo, poucos se comunicavam entre si e informações inúteis eram passadas juntamente com as que interessavam a quem recebia. Foi preciso focar em “o que comunicar e a quem”, e, então, aprimorou-se a técnica da comunicação escrita, principalmente por meio de formulários.

Na comunicação havia muita perda de informação, isso levou à necessidade de administrar a informação. Criaram-se, portanto, procedimentos de tratamento, produção e controle da informação.

Começava-se então a segunda revolução industrial – utilização de equipamentos mecânicos e elétricos para processamento e armazenamento informação. Logo, surgiu a necessidade de aumentar a capacidade do homem de manusear e processar a informação. Passou-se então a estrutura organizacional, focando a dinâmica da informação. O estudo das organizações, através da análise de sistemas e sua consequente informatização, permitiu o domínio da complexidade das grandes organizações.

Modelos de ciclo de vida

Modelo em cascata (clássico ou linear): as fases são realizadas sequencialmente. Eventualmente, pode haver retroalimentação de uma fase para anterior. As fases são: levantamento de requisitos, análise de requisitos, projeto, implementação, testes e implantação.

Modelo Iterativo e Incremental: proposto para corrigir os problemas do modelo em cascata. Divide o desenvolvimento em ciclos. Em cada ciclo pode-se identificar as fases de análise, implementação e testes. Na abordagem em cascata, cada fase é realizada apenas uma vez. O modelo iterativo e incremental incentiva muito a participação do usuário nas atividades de desenvolvimento, diminuindo interpretações erradas em relação aos requisitos levantados. Isso facilita o gerenciamento dos riscos do projeto. O ciclo de vida do processo de desenvolvimento iterativo e incremental pode ser estudado segundo duas dimensões: Temporal e de atividades. Na dimensão temporal o processo está estruturado em fases:

Concepção: são definidos a ideia geral do sistema e o escopo do desenvolvimento.

Elaboração: define-se como o sistema será construído, realiza-se a análise do domínio do negócio (área do conhecimento na qual um sistema será desenvolvido) e ordenam-se os requisitos considerando prioridade e risco.

Construção: desenvolve-se mais a análise e projeto. Nesta fase é que ocorrem mais iterações incrementais, é decidido se o produto pode ser entregue.

Transição: o sistema é instalado para o usuário, são realizados treinamentos, avalia-se a aceitação por parte do usuário e avaliam-se os gastos.

Em cada uma das fases todas as atividades são realizadas, em maior ou menor proporção. Em cada uma das fases há uma ou mais iterações e, ao final de iteração, é produzido um incremento, ou seja, uma parte do sistema final. Cada fase é concluída com um Marco. Ele é o ponto de tomada de decisões sobre o projeto e objetivos são alcançados. Ajudam o gerente a estimar gastos e o andamento do cronograma de desenvolvimento.

Levantamento de requisitos

Pela definição de Maciaszek (2000), requisito é uma condição ou capacidade que deve ser alcançada ou possuída por um sistema, ou componente deste, para satisfazer um contrato, padrão, especificação ou outros documentos formalmente impostos.

Os requisitos são identificados a partir do domínio do negócio. Durante o levantamento de requisitos, a equipe de desenvolvimento tenta entender o que deve ser automatizado pelo sistema. O levantamento de requisitos compreende o estudo exploratório das necessidades do usuário.

O resultado do levantamento de requisitos é documento de requisitos, que são subdivididos em funcionais (definem o que o sistema deve fazer) e não funcionais (definem características de qualidade para o sistema).

Análise de requisitos

Nesta fase os analistas utilizam o documento de requisitos para dividir o sistema em partes menores e entender a relação entre elas. Criando, assim, modelos para representar o sistema. O foco é “o que” o sistema deve fazer e não “como fazer”.

Os modelos construídos nesta fase devem ser validados, para assegurar que as necessidades serão atendidas, e verificados, para garantir que os modelos estão de acordo com os requisitos levantados.

A prototipagem é uma técnica muito utilizada para validação de requisitos. São construídas telas de entrada e saída de dados para que o usuário interaja com o que foi entendido em relação aos requisitos. Isso permite esclarecimentos acerca de duvidas sobre o entendimento dos requisitos.

Projeto, implementação, testes e implantação.

Define-se como o sistema funcionará para atender aos requisitos, considerando os aspectos físicos dependentes da implementação. Consideram-se aspectos da arquitetura do sistema do usuário, padrão de interface gráfica, linguagem de programação e sistema gerenciador de banco de dados.

Os modelos são criados por meio dos diagramas UML – classes, casos de uso, interação, estados e atividades. Embora análise e projeto sejam descritas separadamente, na prática não há distinção clara entre elas.

Metodologia

Um