Tópicos

Engenharia de Software 1- Introdução à Engenharia de Software

2 - Fundamentos Organizacionais de Sistemas
de Informação
3- Gerência de projeto de software
4- Gerenciamento para a qualidade de
UFRA – ICIBE software
Prof. Walmir Couto 5- Acompanhamento do processo de
desenvolvimento de software.

Software Características do Software

1- Instruções 1. desenvolvido ou projetado por engenharia, não

quando executadas produzem a função e o manufaturado no sentido clássico
desempenho desejados
2 - Estruturas de Dados 2. não se desgasta mas se deteriora
possibilitam que os programas manipulem
adequadamente a informação 3. a maioria é feita sob medida em vez de ser
3 - Documentos montada a partir de componentes existentes
descrevem a operação e o uso dos programas

Curva de falhas para o Hardware Curva de falhas do Software

“mortalidade “desgaste” curva real

índice
infantil” índice de
de mudança
falhas
falhas

curva idealizada

tempo tempo

1
 Aplicações do Software
BÁSICO programas de apoio a outros programas Evolução do Software
DE TEMPO REAL monitora, analisa e controla eventos do
mundo real (1950 - 1965)
COMERCIAL operações comerciais e tomadas de ð O hardware sofreu contínuas mudanças
decisões administrativas
ð O software era uma arte "secundária" para a
CIENTÍFICO E DE algoritmos de processamento de números qual havia poucos métodos sistemáticos
ENGENHARIA
EMBUTIDO controla produtos e sistemas de mercados ð O hardware era de propósito geral
industriais e de consumo ð O software era específico para cada aplicação
DE COMPUTADOR processamento de textos, planilhas
PESSOAL
ð Não havia documentação
eletrônicas, diversões, etc.
DE INTELIGÊNCIA algoritmos não numéricos para resolver
ARTIFICIAL problemas que não sejam favoráveis à
computação ou à análise direta

Evolução do Software Evolução do Software

(1965 - 1975)
ð Multiprogramação e sistemas multiusuários (1975 - hoje)
ð Técnicas interativas ð Sistemas distribuídos
ð Sistemas de tempo real ð Redes locais e globais
ð 1a geração de SGBD’s ð Uso generalizado de microprocessadores -
ð Produto de software - software houses produtos inteligentes
ð Bibliotecas de Software
ð Hardware de baixo custo
ð Cresce no de sistemas baseado em computador
ð Impacto de consumo
ð Manutenção quase impossível
..... CRISE DE SOFTWARE ..... CRISE DE SOFTWARE (aflição crônica???)

Evolução do Software Crise de Software

(Quarta era do software: atualidade) Refere-se a um conjunto de problemas
encontrados no desenvolvimento de software:
Æ Tecnologias orientadas o objetos
(1) As estimativas de prazo e de custo freqüentemente
Æ Sistemas especialistas e software de inteligência
são imprecisas
artificial usados na prática
“Não dedicamos tempo para coletar dados sobre o
Æ Software de rede neural artificial processo de desenvolvimento de software”
Æ Computação Paralela “Sem nenhuma indicação sólida de produtividade, não
podemos avaliar com precisão a eficácia de novas
Æ Internet
ferramentas, métodos ou padrões”
..... CRISE DE SOFTWARE (aflição crônica???)

2
Crise de Software
(2) A produtividade das pessoas da área de software
não tem acompanhado a demanda por seus
serviços
“Os projetos de desenvolvimento de software
normalmente são efetuados apenas com um vago
indício das exigências do cliente”
Crise de Software
ü estimativas de prazo e de custo ­
ü produtividade das pessoas ¯
ü qualidade de software ¯
ü software difícil de manter ­
Causas dos problemas associados à
Crise de Software
2. falhas das pessoas responsáveis pelo
desenvolvimento de Software
Gerentes sem nenhum background em
software
Os profissionais da área de software têm
recebido pouco treinamento formal em novas
técnicas para o desenvolvimento de software
Resistência a mudanças.
Crise de Software
(3) A qualidade de software às vezes é menos que
adequada
Só recentemente começam a surgir conceitos
quantitativos sólidos de garantia de qualidade de
software
(4) O software existente é muito difícil de manter
A tarefa de manutenção devora o orçamento destinado
ao software
A facilidade de manutenção não foi enfatizada como
um critério importante
Causas dos problemas associados à
Crise de Software
1. próprio caráter do Software
O software é um elemento de sistema lógico e
não físico (produto intangível)
Conseqüentemente, o sucesso é medido pela
qualidade de uma única entidade e não pela
qualidade de muitas entidades manufaturadas
O software não se desgasta, mas se
deteriora!!!
Causas dos problemas associados à
Crise de Software
3. mitos do Software
propagaram desinformação e confusão
4administrativos
4cliente
4profissional
3
 Mitos do Software (administrativos) Mitos do Software (administrativos)

