Processo de desenvolvimento de software

Um processo de desenvolvimento de software é um conjunto de atividades, parcialmente ordenadas,

com a finalidade de obter um produto de software. É estudado dentro da área de Engenharia de Software,
sendo considerado um dos principais mecanismos para se obter software de qualidade e cumprir
corretamente os contratos de desenvolvimento, sendo uma das respostas técnicas adequadas para
resolver a Crise do software.

Passos/Atividades Processo

 Análise de requisitos de software: A extração dos requisitos de um desejado produto de software é

a primeira tarefa na sua criação. Embora o cliente, provavelmente, acredite saber o que o software
deva fazer, esta tarefa requer habilidade e experiência em engenharia de software para reconhecer
a incompletude, ambigüidade ou contradição nos requisitos.

 Especificação: A especificação é a tarefa de descrever precisamente o software que será escrito,

preferencialmente de uma forma matematicamente rigorosa. Na prática, somente especificações
mais bem sucedidas foram escritas para aplicações bem compreendidas e afinadas que já estavam
bem desenvolvidas, embora sistemas de software de missão crítica 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 à garantia de que o sistema de software irá
ao encontro de requisitos do produto, como também assegurar que futuros requisitos possam ser
atendidos. A etapa da arquitetura também direciona as interfaces entre os sistemas de software e
outros produtos de software, como também com o hardware básico ou com o sistema operacional.

 Implementação (ou codificação): A transformação de um projeto para um código deve 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 tenha sido codificado por dois ou mais
engenheiros trabalhando juntos, é um papel da engenharia de software.

 Documentação: Uma importante tarefa é 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 projetos de software falham
pelo fato de o desenvolvedor não perceber que não importa quanto tempo a equipe de
planejamento e desenvolvimento irá gastar na criação do software se ninguém da organização irá
usá-lo. As pessoas ocasionalmente resistem à mudança e evitam aventurar-se em áreas pouco
familiares. Então, como parte da fase de desenvolvimento, é muito importante o treinamento para
os usuários de software mais entusiasmados, alternando o treinamento entre usuários neutros e
usuários favoráveis ao software. Usuários irão ter muitas questões e problemas de software os
quais conduzirão para a próxima fase.

 Manutenção: A manutenção e melhoria de software lidam com a descoberta de novos problemas e

requisitos. Ela pode tomar mais tempo que o gasto no desenvolvimento inicial do mesmo. Não
somente pode ser necessário adicionar códigos que combinem com o projeto original, mas
determinar como o software trabalhará em algum ponto depois da manutenção estar completa,
pode requerer um significativo esforço por parte de um engenheiro de software. Cerca de ⅔ de
todos os engenheiros de software trabalham com a manutenção, mas estas estatísticas podem
estar enganadas. Um pequena parte destes trabalha na correção de erros. A maioria das
manutenções são para ampliar os sistemas para novas funcionalidades, as quais, de diversas
formas, podem ser consideradas um novo trabalho. Analogamente, cerca de ⅔ de todos os
engenheiros civis, arquitetos e construtores trabalham com manutenção de uma forma similar.
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 garantiria certo grau de
confiança aos seus contratantes.

Alguns padrões existentes atualmente:

 CMMI (anteriormente CMM)

 SPICE
 ISO 12207
 MPS/Br

Modelos 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, ainda não existe um modelo de
processo perfeito para todas aplicações.

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 requisitos, os analisam, projetam uma
abordagem para solução, arquitetam um esboço do software, implementam o código, testam
(inicialmente os testes unitários e então os testes de sistema), implantam e mantêm. Depois que cada
passo é terminado, o processo segue para o próximo passo, tal como construtores que não revisam as
fundações de uma casa depois que as paredes foram erguidas. Se as iterações não são incluídas no
planejamento, o processo não tem meios para corrigir os erros nas etapas inicias (por exemplo, nos
requisitos), então o processo inteiro da engenharia de software deve ser executado até o fim, resultando
em funcionalidades de software desnecessárias ou sem uso.Para isso tem-que-se que fazer o implemento
dos requisitos anteriormente analisados pelo programador.

O modelo em cascata é um modelo de desenvolvimento de software seqüencial no qual o

desenvolvimento é visto como um fluir constante para frente (como uma cascata) através das fases de
análise de requisitos, projeto, implementação, testes (validação), integração, e manutenção de software.
A origem do termo cascata é freqüentemente citado como sendo um artigo publicado em 1970 por W. W.
Royce; ironicamente, Royce defendia um abordagem iterativa para o desenvolvimento de software e nem
mesmo usou o termo cascata. Royce originalmente descreve o que é hoje conhecido como o modelo em
cascata como um exemplo de um método que ele argumentava ser um risco e um convite para falhas.

História do modelo em cascata

Em 1970 Royce propôs o que é agora popularmente designado no modelo em cascata como um conceito
inicial, um modelo no qual ele argumentava ser defeituoso. Seu trabalho então explorou como o modelo
inicial poderia ser desenvolvido em um modelo iterativo, com feedback de cada fase influenciando as
próximas, de modo similar a muitos métodos amplamente utilizados hoje. Ironicamente, foi somente o
modelo inicial que mereceu destaque; e sua crítica ao modelo inicial sendo amplamente ignorada. O
modelo em cascata rapidamente não se tornou o que Royce pretendia, um projeto iterativo, mas ao invés
disto um modelo puramente seqüencialmente ordenado. Este artigo ira tratar o significado popular para o
modelo em cascata. Para um modelo iterativo similar a versão final de Royce, ver o modelo em espiral.

