Processo de desenvolvimento de software
Origem: Wikipédia, a enciclopédia livre.
| Processo de Desenvolvimento de Software |
|---|
| Este artigo é parte da série Processo de desenvolvimento de software |
| Atividade e Passos |
| Requirimentos | Arquitetura | Especificação | Implementação | Teste | Implantação | Manutenção |
| Modelos |
| Ágil | Cleanroom | Interativo | RAD | RUP | Spiral | Waterfall | XP | Scrum |
| Disciplinas de Apoio |
| Gerenciamento de configuração | Documentação | Gerenciamento de Projeto |
Um Processo de desenvolvimento de software é um conjunto de atividades, parcialmente ordenado, realizados com a finalidade de obter um produto de software. São estudados dentro da área de Engenharia de software e são considerados um dos principais mecanismos para obter software de qualidade e cumprir corretamente os contratos de desenvolvimento, sendo uma das respostas técnicas adequadas para resolver a Crise do software.
Índice |
[editar] Passos/Atividades Processo
- Analise de requerimento de software: A extração dos requerimentos de um desejado produto de software é a primeira tarefa na sua criação. Embora o cliente provavelmente acredite conhecer o que software deva fazer, esta tarefa requerer habilidade e a experiência em engenharia de software para reconhecer a incompletude, ambigüidade ou contradição nos requerimentos.
- Especificação: A especificação é a tarefa de descrever precisamente o software que será escrito, preferencialmente de uma forma matematicamente rigorosa. Na pratica, somente especificações mais bem sucedidas foram escritas para aplicações bem compreendidas e afinadas que já estavam bem desenvolvidas, embora sistemas software de missão critica sejam freqüentemente bem especificados antes do desenvolvimento da aplicação. Especificações são mais importantes para interfaces externas que devem permanecer estáveis.
- Arquitetura de Software: A arquitetura de um sistema de software remete a uma representação abstrata daquele sistema. Arquitetura é concernente a garantia de que o sistema de software ira de encontro ao requerimentos do produto, como também assegurar que futuros requerimentos possam ser atendidos. A etapa da arquitetura também direciona as interfaces entre os sistemas de software e outro produtos de software, como também com o hardware básico ou sistema operacional.
- Implementação (ou codificação): A transformação de um projeto para um código dever ser a parte mais evidente do trabalho da engenharia de software, mas não necessariamente a sua maior porção.
- Teste: Teste de partes do software, especialmente onde foi onde tenha sido codificado por dois engenheiros trabalhando junto, é um papel da engenharia de software.
- Documentação: Uma importante tarefa (freqüentemente desprezada) é a documentação do projeto interno do software para propósitos de futuras manutenções e aprimoramentos. As documentações mais importantes são das interfaces externas.
- Suporte e Treinamento de Software: Uma grande porcentagem dos projeto de software falham porque o desenvolvedor não perceber que não importa quanto tempo a equipe de planejamento e desenvolvimento ira gastar na criação do software se ninguém da organização ira usá-lo. As pessoas são ocasionalmente resistem a mudança e evitam aventurar-se em áreas pouco familiares, então como uma parte da fase de desenvolvimento, é muito importante o treinamento para os usuários de software mais entusiasmados (construindo a expectativa e confidencia), alternando o treinamento o treinamento na direção de usuários neutros misturados como os apoiadores ávidos. Usuário irão ter muitas questões e problemas de software os quais conduziram para a próxima fase do software.
- Manutenção: A manutenção e melhoria de software lidam com a descoberta de novos problemas e requerimentos. Ela pode tomar mais tempo que o gasto no desenvolvimento inicial do software. Não somente pode ser necessário adicionar código que combinam com projeto original, mas determinar como o software trabalhara em algum ponto depois da manutenção estar completa pode requerer um significativo esforço por parte de um engenheiro de software. Cera de ⅔ de todos os engenheiro de software trabalham com a manutenção, mas estas estatísticas pode estar enganadas. Um pequena parte disto e consertando erros. A maioria das manutenção é para ampliar os sistemas para novas funcionalidades, as quais de diversas formas pode ser considerada um novo trabalho. Em comparação, cerca de ⅔ de todos os engenheiros civis, arquitetos e construtores trabalham com manutenção de uma forma similar.
[editar] Padrões
O processo de desenvolvimento de software tem sido objetivo de vários padrões, que visam a certificação de empresas como possuidoras de um processo de desenvolvimento, o que garantia certo grau de confiança aos seus contratantes.
Alguns padrões existentes atualmente:
[editar] Modelo de Processo
Há uma década, vem se tentando encontrar um processo ou metodologia previsível e repetível que melhore a produtividade e qualidade. Alguns tentaram sintetizar e formalizar a tarefa aparentemente incontrolável de escrever um software. Outros aplicaram técnicas de gerenciamento de projeto na escrita de software. Sem o gerenciamento de projeto, projetos de software podem facilmente sofrer atraso ou estourar o orçamento. Como um grande número de projetos de software não atendem suas expectativas em termos de funcionalidades, custo, ou cronograma de entrega, o efetivo gerenciamento de projeto esta provando ser muito difícil.
[editar] Processo em cascata
O mais antigo e bem conhecido processo é o modelo em cascata, onde os desenvolvedores (a grosso modo) seguem estes passos em ordem. Eles estabelecem os requerimentos, os analisam, projetam uma abordagem para solução, arquitetam um esboço do software para a solução, implementam o código, testam (inicialmente os testes unitários e então os testes de sistema), implantam e mantem. Depois que cada passo é terminado, o processo segue para o próximo passo, tal como construtores que não revisão as fundações de uma casa depois que as paredes foram erguidas. Se as interações não é incluída no planejamento, o processo não tem meios para corrigir os erros nas etapas inicias (por exemplo, nos requerimentos), então o processo inteiro (caro) da engenharia de software deve ser executado até o fim, resultando em funcionalidades de software desnecessárias ou sem uso.
No processo (CMM) no antigo estilo, a arquitetura e projeto precedia a codificação, algumas vezes separados as pessoas em diferentes etapas do porcesso.
[editar] Processos Interativos
O desenvolvimento interativo prescreve a construção de uma porção pequena, mas abrangente, do projeto de software para ajudar a todos os envolvidos a descobrir cedo os problemas ou suposições falhas que possam a levar ao desastre. O processo interativo é preferido por desenvolvedores comerciais porque lhes fornecer um potencial para atingir os objetivos de projeto de um cliente que não sabe exatamente o que querem.
Processos de desenvolvimento de software ágil são construídos na fundamentação do desenvolvimento interativo. Os processos ágeis usam o feedback, mais que o planejamento, como seus mecanismo de controle primário. O feedback é produzido por testes regulares e versões do software envolvido.
[editar] Processos ágeis
Os processos ágeis parecem ser mais eficientes do que as metodologias antigas, utilizando menos o tempo do programador para mais software funcionais de alta qualidade, mais tem a desvantagem de uma perspectiva de negocio que não prove uma capacidade de planejamento em longo prazo. Em essência, eles dizem prover mais funcionalidade por dólar, mas não dizem exatamente o que a funcionalidade ira fazer.
Exitem varias metodologias que podem ser consideradas como abordagens ágeis entre elas: Scrum, Extreme Programing, FDD, Crystal Clear, DSDM entre outras.
A Extreme Programming, XP, é o mais bem conhecido processo ágil, em XP, as fases são continuadas em passos extremamente pequenos (ou contínuos) comparados aos processos antigos. O primeira passada (interação incompleta) através das etapas deve levar um dia ou uma semana, ao invés de meses ou anos para cada fase completa do modelo em cascata, Primeiramente, escreve-se um autômato de teste, que prove objetivos concretos para o desenvolvimento. Depois e codificado (por um par de programadores), este passo esta completo quando todos os testes se concluem, e os programadores não podem pensar em nada mais que possa ser testado. Projetistas e Arquitetos executam uma refatoração do código. O projeto é feito pelas pessoas que estão codificando. O sistema incompleto mas funcional é entregue e demonstrado para os usuários. Neste ponto, os envolvidos iniciam novamente uma nova fase de escrita e teste para as próximas partes mais importantes do sistema.
[editar] Método formal
O Métodos Formais são abordagem matemáticas para resolver problemas de software e hardware ao nível de requerimento, especificação e projeto. Exemplos de métodos formais incluem Método-B, Redes Petri, RAISE e VDM. Várias notações de especificação formal estão disponíveis, tais como a notação-Z. De forma mais genérica, a teoria do autômato pode ser usada para construir e validar o comportamento da aplicação para o projeto de um sistema de maquina de estado finito.
Maquinas de estado finito baseadas nestas metodologias permitiram especificar software executáveis e contornar a codificação convencional.
[editar] Veja também
Alguns métodos de desenvolvimento de software:
- Modelo em cascata
- Modelo em espiral
- Modelo desenvolvimento dirigido
- Modelo baseado experiência usuario
- Modelo Bottom Up
- Modelo Caotico
- Prototipação evolucionária
- Prototipação
- Modelo TopDown
- Modelo V
- Extreme Programming
- Scrum
Temas relacionados
- Desenvolvimento de Software
- Modelo abstrato
- Modelo IPO+S
- Lista tópicos de engenharia de software
- Processo
- Paradigma da programação
- Projeto
- Ciclo de vida de desenvolvimento de sistema
- Documentação de Software
- Projeto de Sistemas
- Lista de filosofias de desenvolvimento de software
- Esforço de teste
- RUP
- Praxis