Já temos um manual repleto de padrões e

procedimentos para a construção de software. Isso
não oferecerá ao meu pessoal tudo o que eles
precisam saber?
Realidade:
Será que o manual é usado?
Os profissionais sabem que ele existe?
Ele reflete a prática moderna de desenvolvimento de software?
Ele é completo?
Meu pessoal tem ferramentas de desenvolvimento de
software de última geração; afinal lhes compramos
os mais novos computadores.
Realidade:
É preciso muito mais do que os mais recentes
computadores para se fazer um desenvolvimento de
software de alta qualidade.

Mitos do Software (administrativos) Mitos do Software (cliente)

Se nós estamos atrasados nos prazos, podemos Uma declaração geral dos objetivos é suficiente
adicionar mais programadores e tirar o atraso. para se começar a escrever programas -
podemos preencher os detalhes mais tarde.

Realidade:
O desenvolvimento de software não é um processo
mecânico igual à manufatura.
Acrescentar pessoas em um projeto torna-o ainda mais
atrasado. Pessoas podem ser acrescentadas, mas
somente de uma forma planejada.
Realidade:
Uma definição inicial ruim é a principal causa de fracassos dos
esforços de desenvolvimento de software.
É fundamental uma descrição formal e detalhada do domínio da
informação, função, desempenho, interfaces, restrições de
projeto e critérios de validação.

Mitos do Software (cliente) magnitude das mudanças

Os requisitos de projeto modificam-se

continuamente, mas as mudanças podem ser
facilmente acomodadas, porque o software é FASES CUSTO DE MANUTENÇÃO
flexível. DEFINIÇÃO 1x
DESENVOLVIMENTO 1.5 - 6x
Realidade:
MANUTENÇÃO 60 - 100x
Uma mudança, quando solicitada tardiamente num projeto,
pode ser maior do que mais do que uma ordem de magnitude
mais dispendiosa do que a mesma mudança solicitada nas
fases iniciais.

4
 Mitos do Software (profissional)
Assim que escrevermos o programa e o colocarmos
em funcionamento nosso trabalho estará completo.
Realidade:
Os dados da indústria indicam que entre 50 e 70% de todo
esforço gasto num programa serão despendidos depois que
ele for entregue pela primeira vez ao cliente.
Preocupação: Sistematizar o processo de
criação e manutenção de software.
Engenharia de Software
Definições
F IEEE Standard Glossary of Software Engineering
terminology: Engenharia de software é uma
abordagem sistemática para o desenvolvimento,
operação, manutenção de software
Software: programas de computador,
procedimentos, regras, documentação
possivelmente associada, e dados sobre sua
operação.
Mitos do Software (profissional)
Enquanto não tiver o programa "funcionando", eu
não terei realmente nenhuma maneira de avaliar
sua qualidade.
Realidade:
Um programa funcionando é somente uma parte de uma
Configuração de Software que inclui todos os itens de
informação produzidos durante a construção e manutenção do
software.
Engenharia de Software
Definições
F Boehm: Engenharia de software envolve a
aplicação prática de conhecimento científico para
o projeto e construção de programas de
computador e a documentação associada
necessária para desenvolvê-los, operá-los e
mantê-los.
Engenharia de Software
Definições
F Fairley: Engenharia de software é a disciplina
tecnologica e gerencial preocupada com a
produção sistemática e manutenção de produtos
de software que são desenvolvidos e modificados
no prazo estabelecido e dentro das estimativas
de custo.
5
 Engenharia de Software

abrange um conjunto de três elementos fundamentais: métodos: proporcionam os detalhes de

Métodos, Ferramentas e Procedimentos como fazer para construir o software

Principais metas: melhorar a qualidade de

produtos de software, aumentar a
produtividade do pessoal técnico e aumentar
a satisfação do cliente.

