Aulas 2 e 3 – Introdução à Processos

de Software
Professora: Carla Ilane Moreira Bezerra
 Sumário

1. Processo de Software
2. Ciclo de Vida
3. Benefícios do Processo
O que é Processo de Software?
 Um conjunto estruturado de atividades necessárias para
o desenvolvimento de um sistema de software
 Especificação;
 Projeto;
 Validação;
 Evolução.
 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).
O que é Processo 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 (FALBO, 1998).
 Uma seqüência de passos requeridos para realizar uma
tarefa (procedimento médico, operação militar, ou o
desenvolvimento ou manutenção de um software), com o
objetivo de auxiliar os envolvidos na execução das tarefas
e na realização dos trabalhos de forma coordenada, com
cada um auxiliando o outro (HUMPHERY,2005).
Processo x Modelo de Processo
 Processo de software refere-se a todas as atividades, bem
como relacionamentos, artefatos, ferramentas, papéis etc,
necessárias para construir, entregar e manter um produto
de software.
 Um modelo de processo de software ou ciclo de vida de
software é uma representação abstrata do processo. Ele
apresenta a descrição de um processo a partir de uma
perspectiva particular.
Modelos de Processo de Software

Define diferentes fases na existência de um produto de software

Define também princípios e diretrizes que vão guiar a realização destas

fases

Organiza as macroatividades básicas, estabelecendo precedência e

dependência entre as mesmas

Define estrutura e filosofia segundo as quais o processo de software tem

que ser executado

No desenvolvimento de software, o ponto de partida para a arquitetura

de um processo é a escolha de um modelo de ciclo de vida
Modelos de Processo de Software

Outras características
devem ser levadas em
consideração durante a
vida de um produto de
software:
A adoção de um ciclo de • Organização das
vida não é suficiente para atividades do processo
guiar e controlar um
projeto de software na • Recursos humanos,
prática hardware e software
• Procedimentos de
operação
• Políticas de
desenvolvimento e
restrições
• Tipos de software
Modelos de Processo de Software

• Descrever principais fases do

desenvolvimento
Características • Definir principais atividades a serem
realizadas durante cada uma das fases
básicas
• Especificar produtos de cada uma das
comuns aos fases e insumos para o início das fases
modelos: • Fornecer um framework sobre o qual as
atividades necessárias podem ser
mapeadas
Modelos de processo de software

 O modelo cascata
 Fases separadas e distintas de especificação e desenvolvimento.
 Desenvolvimento evolucionário ou evolutivo
 Especificação, desenvolvimento e validação são intercalados.
 Desenvolvimento incremental
 As entrega são separadas em incrementos, sendo que cada
incremento fornece parte da funcionalidade solicitada
 Desenvolvimento em espiral
 É representado em forma de espiral e cada loop no espiral
representa uma fase do processo
Modelo cascata

Clássico, seqüencial, linear ou waterfall

Modelo mais antigo e o mais amplamente usado na ES,

Modelado em função do ciclo da engenharia convencional

Requer uma abordagem sistemática e seqüencial ao desenvolvimento de software

Adequado em situações nas quais os requisitos são bem entendidos e o gerente do

projeto confia na capacidade da equipe de desenvolver utilizando o processo
Modelo cascata
Fases do modelo cascata
 Análise e definição de requisitos
 Projeto de sistema e software
 Implementação e teste de unidade
 Integração e teste de sistema
 Operação e manutenção
Vantagens do modelo cascata
 Fase única de requisitos leva à especificação antes do
projeto e ao projeto antes da codificação
 Uso de revisões ao fim de cada fase permite o
envolvimento do usuário
 O modelo permite que se imponha um controle de
configuração
 Cada passo serve como uma base aprovada e
documentada para o passo seguinte
 Toda fase do projeto pode ser cuidadosamente planejada
 Responsabilidades podem ser claramente definidas
 Existência de marcos ao fim de cada fase
Problemas do modelo cascata
 A principal desvantagem do modelo cascata é a
dificuldade de acomodação das mudanças depois que o
processo está em andamento. Uma fase tem de estar
completa antes de passar para a próxima.
 Particionamento inflexível do projeto em estágios
