Artigo engenharia de Software
Por: Luan Matias • 18/9/2015 • Artigo • 3.489 Palavras (14 Páginas) • 293 Visualizações
[pic 1] [pic 2]
Categoria de Assunto
[pic 3]
Título
[pic 4]
Autor
[pic 5]
Este artigo foi gerado a partir do Programa de Iniciação Científica (PIC) da UniRadial, sob o título: “Um Processo de Desenvolvimento de Software facilmente aplicável”
Resumo
[pic 6]
Palavras-Chave
[pic 7]
Abstract
[pic 8]
Key-words
[pic 9]
- Introdução
A Engenharia de Software melhorou a qualidade da produção de software de forma geral. Ela trouxe modelos de desenvolvimento de software que visam produzir software com mais qualidade e com custo e prazos previsíveis. Dentre estes modelos, destaca-se o modelo Cascata. Apesar de termos outros modelos melhores, o modelo Cascata ainda é o mais largamente utilizado. Por quê?
Engenharia de Software – Processos de Software
Mal o homem começou a produzir software, já se deparou com uma série de problemas de qualidade e com demanda maior que a capacidade produtiva. A solução foi introduzir conceitos de engenharia a este trabalho. Assim, consolidou-se a Engenharia de Software que, através da introdução de metodologias e ferramentas proporcionou condições para a melhoria da qualidade do software produzido.
Pela primeira vez falou-se em um processo de desenvolvimento de software.
No dicionário Michaelis, uma das definições de processo é “maneira de operar, resolver”. Assim, processo de desenvolvimento de software é a maneira como se produz software.
Processos Cascata
O primeiro processo criado foi o modelo Cascata (ou waterfall). Este processo estabeleceu um ciclo de vida básico para o desenvolvimento de um software. Este ciclo é formado de etapas que dividem o trabalho de desenvolvimento de software em etapas claras, conforme demonstrado na figura 1. Isto trouxe alguma organização para as equipes de desenvolvimento e também para os usuários, que passaram a ter que definir melhor suas solicitações, antes de ver iniciado o trabalho de codificação de programas.
O ciclo de vida Cascata é largamente utilizado atualmente e, apesar de ter ajudado muito a organizar o desenvolvimento de software, traz consigo uma série de problemas.
[pic 10]
Figura 1: O ciclo de vida Cascata (Fonte: PRESSMAN, 1995)[pic 11]
Problemas com o Ciclo de Vida cascata
O processo Cascata tem muitas qualidades, mas nem sempre é possível aplicá-lo na íntegra, por vários motivos. O modelo tem algumas desvantagens que discutiremos a seguir. A maioria dos problemas está ligada aos requisitos do software que se vai construir.
Segundo Pressman (Presmann, 1995), as principais críticas a este modelo são:
- Os projetos raramente seguem o fluxo seqüencial, gerando, por vezes, iterações;
- É muito difícil para o cliente declarar todas as suas necessidades corretamente e de forma clara logo no início do projeto;
- Decorre muito tempo entre o início do projeto e a disponibilização de uma primeira versão minimamente utilizável do sistema (durante este período, os requisitos podem sofrer modificações ou mesmo deixarem de fazer sentido);
- O Risco de insucesso é alto, visto que se um erro de grande impacto for cometido e não detectado, provavelmente só será descoberto muito tardiamente, o que pode ser desastroso para o projeto.
O ciclo Cascata presume que o projeto terá uma seqüência correta, sem desvios e sem problemas. Neste ponto temos outra grande deficiência do Cascata: não considera riscos que podem impactar negativamente e até mesmo inviabilizar o projeto.
4.1. Requisitos
Dos motivos destacados por Pressman, o maior foco é sobre o tratamento de requisitos.
Sobre isto, Sommerville (Sommerville, 2003) destaca que os acordos com os clientes devem ser feitos em um estágio inicial do processo de desenvo lvimento onde, geralmente, os requisitos são desconhecidos ou não são claros.
Quando estes requisitos são alterados posteriormente, impactam negativamente o produto de software que deve ser refeito, ao menos em parte, devido às alterações nos requisitos.
Assim, Sommerville aconselha a só utilizar este modelo quando os requisitos forem bem compreendidos.
Embora o ciclo de vida Cascata constitua uma abordagem melhor que a abordagem casual (abordagem livre, antes da Engenharia de Software), a forma altamente dinâmica como se desenvolve software, exige um processo mais ágil e dinâmico.
Ciclo de Vida Espiral
O Ciclo de Vida Espiral traz uma alternativa interessante a este problema com os requisitos, pois divide a tarefa de levantar requisitos em etapas que não ocorre todas de uma vez, no início do desenvolvimento.
O modelo Espiral mantém como seu cerne as mesmas etapas do modelo Cascata. Porém, estas etapas são executadas várias vezes ao longo do ciclo de desenvolvimento do software (uma vez para cada pacote de desenvolvimento). A figura 2 ilustra estas etapas. O centro da figura assinala o início do desenvolvimento. À medida que o desenvolvimento ocorre, caminha-se, na espiral, para sua parte mais externa, passando pelas disciplinas de desenvolvimento várias vezes.
O efeito desta forma de trabalho são entregas parciais de software para o cliente, ao invés de uma entrega única ao final do processo.
[pic 12]
Figura 2 – Ciclo de Vida Espiral (fonte: Sommerville, 2003)
Esta divisão do desenvolvimento em pequenos pacotes, como se fossem subprojetos, é uma boa alternativa ao problema com requisitos, que são tratados (capturados, especificados e validados) em vários estágios e não em um estágio único, permitindo revisões do usuário à medida que o desenvolvimento avança. Certamente, é mais fácil para todos vislumbrar os requisitos à medida que o projeto ganha maturidade.
...