A despeito das intenções de Royce para o modelo em cascata ser modificado para um modelo iterativo, o
uso do modelo em cascata como um processo puramente seqüencial é ainda popular, e, para alguns, o
termo modelo em cascata veio se referir a uma abordagem para criação de software a qual é vista como
inflexível e não iterativa. Aqueles que usam o termo modelo em cascata de forma pejorativa para modelos
não iterativos aos quais não apreciam usualmente vêem o modelo em cascata em si como ingênuo e
inadequado para um processo do mundo real

Uso do modelo cascata

O Modelo em cascata estático. O andamento do processo flui de cima para baixo, como uma cascata.

No modelo em cascata original de Royce, as seguintes fases são seguidas em perfeita ordem:

1. Elicitação de requisitos
2. Projeto
3. Construção (implementação ou codificação)
4. Integração
5. Teste e depuração
6. Instalação
7. Manutenção de software

Para seguir um modelo em cascata, o progresso de uma fase para a próxima se da de uma forma
puramente seqüencial. Por exemplo, inicialmente completa-se a especificação de requerimento —
elaborando um conjunto rígido de requerimentos do software.

O software em questão é projetado e um blueprint e desenhado para implementadores seguirem — este

projeto deve ser um plano para implementação dos requerimentos dados. Quando e somente quando o
projeto está terminado, uma implementação para este projeto é feita pelos codificadores. Encaminhando-
se para o próximo estágio da fase de implementação, inicia-se a integração dos componentes de software
construídos por diferentes times de projeto. (Por exemplo, um grupo pode estar trabalhando no
componente de página web da Wikipedia e outros grupos pode estar trabalhando no componente servidor
da Wikipedia. Estes componentes devem ser integrados para juntos produzirem um sistema como um
todo). Após as fases de implementação e integração estarem completas, o produto de software é testado
e qualquer problema introduzido nas fases anteriores é removida aqui. Com isto o produto de software é
instalado, e mais tarde mantido pela introdução de novas funcionalidades e remoção de bugs.

Portanto o modelo em cascata move-se para a próxima fase somente quando a fase anterior esta
completa e perfeita. Desenvolvimento de fases no modelo em cascata são discretas, e não há pulo para
frente, para trás ou sobreposição entre elas.

Contudo, há vários modelos em cascata modificados (incluindo o modelo final de Royce) que podem ser
incluídos como variações maiores ou menores deste processo.

O Modelo em espiral é um processo de desenvolvimento de software que combina elementos de projeto

prototipação-em-etapas, em um esforço para combinar as vantagens dos conceitos de top-down e
bottom-up.
História

O modelo em espiral foi definido por Barry Boehm em seu artigo de 1988 A Spiral Model of Software
Development and Enhancement. Este modelo não foi o primeiro a discutir o Desenvolvimento iterativo e
incremental, mas ele foi o primeiro modelo a explicar o porque do modo iterativo. Como originalmente
antevisto, as iterações têm uma duração típica de 6 meses a dois anos. Cada fase inicia com um objetivo
esperado e termina como uma revisão pelo cliente do progresso (que deve ser interna) e assim por
diante. Esforços de análise e engenharia são aplicados em cada fase do projeto, com um olho focado no
objetivo do projeto.

Aplicação

Para uma típica aplicação, o modelo em espiral deverá significar que se tem uma visão grosseira dos
elementos como uma aplicação utilizável, adicionando características nas fases e, a determinado ponto, o
gráfico final.

O modelo espiral é usado com mais freqüência em grandes projetos. Para pequenos projetos, os conceitos
de desenvolvimento de software ágil torna-se uma alternativa mais viável. O Exército Americano tem
adotado o modelo em espiral para seus programas dos Sistemas de combate do futuro.

Vantagens

 Estimativas (por exemplo: cronogramas) tornam-se mais realísticas com o progresso do trabalho,
porque problemas importantes são descobertos mais cedo.
 É mais versátil para lidar com mudanças (sempre inevitáveis) que desenvolvimento de software
geralmente exigem.
 Engenheiros de software (que sempre estão impacientes com alongamento da fase de projeto)
podem começar o trabalho no sistema mais cedo

Processos Iterativos

O Desenvolvimento iterativo e incremental 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 iterativo é preferido por desenvolvedores
porque lhes fornece um potencial para atingir os objetivos de projeto de um cliente que não sabe
exatamente o que quer, ou quando não se conhece bem todos os aspectos da solução.

Processos de desenvolvimento ágil de software são construídos com os fundamentos do desenvolvimento

iterativo. Os processos ágeis usam o feedback, mais que o planejamento, como seus mecanismos de
controle primário. O feedback é produzido por testes regulares e das versões do software desenvolvido.

Processos ágeis

Os processos em Desenvolvimento ágil de software parecem ser mais eficientes do que as metodologias
antigas. Utiliza menos tempo do programador no desenvolvimento de softwares funcionais de alta
qualidade, mas tem a desvantagem de ter uma perspectiva de negocio que não provê uma capacidade de
planejamento em longo prazo. Em essência, eles provem mais funcionalidades por custo/benefício, mas
não dizem exatamente o que a funcionalidade irá fazer.

Existem várias metodologias que podem ser consideradas como abordagens ágeis, entre elas: Scrum,
Programação extrema, FDD, Crystal Clear, DSDM entre outras.

A Programação Extrema (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. A primeira passada
(iteraçã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
provê objetivos concretos para o desenvolvimento. Depois é codificado (por um par de programadores),
este passo está completo quando todos os testes se concluem, e os programadores não pensem em nada
mais que possa ser testado. Projetistas e Arquitetos executam uma refatoração do código. O projeto é
feito por 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.

Método formal

Os Métodos Formais são abordagens matemáticas para resolver problemas de software e hardware ao
nível de requisito, especificação e projetos. 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 máquina de estado finito.

Máquinas de estado finito baseadas nestas metodologias permitiram especificar software executáveis e
contornar a codificação convencional.