Engenharia de Software Engenharia de Software

ferramentas: dão suporte automatizado
F Planejamento e estimativa de projeto
aos métodos.
F Análise de requisitos de software e de sistemas
ð existem atualmente ferramentas para sustentar
F Projeto da estrutura de dados cada um dos métodos
F Algoritmo de processamento
ð quando as ferramentas são integradas é
F Codificação estabelecido um sistema de suporte ao
F Teste desenvolvimento de software chamado CASE -
F Manutenção Computer Aided Software Engineering

Engenharia de Software Engenharia de Software

procedimentos: constituem o elo de conjunto de etapas que envolve

ligação entre os métodos e ferramentas métodos
Ü seqüência em que os métodos serão aplicados ferramentas
Ü produtos que se exige que sejam entregues procedimentos
Ü controles que ajudam assegurar a qualidade e
coordenar as alterações Essas etapas são conhecidas como componentes de
Ü marcos de referência que possibilitam administrar CICLO DE VIDA DE SOFTWARE
o progresso do software. ou Processo de Software

6
 Engenharia de Software para escolha de um Ciclo de Vida de Software:

Alguns ciclos de vida mais conhecidos são:

Ä Ciclo de Vida Clássico
Ü natureza do projeto e da aplicação

Ä Prototipação
Ü métodos e ferramentas a serem usados
Ä Modelo Espiral
Ä Técnicas de 4a Geração
Ü controles e produtos que precisam ser
entregues

Ciclo de Vida Clássico (Cascata) Cascata

Ø modelo mais antigo e o mais amplamente Engenharia de
usado da engenharia de software Sistemas
Análise de
Requisitos
Projeto
Ø modelado em função do ciclo da engenharia Codificação
convencional
Testes
Manutenção
Ø requer uma abordagem sistemática,
seqüencial ao desenvolvimento de software

Atividades do Ciclo de Vida Clássico Atividades do Ciclo de Vida Clássico

ANÁLISE E ENGENHARIA DE ANÁLISE DE REQUISITOS DE
Engenharia de SISTEMAS SOFTWARE
Sistemas
Análise de w envolve a coleta de requisitos em Engenharia de
Requisitos Sistemas w processo de coleta dos requisitos
Projeto nível do sistema, pequena Análise de
é intensificado e concentrado
Requisitos
Codificação quantidade de projeto e análise Projeto especificamente no software
Testes
de alto nível Codificação
w deve-se compreender o domínio
Manutenção w visão essencial quando Testes da informação, a função,
o software deve fazer Manutenção desempenho e interfaces
interface com outros exigidos
elementos (hardware, w os requisitos (para o sistema e para
pessoas e banco de dados) o software) são documentados e
revistos com o cliente

7
 Atividades do Ciclo de Vida Clássico Atividades do Ciclo de Vida Clássico
PROJETO CODIFICAÇÃO
w tradução dos requisitos do software para w tradução das representações
um conjunto de representações que podem do projeto para uma
Engenharia de ser avaliadas quanto à qualidade, antes Engenharia de
Sistemas Sistemas linguagem “artificial”
Análise de que a codificação se inicie Análise de
Requisitos Requisitos
resultando em instruções
Projeto w se concentra em 4 atributos do Projeto
executáveis pelo computador
Codificação programa: Codificação
Testes Ø Estrutura de Dados, Testes
Manutenção Ø Arquitetura de Software,
Manutenção
Ø Detalhes Procedimentais e
Ø Caracterização de Interfaces

Atividades do Ciclo de Vida Clássico Atividades do Ciclo de Vida Clássico

TESTES MANUTENÇÃO
Concentram-se: Engenharia de w o software deverá sofrer mudanças
Engenharia de Sistemas
Sistemas w nos aspectos lógicos internos Análise de depois que for entregue ao cliente
Análise de Requisitos
Requisitos do software, garantindo que Projeto
Projeto
todas as instruções tenham Codificação w causas das mudanças:
Codificação
sido testadas Testes erros, adaptação do
Testes
w nos aspectos funcionais Manutenção software para acomodar
Manutenção mudanças em seu
externos, para descobrir
erros e garantir que a ambiente externo e
entrada definida produza exigência do cliente para
resultados que concordem acréscimos funcionais e de
com os esperados. desempenho

Problemas com o Ciclo de Vida Clássico Clássico (comentários)

