MCSI I Página |1

INSTITUTO POLITÉCNICO DA UNIVERSIDADE KIMPA VITA

DEPARTAMENTO DE ENGENHARIA INFORMATICA
Disciplina: Métodos de Concepção de Sistemas de Informação I – MCSI I
Curso: Licenciara em Engenharia Informática Período Lectivo: Iº Semestre
Docente: Joaquim João Nsaku Ventura “Assistente Estagiário” Aula nº 3
Horário: 16h:00min – 17h:45min Sala: Pavilhão IP-UNIKIVI Ano Curricular: 2º
Sumario: 2. O processo de desenvolvimento de software Data: 22 de outubro de 2021
Aula: Teórica Meios de Ensino: Quadro,
Marcador, PC e Projector
OBJECTIVOS:
✓ Conhecer o histórico do processo de desenvolvimento de software.
✓ Conhecer os paradigmas de desenvolvimento de software mais utilizados.
✓ Diferenciar as metodologias mais comuns.
✓ Conhecer o estado da arte com metodologias de desenvolvimento de software

2. O processo de desenvolvimento de software

2.1 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 cadeira estudaremos um método para desenvolver sistemas. Muitas

vezes queremos programar directamente nossos sistemas em vez de projectá-
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 projectos são cancelados;

b) 50% dos projectos custam mais que o dobro do custo inicialmente
projectado;
c) 15 a 20% dos projectos terminam dentro do prazo e dentro do
orçamento.

Os principais problemas encontrados foram:

jnsakuv@gmail.com https://groups.google.com/u/0/g/mcsii2021 IP-UNIKIVI/2021-2022

MCSI I Página |2

a) falta de qualidade do produto final;

b) não cumprimento dos prazos;
c) não cumprimento dos custos.

Processo é um conjunto de actividades bem definidas, que são

executadas em uma determinada ordem.

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
projectos 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.

Processo de desenvolvimento de Software é um conjunto de actividades

(práticas e técnicas) rigorosas, sistemáticas e controláveis que permitem
construir sistemas informatizados em um prazo e orçamento finitos em uma
determinada ordem.

Todo o processo de desenvolvimento de software é definido em um conjunto de

disciplinas chamado Engenharia de Software que o IEEE (http://www.ieee.org)

jnsakuv@gmail.com https://groups.google.com/u/0/g/mcsii2021 IP-UNIKIVI/2021-2022

MCSI I Página |3

define como: aplicação de um processo sistemático, disciplinado e quantificado

ao desenvolvimento, à operação e à manutenção de software.

2.2 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 artefactos.

2.3 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 projecto, o que se
reflecte na metodologia;
c) a documentação pode variar para cada tipo de projecto, o que também se
reflecte na metodologia.

jnsakuv@gmail.com https://groups.google.com/u/0/g/mcsii2021 IP-UNIKIVI/2021-2022

MCSI I Página |4

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:

d) 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 1, é simples e fácil de gerenciar e consiste em
dividir a tarefa em tarefas menores e autocontidas.

Figura 1. Modelo em cascata

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

jnsakuv@gmail.com https://groups.google.com/u/0/g/mcsii2021 IP-UNIKIVI/2021-2022

MCSI I Página |5

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.

Os principais problemas desse modelo são:

a) os sistemas devem ser totalmente entendidos e analisados, antes que

possam ser projectados e implementados. À medida que a complexidade
aumenta, mais difícil se torna o seu desenvolvimento e gerenciamento;
b) os riscos são protelados para as etapas finais. Os problemas só aparecem
nas etapas finais do projecto e o custo para correcção é muito alto;
c) em grandes projectos, cada etapa consome grande quantidade de tempo
e recursos.

Como a fase de análise é feita somente no início do projecto, 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 projectos pequenos, o modelo em cascata pode funcionar muito
bem.

É importante lembrar que consideramos projectos pequenos aqueles que

possuem pouca complexidade e poucos artefactos. 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.

a) 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,
projecto, 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 correcta) do software que o cliente
necessita para resolver seu problema. Esse modelo de desenvolvimento (Figura
2) é muito vantajoso, pois o grupo de desenvolvimento será capaz de trabalhar

jnsakuv@gmail.com https://groups.google.com/u/0/g/mcsii2021 IP-UNIKIVI/2021-2022

MCSI I Página |6

em todo um ciclo de vida do projecto (análise, projecto, 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.

Figura 2. Modelo espira

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 projectos 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 objectivos.

jnsakuv@gmail.com https://groups.google.com/u/0/g/mcsii2021 IP-UNIKIVI/2021-2022

MCSI I Página |7

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 projecto e definimos uma visão geral

dele. Em pequenos projectos, 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 projecto preliminar.

b) Elaboração

Nessa fase analisamos o problema, acrescentamos mais detalhes ao plano de

projecto preliminar e procuramos eliminar ou minimizar os riscos do projecto. 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:

jnsakuv@gmail.com https://groups.google.com/u/0/g/mcsii2021 IP-UNIKIVI/2021-2022

MCSI I Página |8

✓ 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 facto do software. Essa fase do projecto 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 3).

Figura 3. Etapas do processo iterativo

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

jnsakuv@gmail.com https://groups.google.com/u/0/g/mcsii2021 IP-UNIKIVI/2021-2022

MCSI I Página |9

A fase final está relacionada à colocação do produto final para o cliente. As

actividades 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).

3. Resumo
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 actualmente e pode ser trabalhada
dentro de várias metodologias. Vimos ainda que as metodologias podem adoptar
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.

jnsakuv@gmail.com https://groups.google.com/u/0/g/mcsii2021 IP-UNIKIVI/2021-2022