Modelos de desenvolvimento de softwares

Prévia do material em texto

Agora é com você. Depois de termos abordado alguns modelos e as 
principais técnicas de desenvolvimento usadas na gestão de SI, a proposta 
é que você elabore uma redação de 20 a 30 linhas em fonte arial, tamanho 
12, contemplando as características de dois dos modelos apresentados na 
unidade 27. Utilize a internet como fonte de pesquisa. O objetivo dessa 
dissertação é ampliar seus conhecimentos sobre os modelos de 
desenvolvimentos de software e estimular a sua capacidade investigativa 
por meio da pesquisa. Por certo, durante a pesquisa, você encontrará 
outros assuntos que não estão diretamente ligados ao tema, mas que 
poderão ser úteis a você ao longo do curso. E durante sua redação, não 
deixe de pesquisar em pelo menos duas ou três fontes. Não se satisfaça 
com o primeiro resultado de sua busca. Ao final, compartilhe suas 
experiências com seus colegas. Bom trabalho! 
 
 
A utilização de um processo de software é um fator primordial para o 
sucesso no desenvolvimento de software. 
 
Entendemos que um processo de desenvolvimento de software é, nada 
mais, nada menos, que um conjunto estruturado de atividades exigidas 
para desenvolver um sistema de software. Assim Sommerville nos dá a 
seguinte definição: "[O processo é] um conjunto de atividades e 
resultados associados que produzem um produto de software". 
 
Jalote conclui que um processo de software é: "um conjunto de 
atividades, ligadas por padrões de relacionamento entre ela, pelas 
quais se as atividades operarem corretamente e de acordo com os 
padrões requeridos, o resultado desejado é produzido. O resultado 
desejado é um software de alta qualidade e baixo custo. 
Obviamente, um processo que não aumenta a produção (não suporta 
projetos de software grandes) ou não pode produzir software com 
boa qualidade não é um processo adequado." 
 
De modo resumido podemos definir o processo de desenvolvimento de um 
software como um conjunto de atividades uniformizadas a serem aplicadas 
sistematicamente e que se encontram agrupadas em fases, cada uma das quais 
com os seus intervenientes com responsabilidades, que possuem diversas 
entradas e produzem diversas saídas. Isto é, define quem faz o quê, quando e 
como para atingir um certo objetivo. 
 
Humphrey define as seguintes razões para a definição de um processo 
padrão: “Redução dos problemas relacionados a treinamento, 
revisões e suporte à ferramentas; As experiências adquiridas nos 
projetos são incorporadas ao processo padrão e contribuem para 
melhorias em todos os processos definidos; Economia de tempo e 
esforço na definição de novos processos adequados a projetos.” 
 
Com estas definições em mente, poderemos entender melhor as fases 
de um processo de desenvolvimento de um Software, conceitos que nos 
farão entender melhor a escolha dos dois modelos de desenvolvimento 
deste trabalho: 
 
Para Schwartz as principais fases de um processo de software são: 
 
 Especificação de Requisitos: tradução da necessidade ou 
requisito operacional para uma descrição da funcionalidade a ser 
executada. 
 Projeto de Sistema: tradução destes requisitos em uma descrição 
de todos os componentes necessários para codificar o sistema. 
 Programação (Codificação): produção do código que controla o 
sistema e realiza a computação e lógica envolvida. 
 Verificação e Integração (Verificação) : verificação da satisfação 
dos requisitos iniciais pelo produto produzido. 
 
Ao contrário do que possa parecer não existe uma sequência obrigatória 
de fases, sendo que diversos autores apontam a natureza não 
simultânea das fases como uma realidade na aplicação de processos de 
software, e também defendem que o processo de software é muito mais 
iterativo e cíclico do que a ideia de fases simples pode sugerir. 
 
Não iremos nos ater as atividades do processo de desenvolvimento de 
Software, apenas nominá-las, pois em cada fase de um processo de 
software definido são executadas as atividades básicas para que sejam 
atingidos os objetivos propostos. Segundo Pressman estas atividades 
constituem um conjunto mínimo para se obter um produto de software. 
Realizando uma combinação de classificações dadas por Schwartz, 
Pressman e Sommerville podemos identificar as seguintes atividades: 
 
Especificação 
 Engenharia de Sistema. 
 Análise de Requisitos. 
 Especificação de Sistema. 
 
Projeto 
 Projeto Arquitetural. 
 Projeto de Interface. 
 Projeto Detalhado. 
 
Implementação 
 Codificação. 
 
Validação 
 Teste de Unidade e Módulo. 
 Integração. 
 
Manutenção e Evolução 
 
