Upload
internet
View
112
Download
4
Embed Size (px)
Citation preview
Engenharia de Software
Tópicos
1- Introdução à Engenharia de Software
2 - Fundamentos Organizacionais de Sistemas de Informação3- Gerência de projeto de software4- Gerenciamento para a qualidade de software5-Acompanhamento do processo de desenvolvimento de software.
Software
1- Instruções
quando executadas produzem a função e o desempenho desejados
2 - Estruturas de Dadospossibilitam que os programas manipulem adequadamente a informação
3 - Documentos
descrevem a operação e o uso dos programas
Características do Software
1. desenvolvido ou projetado por engenharia, não manufaturado no sentido clássico
2. não se desgasta mas se deteriora
3. a maioria é feita sob medida em vez de ser montada a partir de componentes existentes
Curva de falhas para o Hardware
tempo
“desgaste”“mortalidade infantil”
índice de
falhas
Curva de falhas do Software
índice de falhas
mudançamudança
curva realcurva real
curva idealizada
tempo
Aplicações do Software
BBÁÁSSIICCOO programas de apoio a outros programas
DDEE TTEEMMPPOO RREEAALL monitora, analisa e controla eventos domundo real
CCOOMMEERRCCIIAALL operações comerciais e tomadas dedecisões administrativas
CCIIEENNTTÍÍFFIICCOO EE DDEEEENNGGEENNHHAARRIIAA
algoritmos de processamento de números
EEMMBBUUTTIIDDOO controla produtos e sistemas de mercadosindustriais e de consumo
DDEE CCOOMMPPUUTTAADDOORRPPEESSSSOOAALL
processamento de textos, planilhaseletrônicas, diversões, etc.
DDEE IINNTTEELLIIGGÊÊNNCCIIAAAARRTTIIFFIICCIIAALL
algoritmos não numéricos para resolverproblemas que não sejam favoráveis àcomputação ou à análise direta
Evolução do Software
(1950 - 1965) O hardware sofreu contínuas mudanças O software era uma arte "secundária" para a
qual havia poucos métodos sistemáticos O hardware era de propósito geral O software era específico para cada aplicação Não havia documentação
(1965 - 1975) Multiprogramação e sistemas multiusuários Técnicas interativas Sistemas de tempo real 1a geração de SGBD’s Produto de software - software houses Bibliotecas de Software Cresce no de sistemas baseado em computador Manutenção quase impossível
..... CRISE DE SOFTWARE
Evolução do Software
(1975 - hoje) Sistemas distribuídos Redes locais e globais Uso generalizado de microprocessadores -
produtos inteligentes Hardware de baixo custo Impacto de consumo
..... CRISE DE SOFTWARE (aflição crônica???)
Evolução do Software
(Quarta era do software: atualidade)
Tecnologias orientadas o objetos
Sistemas especialistas e software de inteligência artificial usados na prática
Software de rede neural artificial
Computação Paralela
Internet
..... CRISE DE SOFTWARE (aflição crônica???)
Evolução do Software
Crise de Software
Refere-se a um conjunto de problemas encontrados no desenvolvimento de software:
(1) As estimativas de prazo e de custo freqüentemente são imprecisas
“Não dedicamos tempo para coletar dados sobre o processo de desenvolvimento de software”
“Sem nenhuma indicação sólida de produtividade, não podemos avaliar com precisão a eficácia de novas ferramentas, métodos ou padrões”
(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
(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 manterA tarefa de manutenção devora o orçamento destinado ao softwareA facilidade de manutenção não foi enfatizada como um critério importante
Crise de Software
estimativas de prazo e de custo
produtividade das pessoas
qualidade de software
software difícil de manter
Crise de Software
Causas dos problemas associados à Crise de Software
1. próprio caráter do SoftwareO 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!!!
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.
Causas dos problemas associados à Crise de Software
3. mitos do Software
propagaram desinformação e confusãoadministrativosclienteprofissional
Causas dos problemas associados à Crise de Software
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?
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.
Realidade: É preciso muito mais do que os mais recentes computadores para se fazer um desenvolvimento de software de alta qualidade.
Mitos do Software (administrativos)
Se nós estamos atrasados nos prazos, podemos adicionar mais programadores e tirar o atraso.
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: 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.
Mitos do Software (administrativos)
Uma declaração geral dos objetivos é suficiente para se começar a escrever programas - podemos preencher os detalhes mais tarde.
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.
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 (clientes)
Os requisitos de projeto modificam-se continuamente, mas as mudanças podem ser facilmente acomodadas, porque o software é flexível.
Realidade:
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.
Realidade:
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.
Mitos do Software (clientes)
magnitude das mudanças
FASES CUSTO DE MANUTENÇÃO
DEFINIÇÃO 1 xDESENVOLVIMENTO 1.5 - 6xMANUTENÇÃO 60 - 100x
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.
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.
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.
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.
Mitos do Software (profissional)
Preocupação: Sistematizar o processo de criação e manutenção de software.
Engenharia de Software
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 SoftwareDefinições
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.
Engenharia de SoftwareDefinições
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.
Engenharia de SoftwareDefinições
abrange um conjunto de três elementos fundamentais:
Métodos, Ferramentas e Procedimentos
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
métodos: proporcionam os detalhes de como fazer para construir o software.
Engenharia de Software
Planejamento e estimativa de projeto Análise de requisitos de software e de sistemas Projeto da estrutura de dados Algoritmo de processamento Codificação Teste Manutenção
Engenharia de Software
ferramentas: dão suporte automatizado aos métodos.
existem atualmente ferramentas para sustentar cada um dos métodos
quando as ferramentas são integradas é estabelecido um sistema de suporte ao desenvolvimento de software chamado CASE - Computer Aided Software Engineering
Engenharia de Software
procedimentos: constituem o elo de
ligação entre os métodos e ferramentas seqüência em que os métodos serão aplicados produtos que se exige que sejam entregues controles que ajudam assegurar a qualidade e
coordenar as alterações marcos de referência que possibilitam
administrar o progresso do software.
Engenharia de Software
conjunto de etapas que envolvemétodos
ferramentas procedimentos
Essas etapas são conhecidas como componentes de CICLO DE VIDA DE SOFTWARE
ou Processo de Software
Engenharia de Software
Alguns ciclos de vida mais conhecidos são:
Ciclo de Vida Clássico
Prototipação
Modelo Espiral
Técnicas de 4a Geração
Engenharia de Software
Para escolha de um Ciclo de Vida de Software:
natureza do projeto e da aplicação
métodos e ferramentas a serem usados
controles e produtos que precisam ser entregues
Ciclo de Vida Clássico (Cascata)
modelo mais antigo e o mais amplamente usado da engenharia de software
modelado em função do ciclo da engenharia convencional
requer uma abordagem sistemática, seqüencial ao desenvolvimento de software
Engenharia de Sistemas
Engenharia de Sistemas
Análise de Requisitos
Análise de Requisitos
Projeto Projeto
Codificação Codificação
Testes Testes
Manutenção Manutenção
Cascata
Atividades do Ciclo de Vida Clássico
ANÁLISE E ENGENHARIA DE SISTEMAS
envolve a coleta de requisitos em nível do sistema, pequena
quantidade de projeto e análise de alto nível
Engenharia de Sistemas
Análise de Requisitos
Projeto
Codificação
Testes
Manutenção visão essencial quando o software deve fazer
interface com outros elementos (hardware,
pessoas e banco de dados)
ANÁLISE DE REQUISITOS DE SOFTWARE
processo de coleta dos requisitos é intensificado e concentrado especificamente no software
deve-se compreender o domínio da informação, a função, desempenho e interfaces
exigidos
os requisitos (para o sistema e para o software) são documentados e
revistos com o cliente
Engenharia de Sistemas
Análise de Requisitos
Projeto
Codificação
Testes
Manutenção
Atividades do Ciclo de Vida Clássico
PROJETO
tradução dos requisitos do software para um conjunto de representações que podem ser
avaliadas quanto à qualidade, antes que a codificação se inicie
se concentra em 4 atributos do programa: Estrutura de Dados,
Arquitetura de Software,
Detalhes Procedimentais e
Caracterização de Interfaces
Engenharia de Sistemas Análise de
Requisitos Projeto
Codificação
Testes
Manutenção
Atividades do Ciclo de Vida Clássico
CODIFICAÇÃO
tradução das representações do projeto para uma linguagem “artificial”
resultando em instruções executáveis pelo computador
Engenharia de Sistemas
Análise de Requisitos
Projeto
Codificação
Testes
Manutenção
Atividades do Ciclo de Vida Clássico
TESTESConcentram-se:
nos aspectos lógicos internos do software, garantindo que todas as instruções tenham
sido testadas nos aspectos funcionais
externos, para descobrir erros e garantir que a entrada
definida produza resultados que concordem com os
esperados.
Engenharia de SistemasAnálise de
Requisitos Projeto
Codificação
Testes
Manutenção
Atividades do Ciclo de Vida Clássico
MANUTENÇÃO
o software deverá sofrer mudanças depois que for entregue ao cliente
Engenharia de Sistemas
Análise de Requisitos
Projeto
Codificação
Testes
Manutenção
causas das mudanças: erros, adaptação do
software para acomodar mudanças em seu
ambiente externo e exigência do cliente para
acréscimos funcionais e de desempenho
Atividades do Ciclo de Vida Clássico
Problemas com o Ciclo de Vida Clássico
projetos reais raramente seguem o fluxo seqüencial que o modelo propõe
logo no início é difícil estabelecer explicitamente todos os requisitos. No começo dos projetos sempre existe uma incerteza natural
o cliente deve ter paciência. Uma versão executável do software só fica disponível numa etapa avançada do desenvolvimento
Clássico (comentários)
Embora o Ciclo de Vida Clássico tenha
fragilidades, ele é significativamente
melhor do que uma abordagem casual ao
desenvolvimento de software
Prototipação
processo que possibilita que o desenvolvedor crie um modelo do software que deve ser construído.
idealmente, o modelo (protótipo) serve como um mecanismo para identificar os requisitos de software.
apropriado para quando o cliente definiu um conjunto de objetivos gerais para o software, mas não identificou requisitos de entrada, processamento e saída com detalhes.
fim
início
construção produto
refinamento protótipo
avaliação protótipo
construção protótipo
projeto rápido
obtenção dos
requisitos
Prototipação
Atividades da Prototipação
Obtenção dos Requisitos: desenvolvedor e cliente definem os
objetivos gerais do software, identificam quais requisitos são
conhecidos e as áreas que necessitam de definições adicionais
Projeto Rápido: representação dos aspectos do software que são
visíveis ao usuário (abordagens de entrada e formatos de saída)
fim
início
construção produto
refinamento protótipo
avaliação protótipo
construção protótipo
projeto rápido
obtenção dos
requisitos
Construção Protótipo: implementação do projeto rápido
Avaliação do Protótipo: cliente e
desenvolvedor avaliam o protótipo
fim
início
construção produto
refinamento protótipo
avaliação protótipo
construção protótipo
projeto rápido
obtenção dos
requisitos
Atividades da Prototipação
Refinamento dos Requisitos: cliente e desenvolvedor refinam os
requisitos do software a ser desenvolvido.
Ocorre neste ponto um processo de iteração que pode conduzir a 1a.
atividade até que as necessidades do cliente sejam satisfeitas e o
desenvolvedor compreenda o que precisa ser feito.
fim
início
construção produto
refinamento protótipo
avaliação protótipo
construção protótipo
projeto rápido
obtenção dos
requisitos
Atividades da Prototipação
Construção Produto: identificados os requisitos, o protótipo deve ser
descartado e a versão de produção deve ser construída considerando os
critérios de qualidade.
fim
início
construção produto
refinamento protótipo
avaliação protótipo
construção protótipo
projeto rápido
obtenção dos
requisitos
Atividades da Prototipação
Problemas com a Prototipação
cliente não sabe que o software que ele vê não considerou, durante o desenvolvimento, a qualidade global e a manutenibilidade a longo prazo. Não aceita bem a idéia que a versão final do software vai ser construída e "força" a utilização do protótipo como produto final.
desenvolvedor freqüentemente faz uma implementação comprometida (utilizando o que está disponível) com o objetivo de produzir rapidamente um protótipo. Depois de um tempo ele familiariza com essas escolhas, e esquece que elas não são apropriadas para o produto final.
Problemas com a Prototipação
Prototipação (comentários)
Ainda que possam ocorrer problemas, a prototipação é um ciclo de vida eficiente
A chave é definir-se as regras do jogo logo no começo
O cliente e o desenvolvedor devem ambos concordar que o protótipo seja construído para servir como um mecanismo a fim de definir os requisitos
Ciclo de Vida em Espiral
engloba as melhores características do ciclo de vida Clássico e da Prototipação, adicionando um novo elemento: a Análise de Risco
segue a abordagem de passos sistemáticos do Ciclo de Vida Clássico incorporando-os numa estrutura iterativa que reflete mais realisticamente o mundo real usa a Prototipação, em qualquer etapa da evolução do produto, como mecanismo de redução de riscos
decisão de continuar ou não
direção de um sistema
concluído
avaliação do cliente engenharia
análise dos riscos
planejamento
Espiral
Atividades do Ciclo de Vida em Espiral
Planejamento: determinação dos objetivos, alternativas e restrições
Análise de Risco: análise das alternativas e identificação / resolução dos riscos
Construção: desenvolvimento do produto no nível seguinte
Avaliação do Cliente: avaliação do produto e planejamento das novas fases
avaliação do
clienteengenharia
análise dos riscos
planejamento
é, atualmente, a abordagem mais realística para o desenvolvimento de software em grande escala.
usa uma abordagem que capacita o desenvolvedor e o cliente a entender e reagir aos riscos em cada etapa evolutiva.
pode ser difícil convencer os clientes que uma abordagem "evolutiva" é controlável
exige considerável experiência na determinação de riscos e depende dessa experiência para ter sucesso
Espiral (comentários)
o modelo é relativamente novo e não tem sido amplamente usado
Demorará muitos anos até que a eficácia desse modelo possa ser determinada com certeza absoluta.
Espiral (comentários)
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.
Engloba um conjunto de ferramentas de software que possibilitam que:
o sistema seja especificado em uma linguagem de alto nível e
o código fonte seja gerado automaticamente a partir dessas especificações
Obtenção dos Requisitos
Obtenção dos Requisitos
Estratégia do “Projeto”
Estratégia do “Projeto”
Implementação usando 4GL
Implementação usando 4GL
Testes Testes
Técnicas de 4a Geração
Ferramentas do ambiente de desenvolvimento de software de 4GL
O ambiente de desenvolvimento de software que sustenta o ciclo de vida de 4a geração inclui as ferramentas: linguagens não procedimentais para consulta
de banco de dados geração de relatórios manipulação de dados interação e definição de telas geração de códigos capacidade gráfica de alto nível capacidade de planilhas eletrônicas
Atividades das Técnicas de 4a Geração
1. obtenção dos Requisitos: o cliente descreve os requisitos os quais são traduzidos para um protótipo operacional
Obtenção dos Requisitos
Estratégia do “Projeto”
Implementação usando 4GL
Testes
o cliente pode estar inseguro quanto aos requisitos
o cliente pode ser incapaz de especificar as informações de um modo que uma ferramenta 4GL possa consumir
as 4GLs atuais não são sofisticadas suficientemente para acomodar a verdadeira "linguagem natural"
2. estratégia de "Projeto": para pequenas aplicações é possível mover-se do passo de Obtenção dos Requisitos para o passo de Implementação usando uma Linguagem de 4G
Obtenção dos Requisitos
Estratégia do “Projeto”
Implementação usando 4GL
Testes
para grandes projetos é necessário desenvolver uma estratégia de projeto. De outro modo ocorrerão os mesmos problemas encontrados quando se usa abordagem convencional (baixa qualidade)
Atividades das Técnicas de 4a Geração
3. implementação usando 4GL: os resultados desejados são representados de modo que haja geração automática de código . Deve existir uma estrutura de dados com informações relevantes e que seja acessível pela 4GL
Obtenção dos Requisitos
Estratégia do “Projeto”
Implementação usando 4GL
Testes
Atividades das Técnicas de 4a Geração
Obtenção dos Requisitos
Estratégia do “Projeto”
Implementação usando 4GL
Testes
4. teste: o desenvolvedor deve efetuar testes e desenvolver uma documentação significativa. O software desenvolvido deve ser construído de maneira que a manutenção possa ser efetuada prontamente.
Atividades das Técnicas de 4a Geração
PROPONENTES: redução dramática no tempo de desenvolvimento do software (aumento de produtividade)OPONENTES: as 4GL atuais não são mais fáceis de usar do que as linguagens de programação
o código fonte produzido é ineficiente a manutenibilidade de sistemas usando técnicas 4G
ainda é questionável
Técnicas de 4a Geração (comentários)
Mudança na natureza de desenvolvimento de software
métodos convencionais
aplicação de técnicas de 4a
Geração
demanda demanda globalglobal
demanda por
software
1970 1980 1990 2000
Combinação dos Métodos de Ciclo de Vidaobtenção dos requisitos
preliminares
modelo espiraltécnicas 4G
protomodelagemanálise dos requisitos
projeto
codificação
testes
manutenção
protomodelagemno. interação
protomodelagemno. interação
técnicas 4G
modelo espiralno. interação
sistema completo
Engenharia de Software uma visão genérica
O processo de desenvolvimento de software contém 3 fases genéricas, independentes do modelo de engenharia de software escolhido:
1. DEFINIÇÃO,
2. DESENVOLVIMENTO e
3. MANUTENÇÃO.
1. Revisões2. Documentação3. Controle de
Mudanças
CCCooonnnssstttrrruuuçççãããooo
1. Entender2. Modificar3. Revalidar
Manutenção “mudanças”
OOOpppeeerrraaaçççãããooo
SSSOOOFFFTTTWWWAAARRREEE
PPPRRROOODDDUUUTTTOOO
AAAtttiiivvviiidddaaadddeeesss dddeee AAApppoooiiiooo
1. Análise deSistema
2. Planejamentodo Projeto
3. Análise deRequisitos
Definição“o que” Desenvolvimento
“como”
1. Projeto deSoftware
2. Codificação3. Teste
Engenharia de Software uma visão genérica
DEFINIÇÃO : “o que” será desenvolvido. Análise do Sistema: define o papel de cada elemento
num sistema baseado em computador, atribuindo em última análise, o papel que o software desempenhará.
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
Análise de Requisitos: o escopo definido para o software proporciona uma direção, mas uma definição detalhada do domínio da informação e da função do software é necessária antes que o trabalho inicie.
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.
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
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
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 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.
Engenharia de Software uma visão genérica
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 visão genérica
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 abordagem gerencial
Em geral, um produto de software inclui:
-> Código fonte, e documentação relacionada:
• documento de requisitos
• especificação do projeto
• planos de teste
• princípios de operação
• procedimentos para garantia da qualidade
Engenharia de Software uma abordagem gerencial
Em geral, um produto de software inclui:
-> Cogido fonte, e documentação relacionada:
• relatórios de problemas com o software
• procedimentos de manutenção
• manuais do usuário
• instruções para instalação
• auxílio para treinamento
Engenharia de Software uma abordagem gerencial
Qualidade de software : preocupação principal dos
gerentes de software.
-> Principal atributo de qualidade: utilidade
-> outros atributos de qualidade:
- transportabilidade
- eficiência
- clareza
- confiabilidade
Engenharia de Software uma abordagem gerencial
Fatores de Qualidade e Produtividade :
Fatores que influenciam a qualidade:
Habilidade Individual
Comunicação da equipe
Complexidade do produto
Notações apropriadas
Abordagens sistemáticas
controle de mudanças
Engenharia de Software uma abordagem gerencial
Fatores de Qualidade e Produtividade :
Fatores que influenciam a qualidade:
Adequação de treinamento
Habilidades de gerenciamento
Metas apropriadas
Entendimento do problema
Estabilidade dos requisitos
Habilidades necessárias
Engenharia de Software uma abordagem gerencial
Questões gerenciais
Os gerentes de software:
controlam os recursos e o ambiente no qual as atividades técnicas ocorrem.
responsáveis pela entrega do produto no prazo e dentro das estimativas de custo.
Engenharia de Software uma abordagem gerencial
Questões gerenciais
Os gerentes de software:
devem garantir que o produto tenha os atributos funcionais e de qualidade desejados pelo cliente.
Treinam empregados.
desenvolvem planos e estratégias de marketing.
Engenharia de Software uma abordagem gerencial
Preocupações de gerenciamento de projeto:
métodos para organizar e monitorar um projeto.
técnicas de estimativa de custo.
política de alocação de recursos.
controle orçamentário.
avaliação do progresso.
realocação de recursos.
ajustes no cronograma.
Engenharia de Software uma abordagem gerencial
Preocupações de gerenciamento de projeto:
estabelecer procedimentos para garantia de qualidade.
manter o controle de várias versões do produto.
facilitar a comunicação entre os membros do projeto.
comunicação com o cliente.
estabelecer contratos com o cliente.
garantir que os termos legais e contratuais do projeto sejam cumpridos.
Engenharia de Software uma abordagem gerencial
Problemas na área de gerenciamento:
falta de planejamento para projetos de software.
falta de técnicas e procedimentos para selecionar gerentes de projeto.
falta de habilidade em estimar os recursos necessários para o projeto.
Engenharia de Software uma abordagem gerencial
Problemas na área de gerenciamento:
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 abordagem gerencial
Fatores que melhoram o gerenciamento: treinar gerentes, e desenvolvedores de
software.
estabelecer o uso de padrões, procedimentos e documentação.
analisar dados de projetos passados para avaliar métodos efetivos.
Engenharia de Software uma abordagem gerencial
definir objetivos em termos de qualidade desejada.
definir qualidade em termos de produtos a ser entregues.
Selecionar gerentes de projetos com habilidades para gerenciamento.
Desenvolver uma maneira de avaliar os desenvolvedores de software.
Engenharia de Software uma abordagem gerencial
Conclusão
ENGENHARIA DE SOFTWAREpode ser vista como uma abordagem de
desenvolvimento de software elaborada com disciplina e métodos bem definidos.
.....“a construção por múltiplas pessoas de um software de múltiplas versões” [Parnas 1987]
Pontos a ponderar
• O software é o fator de diferenciação de muitos produtos e sistemas baseados em computador. Apresente exemplos de dois ou três produtos e de pelo menos um sistema em que o software, não o hardware, é o elemento que faz a diferença.
• 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?
,
Pontos a ponderar
• 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.
,
• Os mitos de software citados em aula são somente alguns entre muitos outros. Liste mitos adicionais para cada uma das categorias apresentadas.
• Existe algum caso em que as fases genéricas do processo de engenharia de software não se aplicam? Se assim for, descreva-o.
Pontos a ponderar
• ANTUNES, Paulo Bessa. Direito Ambiental. 2ed. Amplamente Reformulado. 14ª ed., Rio de Janeiro: Atlas, 2012.• Amaral, Diogo Freitas, Ciência Política, vol I ,Coimbra,1990 • AQUINO, Rubim Santos Leão de . et al. História das Sociedades Americanas. 7 ed. Rio de Janeiro: Record, 2000.• ARANHA, Maria Lúcia. Filosofando: Introdução á Filosofia. São Paulo: Moderna, 1993.• ARRUDA, José Jobson de A. e PILETTI, Nelson. Toda a História. 4 ed. São Paulo: Ática, 1996.
ASCENSÃO, José de Oliveira. Breves Observações ao Projeto de Substitutivo da Lei de Direitos Autorais. Direito da Internet e da Sociedade da Informação. Rio de Janeiro: Ed. Forense, 2002.
• BRANCO JR., Sérgio Vieira. Direitos Autorais na Internet e o Uso de Obras Alheias. Ed. Lúmen Júris, 2007.• BUZZI, Arcângelo. Introdução ao Pensar. Petrópolis; ed. Vozes, 1997.
CAPEZ, Fernando. Curso de Direito Penal. V. 2, Parte Especial. 10. Ed. São Paulo: Saraiva, 2010.• CERQUEIRA, João da Gama. “Tratado da Propriedade Industrial”, vol. II, parte II. Revista Forense: Rio de Janeiro,
1952.• CHAUÍ, Marilena. Convite á Filosofia. São Paulo,10ª. Ed.,Ática,1998.• COTRIM, Gilberto. História Global: Brasil e Geral. 6 ed. São Paulo: Saraiva, 2002.• CRETELLA JÚNIOR, José. Curso de Direito Administrativo. Rio de Janeiro: Forense, 2003.• DEON SETTE, MARLI T. Direito ambiental. Coordenadores: Marcelo Magalhães Peixoto e Sérgio Augusto Zampol• DINIZ, Maria Helena. Curso de direito civil brasileiro: teoria das obrigações contratuais e extracontratuais. 3. ed.
São Paulo: Saraiva, 1998, v. 3.• DI PIETRO, Maria Sylvia Zanella. Direito Administrativo. São Paulo: Atlas, 2005.• COELHO, Fábio Ulhoa. Curso de direito comercial. 6. ed. São Paulo: Saraiva, 2002, v. 1, 2 e 3.
REFERÊNCIAS
• FERRAZ JUNIOR, Tercio Sampaio. Introdução ao Estudo do Direito: técnica, decisão, dominação. 6.ed. São Paulo: Atlas, 2008.
• FIORILLO, Celso Antonio Pacheco. Curso de Direito Ambiental Brasileiro. 13ª ed., rev., atual. E compl. – São Paulo :Saraiva, 2012.
• FRAGOSO, Heleno Cláudio. Lições de direito penal: especial. 11. ed. atual. por Fernando Fragoso. Rio de Janeiro : Forense, 2005.
• GONÇALVES, Carlos Roberto. Direito Civil Brasileiro, vol I: Parte Geral. São Paulo: Saraiva, 2007• GAGLIANO, Plablo Stolze & PAMPLONA FILHO, Rodolfo. Novo curso de direito civil, v. 1 - 5 ed. São Paulo: Saraiva. 2004.• GRINOVER, Ada Pellegrini et al. Código Brasileiro de Defesa do Consumidor comentado pelos autores do anteprojeto. 8.
ed. rev., ampl. e atual. Rio de Janeiro: FU, 2004.• JESUS, Damásio E. de. Direito Penal – V. 2 – Parte Especial dos Crimes Contra a Pessoa a dos Crimes Contra o
Patrimônio. 30 ed. São Paulo: Saraiva, 2010.• LAKATOS, Eva Maria. Introdução à Sociologia. São Paulo: Atlas, 1997• LAKATOS, E. M. & MARCONI, M. A. Sociologia Geral. São Paulo: Atlas, 1999• MARQUES, Claudia Lima. Contratos no Código de Defesa do Consumidor: o novo regime das relações contratuais.4. ed.
rev., atual. e ampl. São Paulo: RT, 2004.• MARTINS FILHO, Ives Gandra da Silva. Manual de direito e processo do trabalho. 18.ed. São Paulo: Saraiva, 2009.• MARTINS, Sérgio Pinto.Direito do Trabalho. 25.ed. São Paulo: Atlas, 2009.• MARTINS, Carlos Benedito. O que é Sociologia. Rio de Janeiro: Zahar, 1988• MEDAUAR, Odete. Direito Administrativo Moderno. São Paulo: RT, 2001.• MEIRELLES, Hely Lopes. Direito Administrativo Brasileiro. São Paulo: Malheiros, 1996.• MIRABETE, Julio Fabbrini. Processo penal. 18. ed. – São Paulo: Editora Atlas, 2006.
REFERÊNCIAS
• MORAES, de Alexandre. Direito Constitucional. São Paulo: Atlas, 2004.• PEIXINHO, Manoel Messias. Os princípios da Constituição de 1988. Rio de Janeiro: Lúmen Júris, 2001.• Piçarra, Nuno, A separação dos poderes como doutrina e princípio constitucional: um contributo para o estudo das
suas origens e evolução, Coimbra, Coimbra Editora, 1989 • NUCCI, Guilherme de Souza. Manual de processo penal e execução penal. 3. ed. – São Paulo: Editora Revista dos
Tribunais, 2007.• PEREIRA, Caio Mario da Silva. Instituições de direito civil, v.1. Rio de Janeiro: Forense. 2004.• POLETTI, Ronaldo. Introdução ao Direito. 4. ed., São Paulo: Saraiva, 2010..• PRADO, Luiz Regis. Curso de direito penal brasileiro. 11. ed. São Paulo : RT, 2007, v. 2.• REALE, Miguel. Lições Preliminares de Direito. 27.ed São Paulo: Saraiva, 2006.• REQUIÃO, Rubens. Curso de direito comercial. 8. ed. São Paulo: Saraiva, 1977, v. 1 e 2.• RUSSOMANO, Mozart Victor. Comentários à Consolidação das Leis do Trabalho. 3. ed. Rio de Janeiro: Forense,
2005.• SELL, Carlos Eduardo. Sociologia Clássica . Itajai: EdUnivali, 2002• VENOSA, Sílvio de Salvo. Direito Civil (Parte Geral), v.1 – 3 ed. São Paulo: Atlas. 2003.
REFERÊNCIAS
ATENÇÃOParte deste material foi coletado na internet e não foi possível identificar a
autoria. Este material se destina para fins de estudo e não se encontra completamente atualizado.
• _________________Obrigado pela atenção!!
• Acimarney C. S. Freitas – Advogado – OAB-BA Nº 30.553
• Professor de Direito do Instituto Federal de Educação Ciência e Tecnologia da Bahia – IFBA – campus de Vitória da Conquista
• Diretor do Instituto Federal de Educação Ciência e Tecnologia da Bahia – IFBA – campus de Brumado.
• Bacharel em Teologia
• Especialista em Direito Educacional - FTC
• Especialista em Educação Profissional e de Jovens e Adultos - IFBA
• Mestrando em Filosofia - UFSC
Email: [email protected]
Facebook: Ney Maximus
FIM