A Engenharia de Software

1. Conceitos Gerais da Engenharia de Software

O método de desenvolvimento de softwares não compreende apenas na parte de programação e instalação para o usuário final, mas esta etapa é mais abrangente do que muitos analista pensam.

Um software não é apenas um programa de computador, em que ou usuário acessa-o por meio de algum tipo de autenticação e realiza as tarefas que nele é compatível e que o mesmo deseja, mas existem muitos paradigmas entrelaçados dentro da sua concepção e até mesmo implementação e manutenção.

Varias abordagem são utilizadas atualmente para designar e criar um software mais confiável, interação fácil entre o usuário e o mesmo, rapidez, e principalmente segurança. A engenharia de software , que segundo o seu percursor , realizou a seguinte citação:

“Engenharia de Software é a criação e a utilização de sólidos princípios de engenharia a fim de obter software de maneira econômica, que seja confiável e que trabalhe em máquinas reais.”

Friedrich Ludwig Bauer.

Com o desenvolvimento desta engenharia foi possível que a crise do software, ocorrida na década de 1970, frente a grande demanda por sistemas, as dificuldade devido à complexidade do mesmo, entre outros fatores para a criação deste termo.

A Engenharia de software refere-se métodos e esquemas para serem seguidos para o desenvolvimento de um sistema. Nela se aborda tanto a parte da concepção, onde o usuário solicitante entra em contato com o analista, ou engenheiro de software solicitando, passando pela parte da obtenção dos requisitos, a modelagem deles em diversos diagramas, o seu aprimoramento, entrega de documentos, codificação, testes, implementação e manutenção dos requisitos e em consequência frente à necessidade do usuário e também para adequações a mudanças de mercado e legislação.

Existem alguns paradigmas e métodos dentro da engenharia de software que deve ser observado pelo responsável pela criação. Alguns modelos de desenvolvimento que devem ser estudados separados e alocados de acordo com a característica, e aspectos do software a ser desenvolvido. Um exemplo é o modelo de desenvolvimento em cascata onde o software é desenvolvido em etapas, e a entrega é somente realizada no final. Em face o desenvolvimento iterativo também é em etapas, mas existe a interação entre eles e o sistema desejado é apresentado em varias etapas ao solicitante através de protótipos, onde o mesmo pode verificar alguma intercorrência e solicitar alguma alteração, de exclusão, modificação e inclusão de funcionalidade ao mesmo. Segundo (Falbo 2005. P.6):

Um processo de software não pode ser definido de forma universal. Para ser eficaz e conduzir à construção de produtos de boa qualidade, um processo deve ser adequado ao domínio da aplicação e ao projeto específico.

As abordagens de desenvolvimento foram incorporadas a UML (Unified Modeling Language), transformados em padrão internacional pela OMG (Object Management Grup).Onde atualmente os sistemas se baseiam nesta concepção.

A engenharia de software deve ser bem fundamentalizada e estudada por todos os responsáveis pelo desenvolvimento de sistemas, utilizando os métodos referências e ter no encalço fundamentos pera um bom trabalho e cada vez mais a criação de sistemas funcionais e sem gerar o retrabalho.

1. Engenharia de Requisitos:

O desenvolvimento de um sistema, segundo a visão dos estudiosos, a parte fundamental para a criação é a elicitação dos requisitos, sejam eles da visão do usuário tem das funcionalidades que o mesmo devera atender, mas também de recursos técnicos que em muitas das vezes o usuário final não possui, ou até mesmo tem uma noção errônea do mesmo.

A engenharia de requisitos é uma ferramenta fundamental para os analistas de sistemas para a obtenção com clareza e também no tratamento e filtragem dos requisitos na hora da “filtragem”, dos mesmos incorporando ao documento final, somente aqueles necessário-com a aprovação do comprador- e retirando ambiguidades que possam existir.

Dentro da engenharia de requisitos, os mesmos são subdivididos em 2 partes: requisitos funcionais e não funcionais. A primeira subdivisão compreende todos aqueles requisitos de funcionalidades que o sistema terá com o usuário, entre, inserir alguns cadastros, excluir nomes, entre outras ações que o mesmo possuirá. Observando a segunda subdivisão encontramos os não funcionais, que é definido como requisitos que compreende a parte física, de estrutura de resposta a alguma ação, entre outros.

A parte de elicitação dos requisitos compreende e possui várias ferramentas para auxiliar o analista a “capturar” de forma bem clara os requisitos através dos stakeholders. Existem ferramentas para este fim, que são elas: entrevistas, workshops, braistormig, entre outros.