M projetos reais raramente seguem o fluxo Embora o Ciclo de Vida Clássico tenha
seqüencial que o modelo propõe
fragilidades, ele é significativamente
M logo no início é difícil estabelecer explicitamente
todos os requisitos. No começo dos projetos melhor do que uma abordagem casual
sempre existe uma incerteza natural
ao desenvolvimento de software
Mo cliente deve ter paciência. Uma versão
executável do software só fica disponível numa
etapa avançada do desenvolvimento

8
 Prototipação Prototipação
Ä processo que possibilita que o desenvolvedor crie início
um modelo do software que deve ser construído. fim obtenção
dos
Ä idealmente, o modelo (protótipo) serve como um requisitos
mecanismo para identificar os requisitos de construção projeto
produto rápido
software.
Ä apropriado para quando o cliente definiu um refinamento
construção
protótipo
conjunto de objetivos gerais para o software, mas protótipo

não identificou requisitos de entrada, avaliação

protótipo
processamento e saída com detalhes.

Atividades da Prototipação Atividades da Prototipação

início Obtenção dos Requisitos: início
fim
obtenção
desenvolvedor e cliente definem os fim
obtenção
Construção Protótipo:
dos objetivos gerais do software, dos implementação do projeto
requisitos requisitos
construção projeto identificam quais requisitos são construção projeto
rápido
produto rápido produto rápido
conhecidos e as áreas que
construção necessitam de definições adicionais construção
refinamento refinamento
protótipo protótipo protótipo
protótipo
avaliação avaliação Avaliação do Protótipo:
protótipo protótipo
Projeto Rápido: representação dos cliente e desenvolvedor avaliam
aspectos do software que são o protótipo
visíveis ao usuário (abordagens de
entrada e formatos de saída)

Atividades da Prototipação Atividades da Prototipação

início Refinamento dos Requisitos: início
fim cliente e desenvolvedor refinam fim
obtenção
dos
obtenção
dos
Construção Produto:
os requisitos do software a ser
construção
requisitos
projeto construção
requisitos
projeto identificados os requisitos, o
produto rápido desenvolvido. produto rápido
protótipo deve ser descartado e a
Ocorre neste ponto um processo versão de produção deve ser
construção construção
refinamento
protótipo protótipo de iteração que pode conduzir a refinamento
protótipo construída considerando os
protótipo
avaliação 1a. atividade até que as avaliação
protótipo protótipo critérios de qualidade.
necessidades do cliente sejam
satisfeitas e o desenvolvedor
compreenda o que precisa ser
feito.

9
 Problemas com a Prototipação Problemas com a Prototipação

Mcliente não sabe que o software que ele vê não

Mdesenvolvedor freqüentemente faz uma
considerou, durante o desenvolvimento, a implementação comprometida (utilizando o que
qualidade global e a manutenibilidade a longo está disponível) com o objetivo de produzir
prazo. Não aceita bem a idéia que a versão final do rapidamente um protótipo. Depois de um tempo ele
software vai ser construída e "força" a utilização do
familiariza com essas escolhas, e esquece que elas não
protótipo como produto final.
são apropriadas para o produto final.

Prototipação (comentários) Ciclo de Vida em Espiral

Ainda que possam ocorrer problemas, a prototipação Ü engloba as melhores características do ciclo de vida
é um ciclo de vida eficiente ü Clássico e da Prototipação, adicionando um novo
elemento: a Análise de Risco
A chave é definir-se as regras do jogo logo no
Ü segue a abordagem de passos sistemáticos do Ciclo de
começo ü Vida Clássico incorporando-os numa estrutura iterativa que
O cliente e o desenvolvedor devem ambos concordar reflete mais realisticamente o mundo real
que o protótipo seja construído para servir como Ü usa a Prototipação, em qualquer etapa da evolução do
produto, como mecanismo de redução de riscos
um mecanismo a fim de definir os requisitos ü

Espiral Atividades do Ciclo de Vida em Espiral

Planejamento: determinação dos
planejamento objetivos, alternativas e restrições
análise dos
planejamento
riscos
Análise de Risco: análise das análise dos
riscos
decisão de continuar ou não alternativas e identificação / resolução
direção de um dos riscos
avaliação sistema
do cliente engenharia Construção: desenvolvimento do avaliação
concluído produto no nível seguinte
do
engenharia
cliente

