Modelos do processo de desenvolvimento de software

SUMÁRIO

1 INTRODUÇÃO 3

2 DESENVOLVIMENTO 4

2.1 Modelos de Processo de Software 5

2.2 Prototipação 5

3 CONCLUSÃO 4

4 REFERÊNCIAS 7

1 INTRODUÇÃO

Um processo de software pode ser visto como o conjunto de atividades, métodos, práticas e transformações que guiam pessoas na produção de software. Um processo eficaz deve, claramente, considerar as relações entre as atividades, os artefatos produzidos no desenvolvimento, as ferramentas e os procedimentos necessários e a habilidade, o treinamento e a motivação do pessoal envolvido.

2 DESENVOLVIMENTO

2.1 Modelos de Processos de Software

Um processo de software pode ser definido como um conjunto coerente de atividades, políticas, estruturas organizacionais, tecnologias, procedimentos e artefatos necessários para conceber, desenvolver, dispor e manter um produto de software (FUGGETTA, 2000). Um processo eficaz deve, claramente, considerar as relações entre as atividades, os artefatos produzidos no desenvolvimento, as ferramentas e os procedimentos necessários e a habilidade, o treinamento e a motivação do pessoal envolvido (FALBO, 1998).

A escolha de um modelo de ciclo de vida (ou modelo de processo) é o ponto de partida para a definição de um processo de desenvolvimento de software. Um modelo de ciclo de vida organiza as macro-atividades básicas, estabelecendo precedência e dependência entre as mesmas (FALBO, 1998).

Processos de software definem o conjunto de atividades conduzidas no contexto do projeto, tais como análise de requisitos, projeto, codificação, teste, instalação etc, os recursos (software, hardware e pessoas) necessários e os procedimentos a serem adotados na realização de cada uma das atividades. Sendo que essas atividades são compostas por outras atividades e podem se comunicar entre si e operam sobre artefatos de entrada para produzir artefatos de saída (FALBO, 1998) (GRUHN, 2002).

Outra questão que envolve a elaboração de um processo de software é a sua adequação ao domínio de aplicação e ao projeto. A cada projeto, o processo de software deve ser ajustado às especificidades da aplicação, tecnologia a ser utilizada na sua construção, grupo de desenvolvimento e usuários finais (FALBO, 1998).

2

2.2 Prototipação

Baseado no desenvolvimento de um protótipo com base no conhecimento dos requisitos iniciais para o sistema. O desenvolvimento é feito obedecendo à realização das diferentes etapas de análise de requisitos, o projeto, a codificação e os testes. Não necessariamente estas etapas devem ser realizadas de modo muito explícito ou formal

A definição de todos os requisitos necessários ao sistema pelo cliente ou usuário geralmente é uma tarefa muito difícil. É quase impossível prever como o sistema irá afetar o funcionamento das práticas de trabalho, como será a interação com outros sistemas e que operações dos usuários devem ser automatizadas. Mas para poder testar os requisitos de uma forma mais eficiente, seria necessária a utilização de um protótipo do sistema.

Um protótipo é uma versão inicial de um sistema de software, que é utilizada para mostrar conceitos, experimentar opções de projeto e, em geral, para conhecer mais sobre os problemas e suas possíveis soluções. O desenvolvimento rápido de um protótipo é essencial para que os custos sejam controlados e os usuários possam fazer experiências com o protótipo no início do processo de software.

Um protótipo de software apoia duas atividades do processo de engenharia de requisitos:

 Levantamento de requisitos - Os protótipos de sistema permitem que os usuários realizem experiências para ver como o sistema apoia seu trabalho. Eles obtêm novas ideias para os requisitos e podem identificar pontos positivos e negativos do software. Eles podem, então, propor novos requisitos de sistema.

 Validação de requisitos - O protótipo pode revelar erros e omissões nos requisitos propostos. Uma função descrita em uma especificação pode parecer útil e bem-definida. Contudo, quando essa função é utilizada com outras, os usuários muitas vezes acham que sua visão inicial era incorreta e incompleta. A especificação de sistema pode então ser modificada para refletir sua compreensão alterada dos requisitos.

Na maioria dos projetos, o primeiro sistema construído dificilmente será usável. Ele pode ser muito lento, muito grande, desajeitado em uso, ou todos os três. A questão administrativa, não é se deve construir um sistema-piloto e jogá-lo fora. Isso será feito. A única questão é se deve planejar antecipadamente a construção de algo que se vai jogar fora ou prometer entregar isso aos clientes.

O protótipo pode ser oferecido ao cliente em diferentes formas:

 protótipo em papel

 modelo executável em PC retratando a interface homem-máquina capacitando o cliente a compreender a forma de interação com o software;

 protótipo de trabalho que implemente um subconjunto dos requisitos indicados

programa existente (pacote) que permita representar todas ou parte das funções desejadas para o software a construir

Vantagens da prototipação:

 modelo de desenvolvimento interessante para alguns sistemas de grande porte que representem um certo grau de dificuldade para exprimir rigorosamente os requisitos

 é possível demonstrar a realizabilidade através da construção de um protótipo do sistema

 é possível obter uma versão, mesmo simplificada do que será o sistema, com um pequeno investimento inicial

 A experiência adquirida no desenvolvimento do protótipo vai ser de extrema utilidade nas etapas posteriores do desenvolvimento do sistema real, permitindo reduzir o seu custo e resultando num sistema melhor concebido

Problemas da prototipação:

 Quando informamos que o produto precisa ser reconstruído, o cliente exige que alguns acertos sejam aplicados para tornar o protótipo um produto; muito frequentemente, a gerência de desenvolvimento de software cede.

 O desenvolvedor muitas vezes faz concessões de implementação a fim de colocar um protótipo em funcionamento rapidamente. Depois de algum tempo, o desenvolvedor pode familiarizar-se com essas opções e esquecer-se de todas as razões pelas quais elas são inadequadas - a opção menos ideal se tornou então parte integrante do sistema.

3 LINGUAGEM DE PROGRAMAÇÃO

4 CONCLUSÃO

Responde-se aos objetivos sem, no entanto, justificá-los.

REFERÊNCIAS

http://www.inf.ufes.br/~falbo/download/aulas/es-g/2005-1/NotasDeAula.pdf

http://www.inf.ufes.br/~falbo/files/ProcessoSoftware.pdf

http://homepages.dcc.ufmg.br/~figueiredo/disciplinas/aulas/processos-software_v01.pdf

http://www.univasf.edu.br/~ricardo.aramos/disciplinas/ES_I_2012_2/Aula03_ModelosProcessos.pdf

http://www.inf.ufpr.br/lmperes/ciclos_vida/ModeloIncremental.pdf

...