Software. .SANGLARD, Moacir

Curso Superior de Formao Especfica em Anlise de Sistemas
POL 3420 ENGENHARIA DE SOFTWARE

Objetivos : Apresentar os principais conceitos de Engenharia de software, com nfase no planejamento e na qualidade. Ementa : Fatores considerados no desenvolvimento de software; Planejamento do projeto de software; Estimativa de custos; Tcnicas de estimativa de custo (software, Peopleware, manuteno); Especificao de requisitos; Projeto de software; Implementao (Tipos de linguagem, Ferramentas CASE, Tcnicas de verificao e validao); Manuteno (Aumentando a manutenibilidade, Aspectos gerenciais e mtricas, Manuteno de configurao, Outras ferramentas e tcnicas); Estudo de casos. Professor : Moacir Rodrigues Sanglard Junior. CONTEDO PROGRAMTICO UNIDADE I - CONCEITUAO ......................................................................................3 I.1 - FATORES CONSIDERADOS NO DESENVOLVIMENTO DE SOFTWARE ............................................ 3 I.2 - ASPECTOS GERENCIAIS ........................................................................................... 19 I.3 CATEGORIAS DE PROJETOS....................................................................................... 19 I.4 FATORES DE QUALIDADE E PRODUTIVIDADE ................................................................... 20 Medidas de Produtividade ........................................................................................ 20 UNIDADE II - PLANEJAMENTO DO PROJETO DE SOFTWARE ...................................... 26 II.1 PLANEJAMENTO DO PROCESSO DE DESENVOLVIMENTO...................................................... 26 II.2 PLANEJAMENTO DA ESTRUTURA ORGANIZACIONAL .......................................................... 27 II.3 OUTRAS ATIVIDADES DE PLANEJAMENTO ..................................................................... 28 EXERCCIO - UNIDADE II ................................................................................................ 29 PROVA 1 ................................................................................................................... 29 UNIDADE III - ESTIMATIVAS DE CUSTO.................................................................... 30 INTRODUO............................................................................................................... 30 III.1 FATORES DETERMINANTES ..................................................................................... 30 III.2 TCNICAS PARA ESTIMATIVA DE CUSTOS .................................................................... 31 III.3 CUSTO DE PESSOAL ............................................................................................. 35 III.4 CUSTO DE MANUTENO ....................................................................................... 35 UNIDADE IV - TCNICAS E FERRAMENTAS DA ENGENHARIA DE SOFTWARE ............. 37 IV.1 - TCNICAS DE IMPLEMENTAO ................................................................................. 37 IV.2 - LINGUAGENS DE PROGRAMAO ............................................................................... 38 Introduo ............................................................................................................ 38 Codificao e Traduo para o Computador ............................................................... 38 A Escolha de Uma Linguagem .................................................................................. 40 Estilo de Codificao ............................................................................................... 40 Eficincia............................................................................................................... 40 IV.3 - TCNICAS DE VERIFICAO E VALIDAO .................................................................... 40 IV.4 - MANUTENO DE SOFTWARE ................................................................................... 41 UNIDADE V LABORATRIO .................................................................................... 42 V.1 - ESTUDO DE CASO UTILIZANDO FERRAMENTA EM COMPUTADOR ............................................ 42
Prof. Moacir Sanglard V2.1 1/43
V.2 - PROJETO FINAL DE CURSO ....................................................................................... 42 PROVA 2 ................................................................................................................... 42
BIBLIOGRAFIA RECOMENDADA PARA A MATRIA PRESSMAN, Roger S. (2002). Engenharia de Software. Editora: McGraw-Hill. FIORINI, Soeli T., VON STAA, Arndt., BAPTISTA, Renan Martins (1998). Engenharia de Software com CMM. Editora: Brasport. MAFFEO, Bruno (1997). Engenharia de Software e Especificao de Sistemas. Editora: Campus.
ATENO Esta apostila serve somente como um guia para a matria, no havendo compromisso com o fornecimento de detalhes sobre os tpicos abordados. Para a obteno de mais detalhes sobre os assuntos trabalhos, consulte a bibliografia citada acima e ao final deste documento.
Prof. Moacir Sanglard
V2.1
2/43
Unidade I - Conceituao
I.1 - Fatores Considerados no Desenvolvimento de Software
SOFTWARE
ENGENHARIA DE SOFTWARE
A IMPORTNCIA DO SOFTWARE
EVOLUO CARACTERSTICAS E COMPONENTES PROBLEMAS E CAUSAS DEFINIO DE ENGENHARIA DE SOFTWARE
V2.1
3/43
A IMPORTNCIA DO SOFTWARE
AVANOS DA MICROELETRNICA
MAIOR PODER DE COMPUTAO A CUSTO BAIXO
ASSOMBROSA QUALIDADE DE ARMAZENAMENTO E PROCESSAMENTO
O SOFTWARE O MECANISMO QUE POSSIBILITA APROVEITAR E DAR VAZO A ESSE POTENCIAL
V2.1
4/43
EVOLUO
SISTEMAS DE DESK-TOP PODEROSOS TECNOLOGIAS ORIENTADAS A OBJETOS