distintos, dificulta a resposta aos requisitos de mudança
do cliente.
 Portanto, este modelo é apropriado somente quando os
requisitos são bem compreendidos, e quando as
mudanças forem bastante limitadas durante o
desenvolvimento do sistema.
 Poucos sistemas de negócio têm requisitos estáveis.
 O modelo cascata é o mais usado em projetos de
engenharia de sistemas de grande porte, onde um sistema
é desenvolvido em várias localidades.
Problemas do modelo cascata
 O fluxo seqüencial geralmente não é seguido em projetos
reais
 Requisitos devem ser estabelecidos de maneira completa,
correta e clara no início do projeto
 Dependência de requisitos corretos e estáveis
 O usuário (cliente) muitas vezes não consegue explicar
todos os requisitos inicialmente
 Aplicação deve ser entendida pelo desenvolvedor desde o
início do projeto
 Difícil avaliar o progresso verdadeiro do projeto durante
as primeiras fases
 Uma versão executável do software só fica disponível
numa etapa avançada do desenvolvimento
 Grande esforço de integração e testes no final do projeto
 Desenvolvimento evolucionário
ou evolutivo
 Versões parciais são desenvolvidas para atendimento aos
requisitos conhecidos inicialmente
 Primeira versão utilizada para refinar os requisitos de
uma segunda versão
 A partir do conhecimento sobre os requisitos, obtido
com o uso, continua-se o desenvolvimento, evoluindo o
produto
 Modelo baseado em:
 Versão inicial de implementação
 Entrega de implementações intermediárias
 Verificações constantes pelo usuário até entrega de uma
versão final
 Desenvolvimento evolucionário ou evolutivo
 Desenvolvimento exploratório
 O objetivo é trabalhar com os clientes e desenvolver um sistema final a
partir de uma especificação inicial. Deve iniciar com requisitos bem
compreendidos e adicionar novas características à medida que forem
propostas pelo cliente.
 Prototipação
 O objetivo é compreender os requisitos de sistema. Deve iniciar com
requisitos mal compreendidos para esclarecer o que é realmente
necessário.
Desenvolvimento Exploratório

 Aplicabilidade
 Para sistemas interativos de pequeno e médio portes;
 Para partes de um sistema de grande porte (por exemplo, a
interface de usuário);
 Para sistema com curto ciclo de vida.
 Vantagens:
 Adequado quando os requisitos não podem ser
completamente especificados de início
 O uso do sistema pode aumentar o conhecimento sobre o
produto e melhorar os requisitos
 Produz sistemas que atendem às necessidades imediatas do
cliente
Desenvolvimento Exploratório
 Desvantagens:
 Necessária uma forte gerência de custo, cronograma e
configuração
 Usuários podem não entender a natureza da abordagem e se
decepcionar quando os resultados são não satisfatórios
 O processo não é visível
 Não se produzem documentos que reflitam as versões do sistema
 Freqüentemente são mal estruturados
 Software sem estrutura
 Modificações cada vez mais custosas
Prototipação

 Protótipos podem ser utilizados para:

 Explorar requisitos que serão implementados
posteriormente em um incremento funcional
 Determinar a viabilidade técnica, de custo e de
cronograma para o projeto
 Objetivo
 Entender os requisitos do sistema
 O protótipo concentra-se na verificação dos
pontos pouco entendidos do sistema
Prototipação

Obter Requisitos

Elaborar Projeto Rápido

Refinar Protótipo

Construir Protótipo
Avaliar Protótipo
21
Prototipação

• Desenvolvedor e cliente definem os objetivos gerais do software

Obter Requisitos • Identificação de quais requisitos são conhecidos e as áreas que
necessitam de definições adicionais

Elaborar Projeto • Representação dos aspectos do software que são visíveis ao usuário
Rápido • Abordagens de entrada e formatos de saída

Construir • Implementação rápida do projeto

Protótipo

Avaliar Protótipo • Cliente e desenvolvedor avaliam o protótipo

Refinar Protótipo • Cliente e desenvolvedor refinam os requisitos do software a ser