Nesta fase, o software em geral entra em um ciclo iterativo que abrange 
todas as fases anteriores. 
 
Modelos de Processos 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. 
 
Nos modelos de processo de software é dado uma atenção especial à 
representação abstrata dos elementos do processo e sua dinâmica, não 
estabelecendo métodos de desenvolvimento, pois este trabalha num 
nível mais alto de abstração do que os modelos de ciclo de vida. 
 
A seguir descrevemos os dois modelos que acreditamos tem uma íntima 
ligação entre si: 
 
O modelo Cascata 
 
Modelo idealizado por Royce em 1970, 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. Sofreu diversas ajustes e 
aprimoramentos sendo muito utilizado nos dias atuais. 
 
Descrição Visual do Modelo 
 
 
A ideia principal do modelo é que as diferentes etapas de 
desenvolvimento seguem uma sequência, ou seja, a saída da primeira 
etapa "fluí" para a segunda etapa e a saída da segunda etapa " fluí" para 
a terceira e assim por diante. 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. Este modelo minimiza o impacto da 
compreensão adquirida no decurso de um projeto, uma vez que se um 
processo não pode voltar atrás de modo a alterar os modelos e as 
conclusões das tarefas anteriores, é normal que as novas ideias sobre o 
sistema não sejam aproveitadas. Numa tentativa de resolver este tipo de 
problema foi definido um novo tipo de processo baseado no clássico em 
cascata, designado por modelo em cascata revisto, cuja principal 
diferença consiste em prever a possibilidade de que, a partir de qualquer 
tarefa do ciclo, se poder regressar a uma tarefa anterior de forma a 
contemplar alterações funcionais e/ou técnicas que entretanto tenham 
surgido, em virtude de um maior conhecimento que entretanto se tenha 
obtido. O risco desta abordagem é que, na ausência de um processo de 
gestão do projeto e de controlo das alterações bem definido, podemos 
passar o tempo num ciclo infinito, sem nunca se atingir o objetivo final, 
ou seja disponibilizar o sistema a funcionar. 
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 de Prototipagem 
 
O modelo de desenvolvimento baseado na prototipaçãoprocura suprir 
duas grandes limitações do modelo cascata. De acordo com Jalote 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 está 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 avaliação do cliente é fornecido as impressões do 
que precisa ser alterado, o que está 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. 
 
Segundo Pressman e Jalote 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 versã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. 
 
Conclusão 
 
Mesmo não avaliando, neste trabalho em específico, os demais modelos 
(Modelo em espiral e Modelo de processo de desenvolvimento iterativo 
e incremental), podemos concluir que não existe um processo correto ou 
incorreto, como não existe um modelo de desenvolvimento que seja o 
“Santo Graal” universal para o problema do desenvolvimento de 
software. 
 
Dependendo de sua aplicação, ambiente e objetivo, a utilização de um 
processo ou modelo específico pode ser vantajoso ou não. Cabe a cada 
organização avaliar o seu problema com cuidado e usar os modelos 
existentes como um guia para o desenvolvimento do seu próprio 
processo de desenvolvimento. 
 
Referências: 
 
 SOMMERVILLE, I. Software engineering. 5th. ed. Addison-Wesley, 
1995. 
 PRESSMAN, R. S. , Software engineering: A practitioner's 
approach. 4th. ed. McGraw-Hill, 1997. p. 22-53. 
 Falbo, Ricardo A., Integração de Conhecimento em um Ambiente 
de Desenvolvimento de Software. Tese de Doutorado, 
COPPE/UFRJ, Rio de Janeiro, Brasil, 1998. 
 Humphrey, Watts S., Managing the Software Process. Addison-
Wesley Publishing,Company, Massachussets, 1990. 
 SCHWARTZ, J. I. ,Construction of software. In: Practical 
Strategies for Developing Large Systems. Menlo Park: Addison-
Wesley, 1st. ed., 1975. 
 Christian Reis . , Caracterização de um Modelo de Processo para 
Projetos de Software Livre .teste de mestrado.Instituto de 
Ciências Matemática e Computação. São Carlos, São Paulo Abril 
de 2001. 
 WWW[7] http://www.administradores.com.br/colunas_membro.j
sp?idColuna=233&idColunista=555 - Glaucia Gabriel Sass - O 
Processo de Desenvolvimento Baseado em Componentes: O 
impulso das novas tecnologias , acessado em 19 de agosto de 
2005. 
 
http://www.administradores.com.br/colunas_membro.jsp?idColuna=233&idColunista=555
http://www.administradores.com.br/colunas_membro.jsp?idColuna=233&idColunista=555