SISTEMAS DISTRIBUDOS
SISTEMAS ESPECIALISTAS REDES NEURAIS ARTIFICIAIS COMPUTAO PARALELA
ORIENTAO A BATCH DISTRIBUO LIMITADA SOFTWARE CUSTOMIZADO
MULTIUSURIO TEMPO REAL BANCO DE DADOS PRODUTOS DE SOFTWARE
INTELIGNCIA HARDWARE DE BAIXO CUSTO
IMPACTO DE CONSUMO
1950
1960
1970
1980
2000
V2.1
5/43
CARACTERSTICAS E COMPONENTES O SOFTWARE DESENVOLVIDO OU PROJETADO POR ENGENHARIA, NO MANUFATURADO NO SENTIDO CLSSICO ( NO PROCESSO MECNICO) O SOFTWARE NO SE DESGASTA Curva de falha para o hardware Curva ideal de falhas do software Curva real de falhas do software A MAIORIA DOS SOFTWARES FEITO SOB MEDIDA EM VEZ DE SER MONTADO DE COMPONENTES EXISTENTES COMPONENTES DO SOFTWARE SO CRIADOS POR MEIO DE UMA SRIE DE CONVERSES QUE MAPEIAM AS EXIGNCIAS DO CLIENTE PARA CDICO EXECUTVEL EM MQUINA
O MODELO DAS EXIGNCIAS
PROJETO
CODIFICAO EM
LINGUAGEM
AS LINGUAGENS EM USO SO: LINGUAGENS DE MQUINA : LINGUAGENS DE ALTO NVEL: Pascal, C, ADA, C++, Object Pascal, Eiffel, LISP, PROLOG, etc. E NO PROCEDIMENTAIS: Linguagens de Banco de Dados
V2.1
6/43
Produtos de uma soluo com a aplicao de engenharia de software: Cdigo Executvel (Programa, Subprogramas, DLLs, Scripts etc.) Cdigo Fonte Bibliotecas Banco de Dados Manual do Usurio (Help On-line) Manual de Operao Manual Tcnico (Documentao do Cdigo) Treinamento Manual de Instalao (Pacote de Instalao) Manual de Procedimentos
EXIGNCIA: REUSABILIDADE
V2.1
7/43
APLICAES EM SOFTWARES SOFTWARE BSICO COMPILADORES, EDITORES DE TEXTOS, SISTEMAS OPERACIONAIS etc. SOFTWARE DE TEMPO REAL RESPONDE DENTRO DE RESTRIES DE TEMPO ESTRITAS. SISTEMA DE CONTROLE DE VO E DE SINALIZAO DE TRNSITO SOFTWARE COMERCIAL FOLHA DE PAGAMENTO, CONTAS A PAGAR E A RECEBER, ESTOQUE, EVOLUINDO PARA MIS - OPERAES COMERCIAIS E DE APOIO A DECISO SOFTWARE CIENTFICO E DE ENGENHARIA SISTEMA DE ASTRONOMIA, SISTEMA DE CONTROLE DA DINMICA ORBITAL DE NAVES ESPACIAIS, SISTEMAS DE MANUFATURA AUTOMATIZADA, CAD etc. SOFTWARE EMBUTIDO FUNES DIGITAIS EM AUTOMVEIS (CONTROLE DE COMBUSTVEL, SISTEMA DE FREIOS, CONTROLE DE TECLADO PARA FORNOS MICROONDAS SOFTWARE DE COMPUTADOR PESSOAL
PROCESSAMENTO DE TEXTOS, PLANILHA ELETRNICA, GERENCIADOR DE DADOS etc. SOFTWARE DE INTELIGNCIA ARTIFICIAL SOFTWARE BASEADO EM CONHECIMENTO
V2.1
8/43
PROBLEMAS AS ESTIMATIVAS DE PRAZO E DE CUSTO SO FREQUENTEMENTE IMPRECISAS A PRODUTIVIDADE DAS PESSOAS DA REA DE SOFTWARE NO TEM ACOMPANHADO A DEMANDA POR SERVIOS A QUALIDADE DE SOFTWARE MENOS QUE A ADEQUADA NO SE DEDICA TEMPO COLETA DE DADOS ( ERRA-SE NO PLANEJAMENTO ) INSATISFAO DO CLIENTE COM O SISTEMA PRONTO ( COMUNICAO ENTRE O CLIENTE E O DESENVOLVEDOR FRACA) DIFICULDADE EM MANTER O SOFTWARE EXISTENTE
E CAUSAS
ANALISTA X USURIO
V2.1
9/43
CAUSAS EXPERINCIA POUCO MAIS DE 40 ANOS PROFISSIONAIS DE INFORMTICA COM POUCO TREINAMENTO FORMAL EM TCNICAS PARA DESENVOLVIMENTO DE SOFTWARES GERENTES SEM BACKGROUND TUDO DEVE SER FEITO PARA ONTEM
V2.1
10/43
ENGENHARIA DE SOFTWARE
O estabelecimento e uso de slidos princpios de engenharia para que se possa obter economicamente um software que seja confivel e que funcione eficientemente em mquinas reais. Fritz Bauer
uma disciplina que integra mtodos, ferramentas e procedimentos para o desenvolvimento de software de computador. mtodos: envolvem um amplo conjunto de tarefas que incluem: planejamento e estimativa de projeto, anlise de requisitos de software e de sistemas, projeto de estrutura de dados, especificao e codificao de programas, teste e manuteno. ferramentas Engineering : CASE Computer-Aided Software
procedimentos : constituem o elo de ligao que mantm juntos os mtodos e as ferramentas para desenvolvimento do software.
V2.1
11/43
CICLO CLSSICO DA ENGENHARIA DE SOFTWARE
Estudode V iabilidade A nlise de Sistem as Projetode Sistem as C onstruo Testes Im plantao M anuteno
1 Estudo de Viabilidade
Especificao preliminar de requisitos e restries Anlise de Custo-benefcio Benefcios quantitativos: Anlise Financeira - Clculos VPL = VPB - VPC VPL = Valor Presente Lquido VPB = Valor Presente dos Benefcios VPC = Valor Presente dos Custos Quando VPL > 0, o projeto gera valor Mesmo projetos com VPL < 0, consumidores de valor, podem ser aceitos, principalmente quando eles representem opes de ganhos futuros vide mercado de opes reais.
2 Anlise de Sistemas
O que fazer? Ausncia de detalhes fsicos, de implementao.
V2.1 12/43
3 Projeto de Sistemas
Como fazer? Incorporao dos detalhes fsicos.
4 Implementao (ou Construo)

Gerao da codificao e do banco de dados Testes
4 Testes
Integrao de Mdulos Integrao de Sistemas Homologao pelos Usurios
5 Implantao
Plano de implantao Plano de contingncia Treinamento Converses e migraes Implantao em Produo
6 Manuteno
Manutenes corretivas Manutenes evolutivas e adaptativas
V2.1
13/43
MODELOS DE PROCESSO DE DESENVOLVIMENTO DE SOFTWARE

MODELO CASCATA
Definio e anlise de requisitos
Desenho
Implementao e Teste
Integrao e Teste
Operacionalizao e Manuteno
V2.1
14/43
PROTOTIPAO
PROCESSO QUE CAPACITA O DESENVOLVEDOR A CRIAR UM MODELO DO SOFTWARE QUE SER IMPLEMENTADO.
Fim
Incio
Coleta e refinamento dos requisitos
Projeto Rpido
Engenharia do Produto Construo do Prottipo Refinamento do Produto
Avaliao do Prottipo pelo Cliente
V2.1
15/43
O MODELO ESPIRAL
Determ ine ob jectiv es alternatives and cons traint s
R isk analys is R isk analys is R isk analys is Prot otyp e 2 Risk analysis Prot oty pe 1 C oncept o f Operati on
Ev aluate alt ern atives id en tify, resol ve risk s
Prot otyp e 3
Operati onal prot oyp e
R EVIEW Requi rement s pl an Li fe-cycle pl an
Sim ul ati ons, m odels, b en ch marks S /W requi rement s Prod uct desi gn
Develop ment pl an Integrati on and t est p lan
P lan next p has e
C ode Uni t t es t Desi gn V& V Integr ati on test Accep tance test Develop, v erify Serv ice next -l evel p rod uct
Requi rement valid ati on
Detail ed desi gn
- O processo representado como uma espiral em vez de sequncia de actividades - Cada volta da espiral representa uma fase do processo - No h fases fixas como especifica e desenho - as voltas na espiral so determinadas pelo que requerido - Riscos so explicitamente avaliados e resolvidos no processo
V2.1
16/43
TCNICAS DE QUARTA GERAO
C de oleta requisitos Estratgia de projeto Im entao plem usando 4G L Testes
As novas ferramentas CASE agora suportam o uso das 4GT. Gerao de Cdigo Automtica
V2.1
17/43
COMBINANDO PARADIGMAS
OBTENO PRELIMINAR DOS REQUISITOS
ANLISE DE REQUISITOS
PROTOTIPAO
4GT
MODELO ESPIRAL
PROJETO PROTOTIPAO ENSIMA ITERAO CODIFICAO 4GT
4GT
MODELO ESPIRAL ENSIMA ITERAO
REALIZAO DE TESTES SISTEMA OPERACIONAL
MANUTENO
V2.1
18/43
I.2 - Aspectos Gerenciais

Pg. 83 Gerenciamento de Projetos Page Jones: Planejar Organizar Integrar Medir Revisar Engenharia de Software Pressman: 1. Iniciando um Projeto estabelecimento de objetivos e escopo; alternativas; restries. 2. Medidas e Mtricas. 3. Estimativa (Planejamento) 4. Anlise de Riscos 5. Monitorao e Controle
I.3 Categorias de Projetos

Definio de Projeto 1 - UMA ORIGINAL ORGANIZAO DE PESSOAS E RECURSOS PARA ATINGIR UM PROPSITO ESPECFICO, NUM PERODO DE TEMPO FINITO ORIGINAL - Cada Projeto diferente de todos os outros. ORGANIZAO DE PESSOAS E RECURSOS - Uma mistura de talentos e conhecimentos humanos, com recursos tcnicos e fsicos. PARA ATINGIR UM PROPSITO ESPECFICO - Enfatiza a necessidade dos Projetos terem sempre um objetivo tangvel e realizvel. NUM PERIODO DE TEMPO FINITO - Diferencia um projeto de um PROCESSO. Projetos iniciam com a identificao do propsito ou objetivo e terminam quando se atinge o objetivo. 2 - uma combinao de esforos organizada com a finalidade de atingir objetivos especficos, atravs da implantao de um sistema ou de uma nova verso de um sistema j existente.
V2.1
19/43
Categorias: Projetos de Desenvolvimento Projetos de Manuteno Projetos de Aquisio e Implantao
I.4 Fatores de Qualidade e Produtividade

Portabilidade - Facilidade de transportar o software entre computadores. Confiabilidade - Capacidade de executar uma funo, de forma reprodutvel. Eficincia - Desempenho das funes pretendidas com o menor recurso possvel. Correo - Ausncia de defeitos, de acordo com os requisitos. Acurcia - Avaliao qualitativa da correo, estimativa quantitativa de erros. Robustez - Continuar executando mesmo com entradas erradas. Manutenibilidade - Alterao visando a corrigir, adaptar ou aperfeioar o software em baixo custo. Facilidade de Implantao - Adequado ao ambiente scio/tecnolgico no qual ser implantado. Integridade Capacidade de suportar ataques sua integridade (Ex.: Hackers e perda de dados). Usabilidade Facilidade de uso pelo usurio. Conforto, ou seja, se amigvel ou no.
Medidas de Produtividade Medidas e Mtricas A medio nos capacita a quantificar e, por conseguinte, a administrar mais efetivamente. Muitas vezes leva a controvrsias e a argumentaes: Quais as mtricas apropriadas? Medies no mundo fsico podem ser diretas (ex.: tamanho de um parafuso) ou indiretas (ex.: qualidade dos parafusos, com base no nmero de rejeitados).
V2.1
20/43
Estimativas De esforo humano exigido. Ex.: pessoas/hora, pessoas/ms. De durao cronolgica do projeto. Ex.: em tempo de calendrio. De custo. Ex.: em reais ou dlares. Em muitos casos as estimativas so feitas usando-se a experincia passada como nico guia, mas somente ela poder no ser suficiente para todos os casos. Assim, surgiram vrias tcnicas de estimativa para o desenvolvimento de software. Atributos das tcnicas de estimativa: O escopo do projeto deve ser estabelecido antecipadamente; O histrico de aferies passadas usado como uma base a partir da qual estimativas so feitas; O projeto dividido em pequenas partes que so estimadas individualmente.
Medidas do Software O software medido pelas seguintes razes: Indicar a sua qualidade; Avaliar a produtividade das pessoas que o produzem; Avaliar os benefcios derivados, em termos de qualidade e produtividade; Formar uma linha bsica (baseline) para estimativas; Ajudar a justificar pedidos de novas ferramentas e treinamento. Mtricas de produtividade (PF / hora, LOC / hora etc.) PF = Pontos de Funo, tpico abordado mais adiante neste documento. LOC = Nmero de Linhas de Cdigo. Mtricas da qualidade (No. Erros / PF, No. Erros / LOC) Mtricas tcnicas (Ex.: complexidade lgica, grau de modularidade) Mtricas orientadas ao tamanho (Ex.: nmero de linhas de cdigo LOC) Mtricas orientadas funo (Ex.: mtodo Ponto de Funo)
Mtricas orientadas ao tamanho Medidas diretas do software e do processo de desenvolvimento LOC Linhas de Cdigo Provocam controvrsias e no so universalmente aceitas como a melhor maneira de medir Prs: Podem ser facilmente contadas; Tem significado direto, ou seja, o nmero de linhas de um programa. Contras: So dependentes da linguagem de programao, pois penalizam programas bem projetados, porm mais curtos, e no podem acomodar facilmente linguagens no procedimentais;
Seu uso em estimativas requer um nvel de detalhe alto, ficando difcil na Anlise, por exemplo, saber quantas linhas ter o sistema. Mtricas orientadas funo Medidas indiretas do software e do processo de desenvolvimento Em vez de contar as linhas de cdigo, a mtrica concentra-se na funcionalidade ou na utilidade do programa Tambm controversa FP Mtodo do Ponto de Funo
Parmetros de medida Nmero de entradas do usurio Nmero de sadas do usurio Nmero de consultas do usurio Nmero de arquivos lgicos internos Nmero de arquivos de interface externa Contagem total Simples (__ x 3) + (__ x 4) + (__ x 3) + (__ x 7) + (__ x 5) + Fator de Ponderao Mdio Complexo (__ x 4) + (__ x 6) + (__ x 5) + (__ x 7) + (__ x 4) + (__ x 6) + (__ x 10) + (__ x 15) + (__ x 7) + (__ x 10) + Subtota l = = = = = =
+ + + +
Nmero de entradas do usurio: cada entrada do usurio que proporcione dados distintos orientados aplicao contada. As entradas dever ser distinguidas das consultas, as quais so contadas separadamente. Nmero de sadas do usurio: cada sada do usurio que proporcione informaes orientadas a aplicao contada. Por exemplo, um relatrio contado como uma sada. Nmero de consultas do usurio: uma consulta definida como uma entrada on-line que resulte na gerao de alguma resposta e software imediata na forma de uma sada on-line. Cada consulta distinta contada. Nmero de arquivos lgicos internos: cada arquivo lgico, ou seja, um agrupamento lgico de dados, que pode ser uma parte de um grande banco de dados ou um arquivo convencional que seja mantido pela aplicao, contado. Nmero de arquivos de interface externa: todas as interfaces legveis por mquina (por exemplo, arquivos de dados em fita ou disco) que sejam usadas para transmitir informaes a outro sistema so contadas, incluindo os arquivos lgicos que sejam somente consultados pela aplicao. Assim que os dados anteriores tiverem sido reunidos, um valor de complexidade associado a cada contagem. Cada organizao desenvolve critrios para determinar se uma entrada particular simples, mdia ou complexa. A contagem total obtida atravs do somatrio dos valores da coluna Sub total representa o Nmero de Pontos de Funo No Ajustados. Valor de Ajuste da Complexidade definido com base nas respostas s perguntas a seguir, que so dadas atravs da pontuao numa escala de 0 a 5:
0 Sem influncia
1 Incidental
2 Moderado
3 Mdio
4 Significativo
5 Essencial
1) o sistema requer backup e recuperao confiveis? 2) So exigidas comunicaes de dados? 3) H funes de processamento distribudas? 4) O desempenho crtico? 5) O sistema funcionar intensivamente utilizado? num ambiente operacional existente,
6) O sistema requer entrada de dados on-line? 7) A entrada de dados on-line exige que a transao de entrada seja elaborada em mltiplas telas ou operaes? 8) Os arquivos so atualizados on-line? 9) A entrada, sada, arquivos oo consultas so complexos? 10) O processo interno complexo? 11) O cdigo foi projetado de forma a ser reutilizvel? 12) A converso e a instalao esto includas no projeto? 13) O sistema organizaes? projetado para mltiplas instalaes em diferentes
14) A aplicao projetada de forma a facilitar mudanas (parametrizao, customizao) e o uso (conforto) pelo usurio? Somar os valores dados a cada pergunta anterior para compor o Valor de Ajuste da Complexidade Para computar os pontos de funo, a seguinte frmula usada: PF = PontosdeFunoNoAjustados ValordeAjustedaComplexidade] x [0,65 + 0,01 x =
[0,65 + 0,01 x FatordeAjustedaComplexidade
ValordeAjustedaComplexidade]
Os pontos de funo - PF podem ser usados de maneira anloga s LOC como medida de produtividade, qualidade e outros atributos do software: Produtividade = PF / pessoa-ms Qualidade = defeitos / PF Custo = $ / PF Documentao = pginas de documentao / PF Prs:
Independe da linguagem de programao, ou seja, funciona para linguagens convencionais e no-procedimentais; Se baseia em dados que tm maior probabilidade de ser conhecidos logo no comeo da evoluo de um projeto (estimativas). Contras: Se baseia em dados subjetivos; Dificuldade de definio do domnio da aplicao a posteriori; No tem nenhum significado direto, apenas um nmero. Ponto de Particularidade Feature Point Variao do mtodo de PF para aplicaes de tempo real, controle de processos e software embutido
Parmetros de medida Nmero de entradas do usurio Nmero de sadas do usurio Nmero de consultas do usurio Nmero de arquivos lgicos internos Nmero de arquivos de interface externa Algoritmos Contagem total Contagem Fator de Ponderao x4 x5 x4 x7 x7 x3 Subtotal = = = = = = = + + + + + +
A tabela anterior deve ser utilizada para o clculo dos Pontos de Funo No Ajustados e os demais clculos so feitos de forma idntica
V2.1
24/43
Ponto por Objeto Medida indireta do software criada por Barry Boehm para fornecer subsdio em termos de informao de tamanho necessria para a aplicao do modelo COCOMO II, descrito a seguir nesta apostila. Calculada usando-se a contagem da quantidade de: telas (inerface com o usurio), relatrios e componentes. Cada instncia de objeto classificada em simples, mdia ou difcil, usando critrios definidos por Boehm, basicamente quantidade e fonte das tabelas de dados do cliente e servidores, que so necessrias para gerar a tela ou relatrio, e da quantidade de campos ou sees apresentadas como parte da tela ou relatrio. Aps a determinao da complexidade, a quantidade de telas, relatrios e de componentes ponderada de acordo com o quadro a seguir:
Tipo de objeto Tela Relatrio Componente 3GL Fator de Ponderao Simples Mdio Difcil (__ x 1) + (__ x 2) + (__ x 3) + (__ x 2) + (__ x 5) + (__ x 8) + (__ x 10) + TOTAL
SubTotal
= = = =
+ +
Novos Pontos por Objeto = NOP = (pontos por objeto) x [(100 - % de reuso)/100]
V2.1
25/43
Unidade II - Planejamento do Projeto de Software

II.1 Planejamento do Processo de Desenvolvimento
O planejamento est para o projeto como o roteiro est para uma viagem, indica pontos intermedirios no caminho para os objetivos do projeto e identifica as tarefas que levam o projeto de um ponto para o seguinte. Planejamento a longo e curto prazos Planejamento a longo prazo: desde o incio at o fim. Planejamento a curto prazo: por exemplo, ao fim da definio do escopo do projeto, pode-se planejar a fase de anlise com bastante exatido, mas no a fase de projeto, porque no se pode planejar com certeza uma soluo antes de se especificar o problema em detalhes. Fontes principais para o desenvolvimento de um planejamento: a metodologia da empresa, a experincia que voc j adquiriu, a experincia da equipe do projeto e livros de consulta. Representao do planejamento: mtodo do caminho crtico (CPM) e grfico de Gantt (ou de barras). Estratgias de projeto Conservadora: s inicia a fase seguinte quando a fase anterior estiver completamente terminada, para todos os componentes. Radical: desenvolvimento das fases em paralelo. Obs.: Modelo Espiral de Desenvolvimento. Planejamento das Etapas / Fases / Atividades Planejamento dos Recursos Humanos Hardware Desenvolvimento, Testes, Treinamento, Produo, Segurana etc. Software Ferramenta de Planejamento e Gerenciamento, Ferramenta de Anlise e Projeto, Ferramenta de Programao, Ferramenta de Integrao e Testes, Ferramenta de Construo de Prottipos e Simulao, Ferramenta de Manuteno, Ferramenta de Segurana etc. Reusabilidade Aquisio de software Adaptaes podem custar mais caro que desenvolver um novo
V2.1
26/43
II.2 Planejamento da Estrutura Organizacional

Recursos Humanos Habilidades (motivao e produtividade) Disponibilidade Durao das Tarefas Data de Incio O nmero de pessoas exigido em um projeto de software s pode ser determinado depois que uma estimativa de esforo for feita (Ex.: pessoas/hora, pessoas/dia ou pessoas/ms) Acrescentar pessoas tardiamente a um projeto pode ter um efeito negativo, ao invs de acelerar os trabalhos, pois as novas pessoas devem aprender com aquelas que estariam executando as tarefas. Assim sendo, o tempo gasto com o ensinamento deixa de ser aplicado execuo dos trabalhos, retardando ainda mais o cronograma. Levar em considerao a produtividade de cada recurso na fase/tarefa especfica Desafio: maximizao da relao Talento x Atividade x Motivao Ateno: Promoo versus Cargo Gerencial Um bom tcnico no ser necessariamente um bom gerente; cuidado com a promoo para o nvel de incompetncia Uma das solues pode ser a promoo em nvel tcnico (Ex.: empresas que aplicam a poltica de Carreira em Y)
V2.1
27/43
Elaborao do organograma do projeto: Exemplo de organograma de projeto:
Gerente
Infraestrutura
Aplicaes
Negcio
Telecomunicaes
Geral
Desenvolvimento
Suporte e Arquitetura
Operaes
Analistas
Analistas
Operadores
Programadores
Administradores de Dados - ADs
Administradores de Banco de Dados - DBAs
II.3 Outras Atividades de Planejamento

Anlise dos Riscos Identificao (Riscos do Projeto, Riscos Tcnicos e Riscos de Mercado) Projeo (Probabilidade e Impactos) Avaliao (Como Evit-los e Control-los) Gerenciamento e Monitorao Distribuio do Esforo (sugesto para projetos tradicionais, que no utilizem a gerao de cdigo para os objetos finais da aplicao, podendo variar dependendo das caractersticas do projeto) 2 a 3% - Planejamento 40 a 50% - Anlise e Projeto (sendo 10 a 25% para Anlise e 20 a 25% para Projeto) 30 a 40% - Testes e Depurao 15 a 20% - Codificao Determinao de um Cronograma Rastreamento e Controle do Projeto
V2.1
28/43
Exerccio - Unidade II
MINI-MUNDO PROPOSTO COMO ESTUDO DE CASO Um restaurante necessita de automatizar algumas de suas atividades. Desta forma, solicitou um sistema que controlasse o pedido de encomendas feitas pelo cliente atravs do telefone, o fornecimento e a compra de ingredientes para fazer os pratos e a composio de cada prato. Toda encomenda feita pelo cliente, naturalmente, possui um nmero para identific-la. Ao fazer uma encomenda, o cliente informa seu nome, endereo, telefone e os pratos que deseja, com a respectivas quantidades. Por exemplo, a encomenda 123 do cliente Pedro constituda de 3 saladas mistas e 2 frangos grelhados simples. Cada prato possui o seu preo unitrio. Um dos objetivos do sistema registrar para cada prato, os ingredientes que o compem, com as respectivas quantidades. Ou seja, um pudim composto de duas latas de leite condensado, dentre outras coisas. Outro objetivo gerar uma listagem, contendo para cada fornecedor, os ingredientes que fornece. Tambm necessrio que seja gerado um relatrio contendo, para cada encomenda, o nome do cliente, o endereo, o telefone e os pratos pedidos, com as respectivas quantidades e preos. O sistema deve registrar a compra de ingredientes, guardando o nmero da nota fiscal, a quantidade comprada de cada ingrediente, a data de compra e o nome do fornecedor, a fim de contabilizar o custo com a compra de ingredientes.
Prova 1
V2.1
29/43
Unidade III - Estimativas de Custo

Introduo
Ainda que a realizao de estimativas seja em grande parte tanto arte como cincia, essa importante atividade no precisa ser conduzida ocasionalmente.
III.1 Fatores Determinantes

Complexidade do projeto tem forte efeito sobre a incerteza Tamanho do projeto Grau de estruturao do projeto facilidade com que as funes podem ser dispostas em compartimentos e hierarquizadas Disponibilidade de informaes histricas Definio do escopo do software delimitao das funcionalidades Recursos humanos Recursos de hardware Recursos de software Manuteno Mtricas utilizadas Tcnica de estimativa
V2.1
30/43
III.2 Tcnicas para Estimativa de Custos

Para conseguirmos estimar com confiana, temos uma srie de opes: 1. 2. 3. 4. Atrasar as estimativas at um ponto tardio do desenvolvimento Usar tcnicas de decomposio para gerar as estimativas Desenvolver um modelo emprico para a estimativa Adquirir uma ou mais ferramentas de estimativa automatizadas
Obs.: Cada uma das opes to boa quanto to bons forem os dados histricos Tcnicas de Decomposio Estimativas de LOC e Pontos de Funo Estima-se LOC ou PF otimista, mais provvel e pessimista para cada funo Mdia ponderada: MP = (otimistas + 4*maisprovveis + pessimistas) / 6 Aplica uma das abordagens a seguir: 1. Multiplicar MP pela mtrica de produtividade mdia correspondente MP calculada anteriormente. Ex: MP = 310 PF Produtividade mdia baseada em projetos passados = 5,5 PF/pessoams Esforo = 310 / 5,5 = 56 pessoa-ms 2. Multiplicar MP pelo valor de produtividade ajustado, que se baseia no nvel de complexidade percebido da funo. Para as funes de complexidade mdia, usa-se a mtrica de produtividade mdia. As de complexidade baixa, tm a mtrica reduzida e as de complexidade alta, tm a mtrica aumentada (um tanto subjetivamente). Aps todo este trabalho, vem a pergunta: As estimativas esto corretas? A nica resposta razovel : no podemos ter certeza.
V2.1
31/43
Estimativa de Esforo Tcnica mais comum para se levantar os custos de qualquer projeto de desenvolvimento de engenharia. Um nmero de pessoas-dia, ms ou ano aplicado soluo de cada tarefa do projeto. Um custo em dlares associado a cada unidade de esforo e um custo estimado, derivado. Exemplo:
Tarefas Funes Funo 1 Funo 2 Funo 3 Funo 4 Funo 5 Funo 6 Funo 7 1,0 2,0 2,5 2,0 1,5 1,5 4,0 2,0 10,0 12,0 6,0 11,0 6,0 14,0 0,5 4,5 6,0 3,0 4,0 3,5 5,0 26.5 4.250 112.625 3,5 9,5 11,0 4,0 10,5 5,0 7,0 50.5 4.500 227.250 7 26 31,5 15 27 16 30 152,5 708.075
Custo estimado para todas as tarefas Esforo estimado para todas as tarefas
Anlise dos Requisitos
Projeto
Cdigo
Teste
Total
Total* 14,5 61 Taxa ($) 5.200 4.800 Custo ($) 75.400 292.800 * Todas as estimativas em pessoas-ms
Modelos empricos de estimativa COCOMO Constructive Cost Model Modelo de Custo Construtivo Em seu livro sobre engenharia econmica de software, Barry Boehm apresenta uma hierarquia de modelos de estimativa de software que traz o nome de COCOMO, de COnstructive Cost MOdel (Modelo de Custo Construtivo). O modelo COCOMO evoluiu para um modelo de estimativa mais abrangente, chamado COCOMO II, que se baseia em modelos matemticos obtidos a partir da experincia com diversos projetos. uma hierarquia de modelos de estimativa: Modelo de composio da aplicao (usado nos primeiros estgios da engenharia de software); Modelo do primeiro estgio do projeto (usado aps a definio dos requisitos e arquitetura bsica do software); Modelo para o estgio aps a arquitetura (usado na construo). Pode ser usado para definir um prazo timo para a execuo do Projeto atravs da utilizao de frmulas matemticas, requerendo informao de tamanho: Pontos de Funo; Pontos por Objeto; LOCs. Seguindo a mtrica de Pontos por Objeto, uma taxa de produtividade proposta de acordo com a tabela a seguir: PROD = NOP/pessoa-ms
V2.1
32/43
Experincia/capacidade do Muito desenvolvedor baixa Maturidade / capacidade do ambiente PROD Muito baixa 4
Baixa Baixa 7
Normal Normal 13
Alta Alta 25
Muito alta Muito alta 50
Determinada a taxa de produtividade, a estimativa do esforo em pessoams pode ser obtida da seguinte forma: Esforo estimado = NOP/PROD Podem ser aplicados modelos mais avanados do COCOMO II com a utilizao de Pontos de Funo e Linhas de Cdigo (LOC). O Modelo de Estimativa de Putnam um modelo dinmico de mltiplas variveis que pressupe uma distribuio de esforo especfica ao longo da existncia de um projeto de desenvolvimento de software. O modelo foi construdo a partir de dados de produtividade coletados em mais de 4.000 projetos de software contemporneos: E = [LOC x B0,333 /P]3 x (1/t4) onde E = esforo em pessoas-ms ou pessoas-ano; t = durao do projeto em meses ou anos; B = fator de aptides especiais, que aumenta lentamente medida que cresce a necessidade de integrao, teste, garantia de qualidade, documentao e aptides gerenciais, sendo que para projetos menores (KLOC = 5 a 15), B = 0,16 e para projetos maiores que 70 KLOC, B = 0,39; parmetro de produtividade, que reflete a maturidade do processo e gerncia, uso de boas prticas de engenharia de software, nvel das linguagens de programao usadas, estado do ambiente de software, aptides e experincia da equipe e complexidade da aplicao. Exemplos de P: 2.000, para software embutido de tempo real; 10.000, para software de telecomunicaes; 12.000 para software cientfico, como CAD; 28.000 para aplicaes comerciais; tambm pode ser obtido com dados histricos coletados de desenvolvimentos anteriores da prpria empresa. Ferramentas de Estimativa Automatizadas As tcnicas de decomposio e os modelos de estimativa empricos descritos nas sees precedentes podem ser implementados em software. Essas ferramentas de estimativa automatizadas permitem que o planejador estime os custos e o esforo e realize anlises "o que se..." de importantes variveis de projeto, tais como a data de entrega e a composio do pessoal. No obstante existam muitas ferramentas de estimativa automatizadas, todas elas exibem as mesmas caractersticas gerais e exigem uma ou mais das seguintes categorias de dados:
l. Uma estimativa quantitativa do tamanho do projeto (por exemplo, LOC) ou da funcionalidade (dados de pontos-por-funo). 2. Caractersticas de projeto qualitativas, tais como complexidade, confiabilidade exigida ou carter crtico com relao ao negcio. 3. Alguma descrio do pessoal responsvel pelo desenvolvimento e/ou ambiente de desenvolvimento. A partir desses dados, o modelo implementado pela ferramenta de estimativa automatizada oferece estimativas do esforo exigido para se concluir o projeto, custos, composio do pessoal e, em certos casos, cronograma de desenvolvimento e riscos associados. Caractersticas gerais funes genricas das ferramentas: Dimensionamento dos produtos do projeto sujeitos a entrega; Seleo das atividades do projeto; Previso dos nveis de pessoal; Previso do esforo; Previso do custo; Previso dos cronogramas. As ferramentas de estimativa automatizadas realizam um dilogo com o planejador, obtendo no s informaes apropriadas de apoio e sobre o projeto mas tambm produzindo uma sada tanto tabular como (em certos casos) grfica. Quando ferramentas diferentes so aplicadas ao mesmo projeto, encontrada uma variao relativamente grande nos resultados estimados. Mais importante, os valores previstos s vezes so significativamente diferentes dos valores reais. Isso refora a noo de que a sada das ferramentas de estimativa deve ser usada como uma das fontes, e no como a nica fonte de estimativa.
V2.1
34/43
III.3 Custo de Pessoal

Habilidades Em Engenharia de Software. Na obteno dos requisitos do usurio (entrevistas, conduo de reunies, JADs, resoluo de conflitos) e documentao. Na ferramenta CASE. Em Anlise (Funes e Modelagem de Dados). Em Projeto, Codificao e Testes. Em Treinamento. Em Implantao de Projetos. No Sistema Operacional do projeto. Na linguagem de programao. No banco de dados do projeto. No trabalho em equipe. Em manuteno. Nvel de Senioridade Junior Pleno Snior Recursos Prprios e Terceirizao Custos Trabalhistas: Frias, 13o Salrio, Faltas por Doenas, Processos Legais etc. Alocao do Tempo. Fidelidade e Compromisso. Cooperativas, empresas e microempresas pessoais e consultorias. Esforo, Produtividade e Custo de Pessoal
III.4 Custo de Manuteno

O custo da manuteno de software tem aumentado firmemente durante os ltimos 20 anos. Durante a dcada de 1970, a manuteno era responsvel por um ndice entre 35% e 40% do oramento de software para uma organizao de sistemas de informao. Esse valor pulou para aproximadamente 60% durante a dcada de 1980. Se nada for feito para melhorar nossa abordagem manuteno, muitas empresas gastaro aproximadamente 80% de seus oramentos de software em manuteno. O custo da manuteno em dlares a nossa Porm, outros custos menos tangveis podem, por preocupao maior. Outros custos intangveis incluem: preocupao mais bvia. fim, ser uma causa de
Insatisfao do cliente quando solicitaes aparentemente legtimas de reparo ou modificao no podem ser encaminhadas oportunamente quanto ao tempo. Reduo da qualidade global do software como resultado de mudanas que introduzem erros latentes no software mantido.
V2.1
35/43
Sublevaes causadas durante os esforos de desenvolvimento quando o pessoal precisa ser "empurrado" para trabalhar numa tarefa de manuteno. O custo final da manuteno de software uma drstica diminuio de produtividade (medida em LOC por pessoa-ms ou pontos-por-funo por pessoa-ms) que encontrada quando a manuteno de programas antigos iniciada. Redues de produtividade de 40:1 foram relatadas. Ou seja, um esforo de desenvolvimento que custe 25 dlares por linha de cdigo para ser levado a efeito poderia custar mil dlares para cada linha de cdigo que mantida. O esforo despendido em manuteno pode ser dividido em atividades produtivas (por exemplo, anlise e avaliao, modificao de projeto, codificao) e atividades "quebra-cabea" (por exemplo, tentar entender o que o cdigo faz, tentar interpretar a estrutura de dados, as caractersticas de interface e os limites de desempenho). A seguinte expresso oferece um modelo de esforo de manuteno: M = p + Ke(c-d) Onde: M = esforo total despendido em manuteno; p = esforo produtivo (conforme acima descrito); K = uma constante emprica; c = uma medida da complexidade que pode ser atribuda falta de um bom projeto e documentao; d = uma medida do grau de familiaridade com o software. O modelo acima descrito indica que o esforo (e o custo) pode elevar-se exponencialmente se for usada uma abordagem de desenvolvimento de software ruim (isto , falta de engenharia de software), e se a pessoa ou grupo que usou a abordagem no estiver disponvel para realizar a manuteno.
V2.1
36/43
Unidade IV - Tcnicas e Ferramentas da Engenharia de Software

IV.1 - Tcnicas de Implementao
Reviso das tcnicas de levantamento de requisitos Entrevistas Individuais JAD Apresentao - JAD Reunies Reunies Bem-sucedidas Aspectos fundamentais do projeto de software Abstrao para uma soluo modular, muitos nveis de abstrao podem ser representados, indo desde uma descrio breve em linguagem natural, em um nvel mais alto de abstrao, at um algoritmo em portugus estruturado. Refinamento refinamento passo-a-passo top-down e o estabelecimento de uma hierarquia. Modularidade diviso do software em nomeados e endereveis. componentes separadamente
Arquitetura de software estrutura hierrquica de componentes (mdulos) procedimentais e estrutura de dados. Hierarquia de controle estrutura de programa, na qual um mdulo controla outros ou controlado por outro. Estrutura de dados representao elementos de dados individuais Procedimento de software Ocultao de informaes Projeto orientado ao fluxo de dados Projeto orientado a objeto Mtodos de projeto orientado a dados Projeto de interface com o usurio Projeto de tempo real do relacionamento lgico entre
V2.1
37/43
IV.2 - Linguagens de Programao

Introduo Linguagem de programao linguagem criada para instruir um computador a realizar suas tarefas. Regras Fixas e Rgidas de Sintaxe. Linguagem de Mquina (Primeira Gerao) e Linguagem Assembly (Segunda Gerao). Linguagens de Alto Nvel: Terceira Gerao (Por exemplo: BASIC, COBOL, FORTRAN e PASCAL); Quarta Gerao (Query Languages, Gerao de Cdigo e Capacidades Grficas. Por exemplo: SQL Structured Query Language); Quinta Gerao (Linguagens naturais semelhantes sintaxe da lngua inglesa, usadas para criar programas para inteligncia artificial e sistemas especialistas. Por exemplo: LADDER Identificao e localizao de navios; INTELLECT Interface com banco de dados de mainframes). Traduo para o Computador: Interpretador e Compilador (Linkeditor). Codificao e Traduo para o Computador Programa Cdigo (fonte objeto executvel) Algoritmo -> converso -> comandos em linguagem de programao Montagem Programa em Assembly -> montador -> programa em linguagem de mquina Funes de um montador: substituio dos cdigos de operao; substituio dos nomes de variveis; reserva de espao de memria para instrues e dados; converso de constantes; verificao da correo das instrues. Compilao Programa em linguagem de alto nvel -> compilador -> cdigo objeto Mais complexo e demorado que a montagem (1 comando pode gerar mais que 1 instruo em linguagem de mquina) O processo de compilao: front-end (anlise lxica comandos, operadores e variveis so verificados com as regras da linguagem; anlise sinttica correo dos comandos na estrutura, rvore; anlise semntica semntica esttica, ou seja, que pode ser verificada antes da execuo, por exemplo, se um comando Case tem todos os elementos) e back-end (alocao de memria; atribuio dos registradores e gerao do cdigo objeto) Linkedio (Ligao) Cdigo objeto -> incorporao das rotinas externas, de bibliotecas, ao cdigo objeto -> cdigo executvel Exemplo: Comando em Pascal:
X:= A + B; sendo A, B e X nmeros em ponto flutuante e o compilador somente suporta aritmtica de ponto flutuante via rotina externa, o cdigo substitudo por: CALL MPY_FP (1AB5, 1AB9, 1ABF) --------------endereo de memria dos dados A, B e X ndice para a biblioteca
Cdigo objeto (arquivo *.obj)
Linkedio
Software Linkeditor
Biblioteca A Biblioteca B Biblioteca C
Cdigo executvel (arquivo *.exe)
Obs.: No possvel gerar o cdigo fonte a partir do executvel
Loader tipo de linkeditor que no cria o executvel. Processo de debug identificao e correo de erros. Interpretao Compilao, linkedio e execuo de comando a comando do programa fonte No h produtos intermedirios (*.obj ou *.exe) Compilao versus interpretao Linguagens de programao compiladas Ex.: Cobol, Fortran, C e Pascal. Interpretadas Ex.: Basic (no passado), Dbase, APL e Java. Principal vantagem da interpretao: identificao e indicao de erros. Principal desvantagem: consumo de memria; possibilidade de certas partes do programa serem interpretadas tantas vezes quantas definidas no loop (interpretadores mais eficientes j evitam isto, apesar de ainda assim serem menos eficientes que os compiladores), o que pode tornar a execuo lenta.
V2.1
39/43
A Escolha de Uma Linguagem Levar em considerao os seguintes critrios: A rea de aplicao geral; A complexidade computacional e algortmica; O ambiente em que o software ser executado; Consideraes de desempenho; A complexidade da estrutura de dados; O conhecimento da equipe de desenvolvimento; A disponibilidade de um bom compilador. Estilo de Codificao Documentao do Cdigo No incio de cada sub-rotina, incluindo o corpo do programa. Sempre que se fizer algo diferente do trivial. Na declarao de variveis e tipos de dados que no forem totalmente bvios. Declarao de Dados A ordem da declarao de dados e tipos deve ser padronizada e as estruturas de dados criadas pelo projeto devem ser documentadas. Construo de Instrues Evite o uso de testes condicionais complicados; elimine os testes em condies negativas; evite um intenso aninhamento de laos ou condies; use parnteses para esclarecer expresses lgicas ou aritmticas; use smbolos de espaamento ou legibilidade para esclarecer o contedo da instruo; use somente caractersticas com padro ANSI; pense: ser que eu poderia entender isto se no tivesse sido eu a pessoa que o codificou? Estrada e Sada valide todas as entradas de dados; cheque a viabilidade de combinaes importantes de itens de entrada; mantenha o formato de entrada simples; use indicadores de final de dados, ao invs de exigir que o usurio especifique o nmero de itens; rotule os pedidos de entrada interativa, especificando as opes disponveis ou os valores limites; mantenha o formato da entrada uniforme quando uma linguagem de programao tiver requisitos de formatao rigorosos; rotule todos os relatrios de sada e de projeto.
Eficincia Eficincia de Cdigo Eficincia de memria Eficincia de Entrada e Sada
IV.3 - Tcnicas de Verificao e Validao

Garantia de Qualidade de Software Testes Unitrios Integrao de Mdulos
Interfaces Integrao de Sistemas Tipos de Testes: Funcionalidade, volume, concorrncia, performance e stress.
Teste Sistemtico de Software
IV.4 - Manuteno de Software

Sistemas Modularizados e Componentizados Sistemas Desestruturados Apresentao - Manuteno
V2.1
41/43
Unidade V Laboratrio
V.1 - Estudo de Caso Utilizando Ferramenta em Computador
ER Win: Logic Works; no Brasil Logic Way
V.2 - Projeto Final de Curso

- Construa um sistema para gesto dos pontos de funo de aplicaes.
Prova 2
V2.1
42/43
Bibliografia Utilizada para a Elaborao desta Apostila COSTA, Wilson Dias (1994). JAD Joint Application Design. Editora: IBPI Press. FIORINI, Soeli T., VON STAA, Arndt., BAPTISTA, Renan Martins (1998). Engenharia de Software com CMM. Editora: Brasport. MAXIMIANO, Antonio Cesar Amaru (1997). Administrao de Projetos Editora: Atlas. MOTTA, Rosa. Apostila de Engenharia de Software. http://www.winponta.com.br. Extrao realizada em 14 de outubro de 2001. PAGE-JONES, Meilir (1990). Gerenciamento de Projetos. Editora: Makron. PRESSMAN, Roger S. (2002). Engenharia de Software. Editora: McGraw-Hill. REZENDE, Denis Alcides (2002). Engenharia de Software e Sistemas De Informao. Editora: Brasport. On-line via
V2.1
43/43

Software. .SANGLARD, Moacir

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Software. .SANGLARD, Moacir

Transféré par

Droits d'auteur :

Formats disponibles

Curso Superior de Formao Especfica em Anlise de Sistemas

POL 3420 ENGENHARIA DE SOFTWARE

Curso Superior de Formao Especfica em Anlise de Sistemas

V.2 - PROJETO FINAL DE CURSO ....................................................................................... 42 PROVA 2 ................................................................................................................... 42

Prof. Moacir Sanglard

Curso Superior de Formao Especfica em Anlise de Sistemas

EVOLUO CARACTERSTICAS E COMPONENTES PROBLEMAS E CAUSAS DEFINIO DE ENGENHARIA DE SOFTWARE

Prof. Moacir Sanglard

Curso Superior de Formao Especfica em Anlise de Sistemas

MAIOR PODER DE COMPUTAO A CUSTO BAIXO

ASSOMBROSA QUALIDADE DE ARMAZENAMENTO E PROCESSAMENTO

O SOFTWARE O MECANISMO QUE POSSIBILITA APROVEITAR E DAR VAZO A ESSE POTENCIAL

Prof. Moacir Sanglard

Curso Superior de Formao Especfica em Anlise de Sistemas

SISTEMAS DE DESK-TOP PODEROSOS TECNOLOGIAS ORIENTADAS A OBJETOS

SISTEMAS ESPECIALISTAS REDES NEURAIS ARTIFICIAIS COMPUTAO PARALELA

ORIENTAO A BATCH DISTRIBUO LIMITADA SOFTWARE CUSTOMIZADO

MULTIUSURIO TEMPO REAL BANCO DE DADOS PRODUTOS DE SOFTWARE

INTELIGNCIA HARDWARE DE BAIXO CUSTO

Prof. Moacir Sanglard

Curso Superior de Formao Especfica em Anlise de Sistemas

Prof. Moacir Sanglard

Curso Superior de Formao Especfica em Anlise de Sistemas

Prof. Moacir Sanglard

Curso Superior de Formao Especfica em Anlise de Sistemas

Prof. Moacir Sanglard

Curso Superior de Formao Especfica em Anlise de Sistemas

Prof. Moacir Sanglard

Curso Superior de Formao Especfica em Anlise de Sistemas

Prof. Moacir Sanglard

Curso Superior de Formao Especfica em Anlise de Sistemas

Prof. Moacir Sanglard

Curso Superior de Formao Especfica em Anlise de Sistemas

CICLO CLSSICO DA ENGENHARIA DE SOFTWARE

Prof. Moacir Sanglard

Curso Superior de Formao Especfica em Anlise de Sistemas

4 Implementao (ou Construo)

Prof. Moacir Sanglard

Curso Superior de Formao Especfica em Anlise de Sistemas

MODELOS DE PROCESSO DE DESENVOLVIMENTO DE SOFTWARE

Definio e anlise de requisitos

Prof. Moacir Sanglard

Curso Superior de Formao Especfica em Anlise de Sistemas

Coleta e refinamento dos requisitos

Engenharia do Produto Construo do Prottipo Refinamento do Produto

Avaliao do Prottipo pelo Cliente

Prof. Moacir Sanglard

Curso Superior de Formao Especfica em Anlise de Sistemas

Determ ine ob jectiv es alternatives and cons traint s

Ev aluate alt ern atives id en tify, resol ve risk s

Operati onal prot oyp e

R EVIEW Requi rement s pl an Li fe-cycle pl an

Develop ment pl an Integrati on and t est p lan

P lan next p has e

Requi rement valid ati on

Prof. Moacir Sanglard

Curso Superior de Formao Especfica em Anlise de Sistemas

TCNICAS DE QUARTA GERAO

C de oleta requisitos Estratgia de projeto Im entao plem usando 4G L Testes

Prof. Moacir Sanglard

Curso Superior de Formao Especfica em Anlise de Sistemas

OBTENO PRELIMINAR DOS REQUISITOS

PROJETO PROTOTIPAO ENSIMA ITERAO CODIFICAO 4GT