desenvolvido

22
Prototipação
Modelo executável
retratando a interface
Protótipo de trabalho
homem-máquina
que implemente um
capacitando o cliente a
subconjunto dos
compreender a forma
requisitos indicados
de interação com o
software

Programa existente
(pacote) que permita
representar todas ou
Protótipo em papel
O protótipo parte das funções
desejadas para o
pode ser software a construir
oferecido ao
cliente em
diferentes
formas:

23
Prototipação
 Vantagens:
 Um protótipo deve ser submetido a uma avaliação
 Geralmente realizada pelo cliente
 O fato de o cliente poder interagir com um protótipo ajuda a
balancear suas necessidades funcionais e de desempenho
 Os desenvolvedores podem implementar os requisitos
baseado no feedback do usuário
 Modelo de desenvolvimento interessante para alguns sistemas
de grande porte que representem um certo grau de dificuldade
para exprimir rigorosamente os requisitos
 A experiência adquirida no desenvolvimento do protótipo vai
ser de extrema utilidade nas etapas posteriores do
desenvolvimento do sistema real, permitindo reduzir custo e
resultando num sistema melhor concebido
Prototipação
 Desvantagens:
 Clientes imaginam que a maior parte do trabalho já foi feita
 Protótipo pode crescer de maneira não planejada, se tornando
um incremento funcional
 Protótipo pode ter um desempenho melhor do que um
incremento funcional, pois não implementa toda a funcionalidade,
causando frustração aos clientes quando o sistema completo é
entregue
 Quando informamos que o produto precisa ser reconstruído, o
cliente exige que alguns acertos sejam aplicados para tornar o
protótipo um produto, e muito freqüentemente, 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
 A opção menos ideal se tornou então parte integrante do sistema
Desenvolvimento espiral
 O processo é representado como uma espiral ao invés de
uma seqüência de atividades com realimentação.
 Cada loop na espiral representa uma fase no processo.
 Sem fases definidas, tais como especificação ou projeto –
os loops na espiral são escolhidos dependendo do que é
requisitado.
 Os riscos são explicitamente avaliados e resolvidos ao
longo do processo.
Modelo espiral do processo de software
Modelo espiral do processo de software
 Setores do modelo espiral
 Definição de objetivos
 Objetivos específicos para a fase são identificados.
 Avaliação e redução de riscos
 Riscos são avaliados e atividades são realizadas para reduzir os riscos-chave.
 Desenvolvimento e validação
 Um modelo de desenvolvimento para o sistema, que pode ser qualquer um
dos modelos genéricos, é escolhido.
 Planejamento
 O projeto é revisado e a próxima fase da espiral é planejada.
 Vantagens
 O modelo em espiral permite que ao longo de cada iteração
se obtenham versões do sistema cada vez mais completas,
recorrendo à prototipagem para reduzir os riscos
 Este tipo de modelo permite a abordagem do refinamento
seguido pelo modelo em cascata, mas que incorpora um
enquadramento iterativo que reflete, de uma forma bastante
realística, o processo de desenvolvimento
▪ Não faz distinção entre desenvolvimento e manutenção
 Desvantagens

 Pode ser difícil convencer grandes clientes de que a abordagem

evolutiva é controlável
 A abordagem deste tipo de modelo exige considerável experiência
na avaliação dos riscos e fia-se nessa experiência para o sucesso
 Este tipo de modelo é relativamente novo e não tem sido
amplamente usado
 É importante ter em conta que podem existir diferenças entre o
protótipo e o sistema final. O protótipo pode não cumprir os
requisitos de desempenho, pode ser incompleto, e pode refletir
somente algumas funcionalidades do sistema a desenvolver.
 Gerenciamento de custo e prazo do projeto complexo
▪ Bem aplicado somente a sistemas de larga escala
Iteração de processo
 O sistema de software é desenvolvido em vários passos similares
 Idéia de melhorar (ou refinar) pouco a pouco o sistema (iterações)
 Em cada iteração a equipe de desenvolvimento:
 Identifica e especifica os requisitos relevantes
 Cria um projeto utilizando a arquitetura escolhida como guia
 Implementa o projeto em componentes
 Verifica se esses componentes satisfazem os requisitos
 Se uma iteração atinge os seus objetivos, o desenvolvimento
