O processo de desenvolvimento de software
O desenvolvimento de software
Os principais motivos que levam as organizações a desenvolverem sistemas são: o aumento da qualidade dos produtos e serviços, através da automatização das rotinas; a redução de custos; o aumento da vantagem competitiva sobre os concorrentes; o aumento do nível de serviço, do desempenho dos recursos humanos; a melhoria do processo de tomada de decisões pela administração da empresa.
Em nossa disciplina estudaremos um método para desenvolver sistemas. Muitas vezes queremos programar diretamente nossos sistemas em vez de projetá-los anteriormente. Porém, essa não é uma boa prática.
Estudos feitos nos EUA para se medir a produtividade no desenvolvimento de sistemas (STANDISH GROUP, 2011) revelaram que:
a) 30% a 40% dos projetos são cancelados;
b) 50% dos projetos custam mais que o dobro do custo inicialmente
projetado;
c) 15 a 20% dos projetos terminam dentro do prazo e dentro do orçamento.
Os principais problemas encontrados foram:
a) falta de qualidade do produto final;
b) não cumprimento dos prazos;
c) não cumprimento dos custos.
A partir desses resultados surgiram estudos de processos e técnicas para melhoraria da qualidade e confiabilidade dos produtos, e também a produtividade dos desenvolvedores.
Entre os resultados temos:
a) linguagens de programação mais produtivas;
b) metodologias de desenvolvimento de software;
c) ferramentas computacionais para o desenvolvimento e gerenciamento de projetos de software.
Dessa forma a melhor maneira de se aumentar a qualidade do software é definindo um processo eficaz de desenvolvimento que contemple todas as fases necessárias para sua produção.
Outros requisitos importantes devem ser atendidos:
a) flexibilidade: os sistemas devem ser facilmente alteráveis para garantir a sua evolução;
b) confiabilidade: o número de defeitos deve ser o menor possível;
c) desempenho: o sistema deve ter um desempenho razoável;
d) facilidade de uso: o sistema deve ser de fácil utilização.
Todo o processo de desenvolvimento de software é definido em um conjunto de disciplinas chamado Engenharia de Software que o IEEE (http://www.ieee.org) define como: aplicação de um processo sistemático, disciplinado e quantificado ao desenvolvimento, à operação e à manutenção de software.
Unified Modelling Language (UML)
O primeiro passo para a construção de um software é analisar o problema a ser resolvido, entender o sistema que ele representa e, em seguida, criar um modelo que represente sua solução. Para a criação desse modelo utilizaremos uma notação ou linguagem de modelagem chamada UML.
UML ou Unified Modelling
Language
É uma Linguagem de Modelagem Unificada: linguagem
gráfica que descreve os
principais elementos de sistemas
de software. A esses elementos
damos o nome de artefatos.
Modelos de desenvolvimento de software
Antes de prosseguirmos em nosso estudo, é importante diferenciarmos linguagem de modelagem de metodologia de desenvolvimento de sistemas. Enquanto uma metodologia define rigidamente todos os passos para a construção do software, desde a análise do problema até a entrega final do sistema, fazendo uso de regras e procedimentos para a execução de cada etapa, a linguagem de modelagem preocupa-se apenas com a definição de elementos que simbolizem o sistema a ser criado. Dessa forma, a linguagem de modelagem apresenta graficamente um modelo que representa o sistema em questão, sem a preocupação de definição de passos formais para se chegar a esse modelo. É importante ressaltar que uma mesma linguagem de modelagem pode ser usada por várias metodologias de desenvolvimento de sistemas; basta que os criadores dessas metodologias a escolham para modelar os elementos de seus sistemas.
Isso é muito importante, pois:
a) uma metodologia que funciona para a empresa X pode não funcionar para a empresa Y;
b) os níveis de qualidade podem variar para cada tipo de projeto, o que se reflete na metodologia;
c) a documentação pode variar para cada tipo de projeto, o que também se reflete na metodologia.
Além da UML, outras linguagens de modelagem são utilizadas pelos desenvolvedores de software, entre elas, podemos citar a Modelica, e a Java Modelling Language (JML). Porém, cada vez mais a UML se firma como a linguagem mais utilizada pelos analistas de sistemas. A UML é simplesmente uma linguagem, isto é, uma notação. Ela não diz como desenvolver software e sim como criar um modelo desse software.
Podemos dizer, então, que a UML é uma linguagem de modelagem e não uma metodologia de desenvolvimento! Conhecer a notação UML não significa utilizar uma metodologia X ou Y. Espera-se que a UML possa ser utilizada independentemente da metodologia de desenvolvimento de sistema!
Independentemente da linguagem de modelagem utilizada para desenvolver um sistema, as metodologias normalmente obedecem a um dos modelos a seguir:
a) Modelo em cascata
O modelo em cascata era o mais utilizado até a década de 1980. Nesse modelo cada etapa deve ser completada para que a seguinte possa ser realizada. Esse processo, mostrado da Figura 2.1, é simples e fácil de gerenciar e consiste em dividir a tarefa em tarefas menores e autocontidas.
Quando esse modelo foi proposto, no início do desenvolvimento dos sistemas, acreditava-se que ao se encerrar uma etapa do modelo, todas as informações necessárias sobre aquela fase já estavam capturadas. Por exemplo:
após a entrevista com o usuário sobre as necessidades de seus sistemas,
tudo que se precisaria saber para resolver seu problema já estava dito. Assim,
os desenvolvedores poderiam se concentrar na fase seguinte – Análise –
para darem continuidade ao processo de construção do software. O mesmo
acontecia com as etapas seguintes. Ao longo do tempo, verificou-se que,
muitas vezes, coisas importantes sobre etapas anteriores são descobertas
apenas no final do processo de desenvolvimento.Como a fase de análise é feita somente no início do projeto, o risco de não se compreenderem os requisitos do cliente é bastante alto. Mesmo seguindo um procedimento rígido de captura de requisitos, as chances de mudanças são altas à medida que o desenvolvedor conhece cada vez mais o sistema e seus requisitos. Para projetos pequenos, o modelo em cascata pode funcionar muito bem.
É importante lembrar que consideramos projetos pequenos aqueles que possuem pouca complexidade e poucos artefatos. Dessa forma, o uso do modelo em cascata não compromete a construção do sistema por não deixar de contemplar tudo o que é necessário em cada uma de suas etapas, já que são simples.
b) Modelo espiral
Nesse modelo o problema relatado pelo cliente é abordado em ciclos. Um ciclo completo é chamado de ciclo de vida e compreende as etapas de análise, projeto, implementação e testes.
Ao final de cada ciclo, temos a liberação de uma versão aprimorada do software, ou seja, uma versão mais completa (e mais correta) do software que o cliente necessita para resolver seu problema.
Esse modelo de desenvolvimento (Figura 2.2) é muito vantajoso, pois o grupo de desenvolvimento será capaz de trabalhar em todo um ciclo de vida do projeto (análise, projeto, implementação e testes) e o cliente vai fornecer “feedback” bem cedo para a equipe de desenvolvimento, tornando a detecção de problemas mais fácil e rápida.
Outra vantagem importante é que qualquer mudança no sistema pode ser incorporada ao ciclo seguinte.
Mas esse modelo não tem somente vantagens, ele também apresenta algumas desvantagens, que podemos citar:
a) o processo é mais difícil de gerenciar. O modelo espiral não se “encaixa” bem com as ferramentas de gerência de projetos tradicionais, tais como gráfico de Gantt, PERT, etc.;
b) pode ocorrer precipitação e entrega de código, sem que seja feita análise completa do alcance dos seus objetivos.
Normalmente o cliente fica satisfeito ao ver que as versões que são geradas de seu software estão ficando conforme sua expectativa. Isso mostra para os desenvolvedores que estão no caminho certo do desenvolvimento do sistema.
c) Modelo iterativo e incremental
Esse modelo é um aprimoramento do modelo espiral e incorpora mais formalismos e rigor.
O modelo é dividido em quatro fases:
a) concepção;
b) elaboração;
c) construção;
d) transição
Essas fases são realizadas em sequência e não devem ser confundidas com as etapas do modelo em cascata.
Vamos estudar cada uma dessas fases.
a) Concepção
Nessa fase estabelecemos o escopo do projeto e definimos uma visão geral dele. Em pequenos projetos, ela pode ser realizada durante um cafezinho com o cliente!
Nessa fase devemos:
• construir um documento, descrevendo a visão geral do sistema;
• fazer uma exploração inicial dos requisitos do cliente;
• construir um glossário inicial dos termos utilizados pelo cliente;
• fazer uma análise do negócio (viabilidade, previsão de investimentos, etc.);
• fazer uma análise de risco preliminar;
• traçar um plano de projeto preliminar.
b) Elaboração
Nessa fase analisamos o problema, acrescentamos mais detalhes ao plano de projeto preliminar e procuramos eliminar ou minimizar os riscos do projeto.
No final da fase de elaboração teremos uma visão geral e um melhor entendimento do problema, devido ao seu detalhamento.
Na UML temos dois modelos que ajudam nesse estágio:
• Modelo de caso de uso: que ajuda a entender e capturar os requisitos
do cliente;
• Modelo conceitual (diagrama de classes): que mostra os principais conceitos do sistema, os quais o cliente entende.
c) Construção
Nessa fase ocorre a construção de fato do software. Essa fase do projeto não é executada de modo linear, mas na forma do modelo espiral, fazendo uma série de iterações. Em cada uma dessas iterações utilizamos o modelo em cascata. Tornando cada iteração mais curta possível, evitamos os problemas do modelo em cascata (Figura 2.3).
Ao término de cada iteração temos o sistema um pouco mais desenvolvido. Após um conjunto de iterações, podemos ter a liberação de uma nova versão preliminar (pré-alfa, alfa, beta, etc.) do software.
d) Transição
A fase final está relacionada à colocação do produto final para o cliente.
As atividades típicas dessa fase são:
• liberação de versões Beta para alguns usuários da comunidade;
• teste de validação ou execução paralela;
• conversão de dados de sistemas antigos;
• treinamento de usuários;
• publicidade, distribuição e vendas.
A versão Beta é a versão de um produto que ainda se encontra em fase de desenvolvimento e testes. No entanto, esses produtos muitas vezes são popularizados bem antes de sair a versão final.
A fase de transição não deve ser confundida com a fase de teste tradicional. No início da fase de transição deve existir um produto completo, testado e operacional para os usuários (os clientes).
Resumo
Encerramos assim nossa segunda aula e vimos que muita informação nova foi aprendida. Esse conhecimento é necessário para que continuemos nosso estudo sobre a análise e o projeto de sistemas que atendam, cada vez mais, às necessidades de nossos clientes. Vale lembrar que, apesar dos problemas naturais para se desenvolver sistemas, é muito importante que sempre trabalhemos na construção de nosso software usando ferramentas adequadas. As metodologias e as linguagens de modelagem são fundamentais para esse trabalho. Vimos que a UML é a mais importante linguagem de modelagem usada atualmente e pode ser trabalhada dentro de várias metodologias. Vimos ainda que as metodologias podem adotar modelos que nos ajudam a alcançar mais qualidade em nossos produtos. Os modelos mais utilizados são aqueles que priorizam a satisfação final do cliente, como o Iterativo e Incremental.
Agora que já tivemos uma visão geral do processo de desenvolvimento de software e conhecemos as etapas necessárias para sua construção vamos, na próxima aula, aprender como trabalhar na primeira fase desse processo: o levantamento dos requisitos de um sistema. Essa fase é comum a todas as metodologias e se aplica a qualquer modelo de desenvolvimento de sistemas.