Avaliação do Cliente: avaliação do

produto e planejamento das novas
fases

10
 Espiral (comentários) Espiral (comentários)

I é, atualmente, a abordagem mais realística para o

desenvolvimento de software em grande escala.
☞ o modelo é relativamente novo e não tem
I usa uma abordagem que capacita o desenvolvedor e o
cliente a entender e reagir aos riscos em cada etapa sido amplamente usado
evolutiva.
Demorará muitos anos até que a eficácia desse
I pode ser difícil convencer os clientes que uma abordagem
"evolutiva" é controlável
modelo possa ser determinada com certeza
I exige considerável experiência na determinação de riscos
absoluta.
e depende dessa experiência para ter sucesso

Técnicas de 4a Geração Técnicas de 4a Geração

Concentra-se na capacidade de se especificar o software
a uma máquina em um nível que esteja próximo à
linguagem natural. Obtenção dos
Requisitos
Estratégia do
“Projeto”
Engloba um conjunto de ferramentas de software Implementação
que possibilitam que: usando 4GL
Testes
ð o sistema seja especificado em uma
linguagem de alto nível e
ðo código fonte seja gerado automaticamente a
partir dessas especificações

Ferramentas do ambiente de
desenvolvimento de software de 4GL Atividades das Técnicas de 4a Geração
Obtenção dos
Requisitos
O ambiente de desenvolvimento de software que sustenta o ciclo Estratégia do
“Projeto”
de vida de 4a geração inclui as ferramentas: 1. obtenção dos Requisitos: Implementaçã
o usando 4GL
ü linguagens não procedimentais para consulta de o cliente descreve os requisitos Testes
banco de dados os quais são traduzidos para um
ü geração de relatórios protótipo operacional
ü manipulação de dados
ü interação e definição de telas Öo cliente pode estar inseguro quanto aos requisitos
ü geração de códigos Öo cliente pode ser incapaz de especificar as informações
ü capacidade gráfica de alto nível de um modo que uma ferramenta 4GL possa consumir
ü capacidade de planilhas eletrônicas Öas 4GLs atuais não são sofisticadas suficientemente para
acomodar a verdadeira "linguagem natural"

11
 Atividades das Técnicas de 4a Geração Atividades das Técnicas de 4a Geração
Obtenção dos Obtenção dos
Requisitos Requisitos
Estratégia do Estratégia do
2. estratégia de "Projeto": “Projeto”
Implementaçã
“Projeto”
Implementaçã
para pequenas aplicações é o usando 4GL 3. implementação usando o usando 4GL
Testes Testes
possível mover-se do passo de 4GL: os resultados desejados
Obtenção dos Requisitos para o são representados de modo que
passo de Implementação usando haja geração automática de
código . Deve existir uma
uma Linguagem de 4G
estrutura de dados com
Öpara grandes projetos é necessário desenvolver uma informações relevantes e que
estratégia de projeto. De outro modo ocorrerão os seja acessível pela 4GL
mesmos problemas encontrados quando se usa
abordagem convencional (baixa qualidade)

Atividades das Técnicas de 4a Geração Técnicas de 4a Geração (comentários)

Obtenção dos
Requisitos
Estratégia do
“Projeto”
4. teste: o desenvolvedor Implementaçã PROPONENTES: redução dramática no tempo de
o usando 4GL
deve efetuar testes e Testes desenvolvimento do software (aumento de
desenvolver uma produtividade)
documentação significativa.
OPONENTES: as 4GL atuais não são mais fáceis de
O software desenvolvido
deve ser construído de usar do que as linguagens de programação
maneira que a manutenção M o código fonte produzido é ineficiente
possa ser efetuada M a manutenibilidade de sistemas usando técnicas 4G
prontamente. ainda é questionável

Combinação dos Métodos de Ciclo de Vida

Mudança na natureza de desenvolvimento de
obtenção dos requisitos
software preliminares

análise dos protomodelagem técnicas modelo espiral

requisitos 4G

demanda
global projeto protomodelagem técnicas
no. interação 4G
demanda aplicação de
por técnicas de 4a codificação
software Geração modelo espiral
no. interação
métodos protomodelagem
convencionais no. interação

testes
1970 1980 1990 2000
sistema completo

manutenção

12
Engenharia de Software uma visão genérica Engenharia de Software uma visão genérica

O processo de desenvolvimento de software Construção Operação

