Engenharia de Software é a aplicação de uma abordagem sistemática, disciplinada e quantificável no desenvolvimento, na operação e na manutenção de software.
Importante frisar que Software não é apenas o arquivo executável final, pois inclui toda a documentação necessária (arquivos de configuração, manual de instalação e utilização) e o banco de dados.
Na imagem a seguir temos as camadas da Engenharia de Software:
A gestão da qualidade ajudam a promover uma cultura de aperfeiçoamento contínuo de processos.
O processo define uma metodologia que deve ser estabelecida para que seja possível ter uma entrega efetiva. O processo também é a base para o controle do gerenciamento de projetos de software, permiteaplicar métodos técnicos, produzir diferentes produtos como modelos, documentos, mudanças, etc, e por fim estabelece marcos, garantia da qualidade e gerir mudanças de forma apropriada. Define o Define o que faz, como será feito e quando será feito faz, como será feito e quando será feito.
A camada de métodos que é responsável por fornecer informações técnicas para desenvolver software. Os métodos envolvem diversas tarefas como: comunicação, análise de requisitos, modelagem de projeto, construção de software, testes e suporte.
Por fim, as ferramentas são responsáveis por fornecer suporte automatizado ou semi automatizado para o processo e os métodos. Quando as ferramentas são interligadas de forma que informações criadas por uma ferramentas são usadas por outra temos um sistema que suporta o desenvolvimento, também chamado de Engenharia de Software com o Auxílio do Computador ou Computer Aided Software Engeneering (CASE).
Processos de Software
Um processo de desenvolvimento de software é um conjunto de atividades, parcialmente ordenadas, com a finalidade de obter um produto de software.
De forma resumida, "é quem está fazendo o quê, quando e como para atingir um determinado objetivo".
Um conceito bastante importante dentro de processo é o de metodologia que estabelece uma base para um processo de engenharia de software completo através de um pequeno número atividades estruturais aplicáveis a todos projetos de software, independente de tamanho ou complexidade.
Uma metodologia de processo genérica possui cinco atividades:
Comunicação: Antes do inicio do projeto comunicamos e colaboramos com os clientes e todos os interessados para compreender os seus objetivos e fazermos o levantamento das necessidades que ajudarão a definirmos as funções e características do software a ser construído.
Planejamento: O planejamento é como um mapa que ajuda a guiar a equipe na jornada de construção do produto. No planejamento define-se o trabalho de engenharia descrevendo suas tarefas técnicas, riscos, recursos necessários, produtos a serem construídos e um cronograma de trabalho.
Modelagem: Modelos são esboços de modo que possamos ter uma ideia melhor do todo. Caso necessário os modelos são mais detalhados a fim de compreender melhor o problema e como resolvê-lo.
Construção: Essa atividade é onde o software é construído. No entanto, atividades de testes também são realizadas nessa atividade com o intuito de revelar erros na codificação.
Emprego: O incremento do software ou o software completo é entregue ao cliente que avalia o produto e retorna feedbacks baseando-se na avaliação do produto.
Modelos de Processo de Desenvolvimento de Software
Os modelos de processos de desenvolvimento de software surgiram pela necessidade de dar resposta às situações a analisar, porque só na altura em que enfrentamos o problema é que podemos escolher o modelo.
Os principais modelos são:
Modelo Cascata
Também conhecido como abordagem ‘top-down’ , tem como principal característica a sequência de atividades onde cada fase transcorre completamente e seus produtos são vistos como entrada para uma nova fase. Na imagem a seguir é possível ver uma representação visual do modelo:
As atividades a executar são agrupadas em tarefas, executadas sequencialmente, de forma que uma tarefa só poderá ter início quando a anterior tiver terminado. Uma das vantagens do modelo é que só avança para a tarefa seguinte quando o cliente valida e aceita os produtos finais da tarefa atual.
O modelo pressupõe que o cliente participa ativamente no projeto e que sabe muito bem o que quer.
As desvantagens deste modelo são :
Dificuldade em acomodar mudanças depois que o processo está a ser executado;
Partição inflexível do projeto em estágios distintos;
Dificuldade em responder a mudanças dos requisitos;
É mais apropriado quando os requisitos são bem compreendidos;
Os projetos reais raramente se adaptam ao modelo linear e sequencial;
É difícil capturar os requisitos de uma só vez;
Cliente tem de pacientemente esperar o resultado final;
Os programadores são frequentemente atrasados sem necessidade;
Alto custo de correção das especificações quando nas fases de Teste e Implantação.
Modelo Espiral
Neste modelo o projeto é atacado como uma série de pequenos ciclos, cada um finalizando um versão de um software executável.
A imagem a seguir apresenta uma representação visual do modelo:
O modelo espiral é, atualmente a abordagem mais realística para desenvolvimento de software em grande escala, e usa uma abordagem que capacita a empresa que presta o serviço, e o cliente a entender e reagir aos riscos em cada etapa evolutiva.
Vantagens deste modelo:
Modelo em espiral permite que ao longo de cada iteração se obtenham versões do sistema cada vez mais completas, recorrendo à prototipagem para reduzir os riscos.
Desvantagens:
Pode ser difícil convencer grandes clientes ( particularmente em situações de contrato) de que a abordagem evolutiva é controlável.
A abordagem deste tipo de modelo exige considerável experiência na avaliação dos riscos e baseia-se nessa experiência para o sucesso. Se um grande risco não for descoberto, poderão ocorrer problemas.
Este tipo de modelo é relativamente novo e não tem sido amplamente usado.
É importante ter em conta que podem existir diferenças entre o protótipo e o sistema final. O protótipo pode não cumprir os requisitos de desempenho, pode ser incompleto, e pode refletir somente alguns aspectos do sistema a ser desenvolvido.
O modelo em espiral pode levar ao desenvolvimento em paralelo de múltiplas partes do projeto, cada uma sendo abordada de modo diferenciado, por isso é necessário o uso de técnicas específicas para estimar e sincronizar cronogramas, bem como para determinar os indicadores de custo e progresso mais adequados.
Modelo de do processo de desenvolvimento iterativo e incremental
Este modelo é uma extensão do modelo espiral sendo porém mais formal e rigoroso.
O desenvolvimento de um produto comercial de software é uma grande tarefa que pode ser estendida por vários meses, possivelmente um ano ou mais. Por isso, é mais prático dividir o trabalho em partes menores ou iterações. Cada iteração resultará num incremento.
Iterações são passos em fluxo de trabalho e incrementos são crescimentos do produto.
A cada iteração são realizadas as seguintes tarefas:
Análise (refinamento de requisitos, refinamento do modelo conceitual)
Projeto (refinamento do projeto arquitetural, projeto de baixo nível)
Implementação (codificação e testes)
Transição para produto (documentação, instalação, ...)
As principais vantagens desse modelo incluem:
Possibilidade de avaliar mais cedo os riscos e pontos críticos do projeto, e identificar medidas para os eliminar ou controlar;
Redução dos riscos envolvendo custos a um único incremento. Se a equipe que desenvolve o software precisar repetir a iteração, a organização perde somente o esforço mal direcionado de uma iteração, não o valor de um produto inteiro;
Permite que os vários intervenientes possam trabalhar mais efetivamente pela interação e partilha de comunicação daí resultante.
Modelo de Prototipagem
O modelo de desenvolvimento baseado na prototipação procura suprir duas grandes limitações do modelo cascata.
A ideia básica deste modelo é que ao invés de manter inalterado os requisitos durante o projeto e codificação, um protótipo é desenvolvido para ajudar no entendimento dos requisitos.
Este desenvolvimento passa por um projeto , codificação e teste, sendo que cada uma destas fases não é executada formalmente. Usando assim os protótipos o cliente pode entender melhor os requisitos do sistema.
A sequência de eventos deste modelo esta exibido na figura abaixo:
O protótipo é desenvolvido com uma versão inicial do documento de especificação dos requisitos. Depois do protótipo estar pronto o cliente o utiliza e baseado na sua avaliação do cliente é fornecido ao as impressões do que precisa ser alterado, o que esta faltando e o que não é preciso.
O protótipo é então modificado incorporando as sugestões de mudança e o cliente usa o protótipo novamente repetindo o processo até que o mesmo seja válido em termos de custo e tempo. No final os requisitos iniciais são alterados para produzir a especificação final dos requisitos.
Este modelo pode trazer os seguintes benefícios:
O modelo é interessante para alguns sistemas de grande porte nos quais representem um certo grau de dificuldade para exprimir rigorosamente os requisitos
É possível obter uma verão do que será o sistema com um pequeno investimento inicial
A experiência de produzir o protótipo pode reduzir o custo das fases posteriores
A construção do protótipo pode demonstrar a viabilidade do sistema.
Questões a serem consideradas quanto a utilização do modelo:
A Prototipação deve ser utilizada apenas quando os usuários podem participar ativamente no projeto
Não descuidar de uma boa análise que deve ser conduzida durante todo o processo de prototipação
Esclarecer aos usuários que o desempenho apresentado pelo protótipo não necessariamente será o mesmo do sistema final
Evitar que o sistema final seja um protótipo em que foram implementados todos os requisitos especificados, pois corre-se o risco de ter-se um sistema mal implementado, uma vez que as técnicas utilizadas para desenvolver um protótipo são diferentes daquelas utilizadas na implementação de um sistema (relaxamento de regras de negócio, manipulação de exceções etc)
Durante a etapa de prototipação, documentar todos os pontos levantados e implementados no protótipo, que não constavam dos requisitos iniciais, para incluí-los na documentação final.
Fontes:
http://www.devmedia.com.br/principios-da-engenharia-de-software/29630
http://softwarelivre.org/articles/0132/5679/Introdução_a_Engenharia_de_Software_-_Aula_01.pdf
https://pt.wikipedia.org/wiki/Processo_de_desenvolvimento_de_software
http://www.macoratti.net/proc_sw1.htm