prossegue com a próxima iteração
 Caso contrário a equipe deve rever as suas decisões e tentar uma
nova abordagem
 Conclusão:
 O âmbito do sistema não é alterado
 Seu detalhe vai aumentando em iterações sucessivas
 Entrega incremental
 Em cada passo, o sistema é estendido com mais
funcionalidades
 Ideia de aumentar pouco-a-pouco o âmbito do sistema
 Um incremento não é necessariamente a adição do código
executável correspondente aos casos de uso que pertencem à
iteração em andamento
 Especialmente nas primeiras fases do ciclo de desenvolvimento,
os desenvolvedores podem substituir um projeto superficial
por um mais detalhado ou sofisticado
 Em fases avançadas os incrementos são tipicamente aditivos
 Entrega incremental

 Ao invés de entregar o sistema como uma única entrega, o

desenvolvimento e a entrega são separados em incrementos,
sendo que cada incremento fornece parte da funcionalidade
solicitada
 Os requisitos de usuário são priorizados e os requisitos de
prioridade mais alta são incluídos nos incrementos iniciais
 Uma vez que o desenvolvimento de um incremento é iniciado,
os requisitos são congelados, embora os requisitos para os
incrementos posteriores possam continuar evoluindo
Modelo incremental

Requisitos são segmentados em uma série incremental de produtos

Repetição do processo até que um produto completo seja produzido

Segmentação dos requisitos realizada antes do desenvolvimento da primeira versão

Adotado quando os requisitos são conhecidos no início do desenvolvimento

Necessidade de entrega de um produto funcional em pouco tempo

Cada incremento produz uma versão operacional do software

35
 Entrega incremental
 Exemplo

 O desenvolvimento de um produto comercial de software é uma

grande tarefa que pode ser estendida por vários meses,
possivelmente um ano ou mais

 É mais fácil dividir o trabalho em partes menores (iterações) tendo

cada uma como resultado um incremento (processo incremental)

 Assim a equipe envolvida pode refinar e melhorar gradativamente a

qualidade e os detalhes do sistema
Desenvolvimento incremental
Vantangens do desenvolvimento
incremental
 O valor pode ser entregue para o cliente com cada
incremento e, desse modo, a funcionalidade de sistema é
disponibilizada mais cedo.
 O incremento inicial age como um protótipo para auxiliar
a elicitar os requisitos para incrementos posteriores do
sistema.
 Riscos menores de falha geral do projeto.
 Os serviços de sistema de mais alta prioridade tendem a
receber mais testes.
Vantangens do desenvolvimento
incremental
 Menor custo e menos tempo são necessários para se entregar
a primeira versão
 Número de mudanças nos requisitos pode diminuir devido ao
curto tempo de desenvolvimento da primeira versão
 Aceleração do tempo de desenvolvimento do projeto como
um todo, porque os desenvolvedores trabalham de maneira
mais eficiente quando buscam resultados de escopo pequeno e
claro
 Reconhecimento de uma realidade freqüentemente ignorada:
 Necessidades dos usuários e os requisitos correspondentes podem
não podem ser totalmente definidos no início do processo
 Tipicamente refinados em sucessivas iterações
Desvantangens do desenvolvimento
incremental
 Se os requisitos não são tão estáveis ou completos
quanto se esperava, alguns incrementos podem precisar
ser retirados de uso e retrabalhados

 Retrabalho

 O gerenciamento de custo, cronograma e configuração é

mais complexo
Benefícios da definição e utilização de
modelos de processos
 A descrição e utilização de modelos de processos de
software resultam em diversos benefícios às organizações
de desenvolvimento de software:
 Permite que o conhecimento e experiências sobre um