contém 3 fases genéricas, independentes do Definição
“o que” Desenvolvimento Manutenção
modelo de engenharia de software escolhido: 1. Análise de “como”
SOFTWARE
“mudanças”
Sistema 1. Projeto de ð ð
PRODUTO 1. Entender
2. Planejamento ð Software
1. DEFINIÇÃO, do Projeto 2. Codificação
2. Modificar
3. Análise de 3. Revalidar
3. Teste
Requisitos
2. DESENVOLVIMENTO e
Atividades de Apoio
õ 1. Revisões
ö
3. MANUTENÇÃO. 2. Documentação
3. Controle de
Mudanças

Engenharia de Software uma visão genérica Engenharia de Software uma visão genérica
DEFINIÇÃO : “o que” será desenvolvido.
Ø Análise de Requisitos: o escopo definido para o
Ø Análise do Sistema: define o papel de cada
elemento num sistema baseado em computador, software proporciona uma direção, mas uma
atribuindo em última análise, o papel que o definição detalhada do domínio da informação e da
software desempenhará. função do software é necessária antes que o
trabalho inicie.
Ø Planejamento do Projeto de Software: assim que
o escopo do software é estabelecido, os riscos são
analisados, os recursos são alocados, os custos
são estimados e, tarefas e programação de
trabalho definidas.

Engenharia de Software uma visão genérica
DESENVOLVIMENTO: “como” o software vai ser
desenvolvido.
ð Projeto de Software: traduz os requisitos do
software num conjunto de representações (algumas
gráficas, outras tabulares ou baseadas em
linguagem) que descrevem a estrutura de dados, a
arquitetura do software, os procedimentos
algorítmicos e as características de interface.
Engenharia de Software uma visão genérica
ðCodificação: as representações do projeto devem
ser convertidas numa linguagem artificial (a linguagem
pode ser uma linguagem de programação
convencional ou uma linguagem não procedimental)
que resulte em instruções que possam ser executadas
pelo computador.
ðRealização de Testes do Software: logo que o
software é implementado numa forma executável por
máquina, ele deve ser testado para que se possa
descobrir defeitos de função, lógica e implementação.

13
Engenharia de Software uma visão genérica
MANUTENÇÃO: concentra-se nas
“mudanças” que ocorrerão depois que o
software for liberado para uso operacional
Ü Correção
Ü Adaptação
Ü Melhoramento Funcional
Engenharia de Software uma visão genérica
Melhoramento Funcional: a medida que o
software é usado, o cliente/usuário reconhecerá
funções adicionais que oferecerão benefícios.
A manutenção perfectiva estende o software
para além de suas exigências funcionais
originais.
Engenharia de Software uma aborgagem
gerencial
A Engenharia de Software também se preocupa com
questões gerenciais, que encontra-se do lado oposto
ao domínio da programação
Gerenciamento: necessário para coordenar as
atividades técnicas em projetos de produtos de
software.
Engenharia de Software uma visão genérica
Correção: mesmo com as melhores atividades de
garantia de qualidade de software, é provável que o
cliente descubra defeitos no software. A manutenção
corretiva muda o software para corrigir defeitos.
Adaptação: com o passar do tempo, o ambiente
original (por exemplo a CPU, o sistema operacional e
periféricos) para o qual o software foi desenvolvido
provavelmente mudará. A manutenção adaptativa
muda o software para acomodar mudanças em seu
ambiente.
Engenharia de Software uma visão genérica
Atividades de Proteção: as fases e etapas correlatas
descritas são complementadas por uma série de
atividades de proteção.
Revisões: efetuadas para garantir que a qualidade seja
mantida à medida que cada etapa é concluída.
Documentação: é desenvolvida e controlada para garantir
que informações completas sobre o software estejam
disponíveis para uso posterior.
Controle das Mudanças: é instituído de forma que as
mudanças possam ser aprovadas e acompanhadas.
Engenharia de Software uma aborgagem
gerencial
Em geral, um produto de software inclui:
-> Código fonte, e documentação relacionada:
l documento de requisitos
l especificação do projeto
l planos de teste
l princípios de operação
l procedimentos para garantia da qualidade
14
Engenharia de Software uma aborgagem Engenharia de Software uma aborgagem
gerencial gerencial

Em geral, um produto de software inclui: Qualidade de software : preocupação principal dos