processo sejam organizados e conseqüentemente
incorporados ao processo ou reaproveitadas em outro
processo;
 Auxilia na tomada de decisão em situações imprevistas;
 Torna possível a identificação de tarefas críticas;
 Atribui maior visibilidade aos processos;
 Forma uma base para a elaboração de guias, scripts, manuais;
 Auxilia no gerenciamento do projeto (organização,
planejamento, alocação de recursos, estimativas etc);
Benefícios da definição e utilização de
modelos de processos
 A descrição e utilização de modelos de processos de
software resultam em diversos benefícios às organizações
de desenvolvimento de software:
 Estabelece bases que podem ser avaliadas para análise e
mudanças para melhoria do processo de software;
 Possibilita que novas tecnologias sejam avaliadas e
incorporadas ao processo de software;
 Habilita a empresa na definição de programas de mensuração.
Conclusões
 Definir o ciclo de vida adequado às características do
projeto é essencial para o seu sucesso
 Deve-se analisar os pontos fortes e fracos de cada
modelo de ciclo de vida e escolher o que ofereça
melhores condições para o desenvolvimento do software
 Pontos importantes
 variação da especificação dos requisitos ao longo do projeto
 complexidade do sistema a ser desenvolvido
 características específicas do projeto
Caso 1
 Objetivo: desenvolver um sistema para uma aplicação de
comércio eletrônico. Apesar do cliente ter uma certa
urgência em colocar o sistema em operação, os requisitos
para o mesmo não se encontram bem definidos. O cliente
se comprometeu em acompanhar o desenvolvimento.
Porém, este possui dificuldades em expressar os
requisitos do sistema.
 Possibilidades: Cascata, Evolutivo, Espiral, Incremental,
Prototipação.
Caso 1
 Objetivo: desenvolver um sistema para uma aplicação de
comércio eletrônico. Apesar do cliente ter uma certa
urgência em colocar o sistema em operação, os requisitos
para o mesmo não se encontram bem definidos. O cliente
se comprometeu em acompanhar o desenvolvimento.
Porém, este possui dificuldades em expressar os
requisitos do sistema.
 Resposta: Prototipação
Caso 2
 Objetivo:desenvolver um sistema de cadastro de usuários
de uma biblioteca virtual. Os requisitos para o sistema
foram fornecidos pelo usuário de antemão e estão
relativamente bem definidos. A organização dispõe de
uma quantidade adequada de desenvolvedores
experientes no domínio da aplicação. Porém, há uma alta
disputa interna entre a equipe de desenvolvimento.
 Possibilidades: Cascata, Evolutivo, Espiral, Incremental,
Prototipação.
Caso 2
 Objetivo:desenvolver um sistema de cadastro de usuários
de uma biblioteca virtual. Os requisitos para o sistema
foram fornecidos pelo usuário de antemão e estão
relativamente bem definidos. A organização dispõe de
uma quantidade adequada de desenvolvedores
experientes no domínio da aplicação. Porém, há uma alta
disputa interna entre a equipe de desenvolvimento.
 Reposta: Cascata
 Motivação
 Muitas empresas buscam pela qualidade tanto de seus produtos
quanto de seus processos de software.

Abandono de
Acúmulo planos e Produto funciona, mas com
procedimentos defeitos; prazo e custo
de trabalho
maiores; e menos
funcionalidade

Clientes e
Sucesso depende muito do funcionários
esforço heróico das pessoas Pouca insatisfeitos
repetibilidade
Motivação
 Benefícios da qualidade:
 Maior produtividade
 Redução de defeitos no produto
 Aumento da confiabilidade do produto
 Menos esforço de re-trabalho
 Redução de custo de desenvolvimento e manutenção
 Maior competitividade
 Maior índice de satisfação
Custo Relativo para Correção de Defeitos
Custo no Desenvolvimento com e sem
Inspeções
Papéis
 Papel
 descreve como as pessoas se comportam no processo e quais
são as
 responsabilidades que elas têm
 requer habilidades específicas necessárias
 papéis não são pessoas
 pessoas executam papéis
Primeiros Passos - Papéis
• Administrador de Rede
• Analista de Qualidade
• Analista de Requisitos
• Analista de Negócios
• Analista de Testes
• Arquiteto de Software
• Consultor
• Desenvolvedor
Cada papel tem sua
importância, disciplina, • Gerente de
artefatos associados e Configuração
atividades pré-definidas • Gerente de Projetos
• Testador
• ...
Tarefas
 Tarefa
 é uma ação desempenhada por alguma pessoa visando a
realização ou monitoramento do projeto
 não representa uma evidência de progresso no
desenvolvimento
 ter trabalhado 20 horas não implica ter produzido um artefato de
qualidade, mesmo que se tenha estimado serem necessárias 20 horas
para o seu desenvolvimento
 consome recursos - consumo real
 esforço (tempo de pessoa)
 equipamento
 financeiro
Atividades
 Atividade
 conjunto de tarefas que levam a um ou mais artefatos de
qualidade controlada
 permite o controle da qualidade do resultado
 num extremo pode ser a mera constatação que o resultado existe
 no outro extremo pode envolver técnicas muito avançadas de
controle da qualidade
 o esforço é medido através das tarefas constituintes
 Atividades são “mini-projetos”
 possuem início e fim definidos
 consomem um volume finito de recursos
 produzem artefatos definidos
 possuem critérios de conclusão estabelecidos
Primeiros Passos - Atividades

• Análise e projeto de
software
• Desenvolvimento de
software
• Gerência de Configuração
• Gerência de Requisitos
• Gerência de Projetos
• Implantação

Categorização de processos • Modelagem de Negócios

que são, teoricamente, • Teste de Software
independente dos demais
Artefatos
 Artefato
 é um resultado de uma atividade, exemplos
 documento revisto e aceito
 módulo implementado, testado e aceito
 construto integrado, testado e aceito
 framework documentado, implementado, testado e aceito
 quando entregue ao usuário (cliente) o artefato é um produto
 Insumo
 elemento necessário para a realização de uma tarefa ou
atividade
 pode ser um elemento de saída de outras atividades ou tarefas
Primeiros Passos - Artefato
• Ator
• Burndown chart
• Caso de Teste
• Caso de Uso
• Código fonte
• E-mail
• Glossário
• Plano de iteração
• Requisito
• Exemplo:
Documento ou elemento
pertencente a este, que deve • Coleção de Requisitos
ser criado ou alterado • Caso de Uso
• Regra de Negócio
Exemplo
 Atividade: Realizar estimativas para o projeto
 Descrição
 A partir do escopo preliminar do projeto, detalhar as atividades necessárias a sua
realização, as estimativas de consumo de recursos, os prazos e orçamentos.
 Papel:
 Gerente de Projeto
 Artefatos de Entrada:
 Escopo do projeto; Plano do projeto; Acordo de serviço; Estrutura analítica do
projeto (EAP)
 Artefatos de Saída:
 Estimativas de custo da atividades; Estimativa de esforço das atividades,
Cronograma e Plano do projeto atualizados
 Tarefas:
 Detalhar atividades e recursos; Detalhar cronograma; Detalhar estimativa de
custo das atividades;
 Detalhar orçamento do projeto
Normas e Modelos de Qualidade de Processos
de Software
Vídeo

http://www.youtube.com/watch?v=L2zqTYgcpfg&p=09FD81C593
B3FA8F&playnext=1&index=21
Referências Bibliográficas
 Qualidade de Software. André Koscianski e Michel dos Santos
Soares. Editora Novatec. 2a Edição. ISBN 978-85-7522-112-9.
 Notas de Aula da disciplina de Qualidade de Software do
professor Alexandre Vasconcelos UFPE.
 FUGGETTA, A. 2000. Software process: a roadmap . In
Proceedings of the Conference on the Future of Software
Engineering (Limerick, Ireland, June 04 - 11, 2000). ICSE '00.
ACM, New York, NY, 25-34.
 HUMPHREY,Watts S. PSP: a self-improvement process for
software engineers. Addison-Wesley, 2005.
 Sommerville, Ian. Software Engineering . 8 th edition, Addison -
Wesley, 2006.
Dúvidas?

"A qualidade nunca se obtém por acaso; ela é

sempre o resultado do esforço inteligente."
(John Ruskin)