-> Cogido fonte, e documentação relacionada: gerentes de software.
l relatórios de problemas com o software -> Principal atributo de qualidade: utilidade
l procedimentos de manutenção -> outros atributos de qualidade:
l manuais do usuário - transportabilidade
l instruções para instalação
- eficiência
l auxílio para treinamento - clareza
- confiabilidade

Engenharia de Software uma aborgagem Engenharia de Software uma aborgagem

gerencial gerencial

Fatore de Qualidade e Produtividade : Fatore de Qualidade e Produtividade :

Fatores que influenciam a qualidade: Fatores que influenciam a qualidade:
ð Habilidade Individual ð Adequação de treinamento
ð Comunicação da equipe ð Habilidades de gerenciamento
ð Complexidade do produto ð Metas apropriadas
ð Notações apropriadas ð Entendimento do problema
ð Abordagens sistemáticas ð Estabilidade dos requisitos
ð controle de mudanças ð Habilidades necessárias

Engenharia de Software uma aborgagem Engenharia de Software uma aborgagem

gerencial gerencial

Questões gerenciais Preocupações de gerenciamento de projeto:

Os gerentes de software: ð métodos para organizar e monitorar um projeto.
ð controlam os recursos e o ambiente no qual as atividades ð técnicas de estimativa de custo.
técnicas ocorrem. ð política de alocação de recursos.
ð responsáveis pela entrega do produto no prazo e dentro das ð controle orçamentário.
estimativas de custo.
ð avaliação do progresso.
ð devem garantir que o produto tenha os atributos funcionais e
de qualidade desejados pelo cliente. ð realocação de recursos.

ð Treinam empregados. ð ajustes no cronograma.

ð desenvolvem planos e estratégias de marketing.

15
Engenharia de Software uma aborgagem Engenharia de Software uma aborgagem
gerencial gerencial

Preocupações de gerenciamento de projeto: Problemas na área de gerenciamento:

ð estabelecer procedimentos para garantia de qualidade. ð falta de planejamento para projetos de software.
ð manter o controle de várias versões do produto. ð falta de técnicas e procedimentos para selecionar gerentes de
ð facilitar a comunicação entre os membros do projeto. projeto.

ð comunicação com o cliente. ð falta de habilidade em estimar os recursos necessários para o

ð estabelecer contratos com o cliente.
ð garantir que os termos legais e contratuais do projeto sejam
cumpridos.
projeto.
ð falta de um processo de desenvolvimento bem estabelecido.
ð falta de estratégias para o gerente acompanhar o progresso
do projeto.
ð falta de padrões e técnicas para medir produtividade.

Engenharia de Software uma aborgagem

gerencial
Fatores que melhoram o gerenciamento: Conclusão
ð treinar gerentes, e desenvolvedores de software. ENGENHARIA DE SOFTWARE
ð estabelecer o uso de padrões, procedimentos e pode ser vista como uma abordagem de desenvolvimento de
documentação.
software elaborada com disciplina e métodos bem definidos.
ð analisar dados de projetos passados para avaliar métodos
efetivos.
ð definir objetivos em termos de qualidade desejada.
ð definir qualidade em termos de produtos a ser entregues.
ð Selecionar gerentes de projetos com habilidades para .....“a construção por múltiplas
gerenciamento. pessoas de um software de
ð Desenvolver uma maneira de avaliar os desenvolvedores de múltiplas versões” [Parnas 1987]
software.

Pontos a ponderar Pontos a ponderar

l O software é o fator de diferenciação de muitos produtos e sistemas l Os mitos de software citados em aula são somente alguns entre muitos
baseados em computador. Apresente exemplos de dois ou três produtos e outros. Liste mitos adicionais para cada uma das categorias apresentadas.
de pelo menos um sistema em que o software, não o hardware, é o elemento
l Existe algum caso em que as fases genéricas do processo de engenharia de
que faz a diferença.
software não se aplicam? Se assim for, descreva-o.
l Nas décadas de 1950 e 1960, a programação de computador era uma forma
de arte aprendida num ambiente semelhante ao de aprendizes. Como os
primórdios afetaram as práticas de desenvolvimento de software atuais?
l Apresente cinco exemplos de desenvolvimento de software que seriam
adequados à prototipação. Cite duas ou três aplicações que seriam mais
difíceis de ser representadas em protótipos.
, ,

16