apostilha es2003
DESCRIPTION
Apostilha de apostilha e s em 2003TRANSCRIPT
-
ENGENHARIA DE SOFTWARE
Rosario Girardi
UFMA
2002
-
Engenharia de Software Prof. Rosrio Girardi
2
Tabela de contedo
CAPTULO 1 - INTRODUO ENGENHARIA DE SOFTWARE 7
1.1 ALGUMAS DEFINIES 7 1.2 OBJETIVOS DA ENGENHARIA DE SOFTWARE 7 1.3 A IMPORTNCIA DO SOFTW ARE 7 1.4 O QU O SOFTWARE? 8 1.5 SISTEMA DE COMPUTAO 8 1.5.1 ELEMENTOS DE UM SC 8 1.5.2 EVOLUO DOS SISTEMAS DE COMPUTAO 9 1.5.3 EVOLUO NAS MODALIDADES DE PROCESSAMENTO DA INFORMAO 11 1.5.3.1 Processamento centralizado 11 1.5.3.2 Processamento distribudo 12 1.6 ELEMENTOS DA ENGENHARIA DE SOFTWARE 13 1.7 DETERIORO DO HARDWARE VS SOFTWARE 14 1.8 TIPOS DE SOFTWARE 15 1.9 A CRISE DO SOFTWARE 16 1.10 PROBLEMAS DO DESENVOLVIMENTO DE SOFTWARE 17
CAPTULO 2 - MODELOS DE DESENVOLVIMENTO 18
2.1 O CICLO DE VIDA EM CASCATA 18 2.1.1 ANLISE U ENGENHARIA DE SISTEMAS 18 2.1.2 ANLISE DE REQUERIMENTOS DO SOFTWARE 19 2.1.3 PROJETO 19 2.1.4 CODIFICAO 19 2.1.5 PROVA 20 2.1.6 INTEGRAO 20 2.1.7 MANUTENO 20 2.2 CRTICAS AO CICLO DE VIDA EM CASCATA 21 2.3 CONTRIBUIES DO CICL O DE VIDA EM CASCATA 22 2.4 PARADIGMA DA PROTOTI PAO 22 2.4.1 QUANDO APLICA-LHO 23 2.4.2 VANTAGENS DA PROTOTIPAO 23 2.4.3 PROBLEMAS DA PROTOTIPAO 23 2.5 TCNICAS DA QUARTA GERAO 24 2.6 MODELO EM ESPIRAL 24 2.7 MTODOS, METODOLOGIAS E FERRA MENTAS DE DESENVOLVIMENTO 25 2.8 ENGENHARIA DE SOFTWARE BASEADA NA REUTILI ZAO 25 2.9 FERRAMENTAS CASE 26 2.10 GROUPWARE 26 2.11 VISO GENRICA DO PROCESSO DE DESENVOLVIMENTO DO SOFTWARE 26 2.11.1 DEFINIO 27
-
Engenharia de Software Prof. Rosrio Girardi
3
2.11.2 DESENVOLVIMENTO 27 2.11.3 MANUTENO 28
CAPTULO 3 - ENGENHARIA DE SISTEM AS 29
3.1 TAREFAS DA ENGENHARIA DE SISTEMAS 29 3.1.1 IDENTIFICAO DAS NECESSIDADES DO CLIENTE E DEFINIO DE OBJETIVOS 29 3.1.2 ESTUDO DE VIABILIDADE 30
CAPTULO 4 - ENGENHARIA DE REQUISITOS 32
4.1 PRINCIPAIS CONCEITOS 32 4.2 TIPOS DE REQUISITOS 32 4.3 PROBLEMA S DOS REQUISITOS 33 4.4 E.R. MOTIVAO 33 4.5 QUESTES MAIS FREQENTEMENTE PERGUNTADAS SOBRE REQUISITOS (FAQS) 34 4.6 A ENGENHARIA DE REQUIS ITOS E AS OUTRAS FASES DO CICLO DE DESENVOLVIMENTO 35 4.7 FUNDAMENTOS DA ANLISE DE REQUISITOS 36 4.8 TAREFAS DA ANLISE DE REQUISITOS 37 4.8.1 RECONHECIMENTO DO PROBLEMA 37 4.8.2 COMPREENSO E REPRESENTAO DE DOMNIO 38 4.8.2.1 O domnio da informao 38 4.9 PRINCPIOS DA ANLISE DE REQUISITOS 39 4.9.1 DECOMPOSIO DO PROBLEMA 39 4.9.2 VISES LGICAS E FSICAS DOS REQUISITOS 40 4.10 A ESPECIFICAO DE REQ UISITOS 40 4.10.1 PROPRIEDADES EMERGENTES 41 4.10.2 USURIOS DO DOCUMENTO DE REQUISITOS 41 4.10.3 A ESTRUTURA DO DOCUMENTO DE REQUISITOS 42 4.10.3.1 Adaptando um padro 43 4.11 CONSTRUO DE PROTTIPOS 44 4.11.1 PARADIGMA DA PROTOTIPAO 45 4.12 ROTEIRO PARA A ESPECI FICAO DE REQUISITO S 45 4.13 MTODOS PARA A ANLISE DE REQUISITOS 46 4.13.1 CLASSIFICAO DOS MTODOS PARA A ANLISE DE REQUISITOS 46
CAPTULO 5 - INTERAO HUMANA - COMPUTADOR 47
5.1 CONCEITOS BSICOS 47 5.1.1 IMPORTNCIA DA HCI 47 5.1.2 REAS DE APLICAO 48 5.1.3 INTERFACE USURIO 48 5.1.4 FATORES HUMANOS 48 5.1.5 METFORAS 49
-
Engenharia de Software Prof. Rosrio Girardi
4
5.1.6 HIPERTEXTO 49 5.1.7 ORIGENS 49 5.1.7.1 Psicologia cognitiva 50 5.2 EVOLUO 51 5.3 REQUERIMENTOS DE UMA INTERFACE 53 5.3.1 REQUERIMENTOS DE UMA GUI 53 5.4 O SOM NA INTERAO 54 5.4.1 SISTEMAS DE RECONHECIMENTO DE VOZ 54 5.4.1.1 Sintetizadores da fala 55 5.5 PERCEPO NA INTERA O 55 5.5.1 PERCEPO VISUAL 55
CAPTULO 6 - O PROJETO DE SOFTWAR E 57
6.1 MODULARIDADE 58 6.2 FASES DO PROJETO DE SOFTWARE 58 6.2.1 O PROJETO GLOBAL 59 6.2.1.1 Diagramas de estrutura 59 6.3 TCNICAS DE PROJETO 60 6.3.1 PROJETO ESTRUTURADO 61 6.3.1.1 Mtodo do projeto estruturado 61 6.3.2 PROJETO DETALHADO 64
CAPTULO 7 - GERENCIAMENTO E PLAN EJAMENTO DE PROJETOS DE SOFTWARE 66
7.1 INTRODUO 66 7.2 FUNDAMENTOS DOS PROJETOS 66 7.2.1 COMO CONDUZIR UM PROJETO DE SOFTWARE? 67 7.2.2 COMO INICIAR UM PROJETO DE SOFTWARE? 68 7.2.3 O QUE CONSIDERAR NO PLANEJAMENTO DE PROJETO DE SOFTWARE? 68 7.2.4 OS ASPECTOS COMUNS QUE DEVEM SER CONSIDERADOS NAS TCNICAS ADMINISTRATIVAS: 69 7.2.5 PREVISO DE RISCOS 69 7.2.6 DETERMINAO DOS PRAZOS 70 7.2.7 MONITORAO E CONTROLE 70 7.3 MEDIDAS DE SOFTWARE 70 7.3.1 MTRICAS ORIENTADAS AO TAMANHO. 73 7.3.2 MTRICAS ORIENTADAS FUNO. 73 7.3.3 MTRICAS DE QUALIDADE 74 7.3.4 FATORES QUE INFLUENCIAM A PRODUTIVIDADE DO SOFTWARE 75 7.4 O PLANEJAMENTO DE SOFT WARE 76 7.4.1 PORQUE PLANIFICAR? 76 7.4.2 QUANDO PLANIFICAR? 76 7.4.3 FATORES QUE AFETAM A PRECISO E A EFICCIA DAS ESTIMAES 76
-
Engenharia de Software Prof. Rosrio Girardi
5
7.4.4 UMA GUIA PARA A PLANIFICAO 76 7.4.4.1 Escopo do software 77 7.4.5 ESTIMAO DE RECURSOS 77
CAPTULO 8 - A REUTILIZAO DE SO FTWARE 79
8.1 CONCEITOS BSICOS 79 8.1.1 PROBLEMAS DO DESENVOLVIMENTO DE SOFTWARE 79 8.1.2 QUALIDADE E PRODUTIVIDADE ATRAVS DA REUTILIZAO 79 8.1.3 PROBLEMAS ATUAIS DA REUTILIZAO 80 8.1.4 O DESENVOLVIMENTO ORIENTADO A OBJETOS E A REUTILIZAO 80 8.1.5 EFETIVIDADE DA RECUPERAO DE SOFTWARE 80 8.1.6 CUSTO DA CLASSIFICAO DE SOFTWARE 81 8.1.7 LINGUAGEM NATURAL PARA CONSULTAS E CLASSIFICAO 81 8.1.8 REUSABILIDADE 82 8.1.9 REUTILIZAO VS. MIGRAO 82 8.1.10 ALGUMAS DEFINIES 82 8.1.11 QUE REUTILIZAR? 83 8.1.12 ARTEFATOS REUTILIZVEIS 83 8.1.13 TCNICAS 83 8.1.14 ALCANCE 83 8.1.15 MODALIDADES 84 8.2 EVOLUO 84 8.2.1 EVOLUO NA PRTICA DA REUTILIZAO 84 8.3 O DESENVOLVIMENTO DE SOFTWARE BASEADO NA REUTILIZAO 85 8.3.1 DESENVOLVIMENTO PARA REUTILIZAO 85 8.3.2 QUALIFICAO E GENERALIZAO 86 8.3.2.1 Classificao 86 8.3.2.2 Evoluo dos repositrios 87 8.3.3 DESENVOLVIMENTO COM REUTILIZAO 87 8.3.3.1 Recuperao 87 x vnculos hipertexto ou hipermdia 88 8.3.3.2 Recuperao 88 8.3.3.3 Adaptao 88 8.3.3.4 Composio 88 8.4 ABSTRAES DE SOFTWARE PARA A REUTILIZA O 89 8.4.1 QUE UMA ABSTRAO DE SOFTWARE? 89 8.4.2 PARTES DE UMA ABSTRAO 90 8.5 EFETIVIDADE DAS TCNICAS DE REUTILIZAO 91 8.5.1 CRITRIOS PARA MEDIR A EFETIVIDADE 91 8.5.1.1 Distancia cognitiva 91 8.5.2 ANALISE DE EFETIVIDADE DAS TCNICAS DE REUTILIZAO 92 8.5.2.1 Linguagens de alto nvel 92 8.5.2.2 Reutilizao informal de cdigo e projeto 93 8.5.2.3 Componentes de cdigo 93 8.5.2.4 Paradigma de orientao a objetos 94
-
Engenharia de Software Prof. Rosrio Girardi
6
8.5.2.5 Esquemas de software 96 8.5.2.6 Geradores de aplicaes 97 8.5.2.7 Linguagens de muito alto nvel (VHLL) 98 8.5.2.8 Sistemas de transformao 99 8.5.2.9 Arquiteturas 100
-
Engenharia de Software Prof. Rosrio Girardi
7
Captulo 1 - Introduo Engenharia de Software
A Engenharia de software a disciplina que estuda tcnicas para o desenvolvimento e manuteno de software de baixo custo; confivel; de fcil manuteno.
Surge como resposta crise de software.
Estas tcnicas tratam ao software como um produto de Engenharia que requer planejamento, anlise, projeto, implementao, prova e manuteno.
1.1 Algumas definies
O estabelecimento e uso de princpios de Engenharia robustos, orientados a obter de forma econmica software confavel e que funcione eficientemente sobre mquinas reais (Fritz Bauer, 1969)
Disciplina tecnolgica e administrativa dedicada a produo sistemtica de produtos de programao, que so desenvolvidos e modificados a tempo e dentro de um oramento definido (R Fairley, 1985)
1.2 Objetivos da Engenharia de Software
Incrementar a produtividade no desenvolvimento e manuteno dos SC
Melhorar a qualidade
Diminuir os custos de desenvolvimento e manuteno
1.3 A importncia do software
O software tm superado ao hardware como elemento chave do sucesso de empresas, produtos e sistemas. A suficincia e oportunidade da informao dada pelo software diferencia uma empresa de seus competidores.
Nas dcadas de 1950-1980 o principal problema era desenvolver hardware de forma a reduzir o custo de processamento e armazenamento de dados
Desde os 80, os avanos em microelectrnica permitiram reduzir os custos de hardware e proporcionar maior potncia de clculo.
-
Engenharia de Software Prof. Rosrio Girardi
8
Hoje, os problemas esto centrados em reduzir custos de desenvolvimento e manuteno e melhorar a qualidade do software.
1.4 O qu o software?
SOFTWARE = PROGRAMAS (instrues) + ESTRUCTURAS DE DATOS + ESPECIF ICACOES + MANUAIS DE USO
As instrues, quando se executam, subministram o comportamento esperado do sistema. As estruturas de dados armazenam a informao que os programas manipulam. Os manuais descrevem a operao e o uso dos programas. As especificaes descrevem os software nas diferentes fases de desenvolvimento (anlise, projeto e implementao).
O software composto por dos tipos de componentes: componentes no executveis, como especificaes de requerimentos e de projeto e componentes executveis, como o cdigo de um programa.
1.5 Sistema de computao
Um sistemas de computao um conjunto de elementos organizados para levar a cabo algum mtodo, procedimento ou controle atravs do processamento da informao.
1.5.1 Elementos de um SC
Os elementos de um sistemas de computao so:
Software: Produtos do ciclo de desenvolvimento utilizados para realizar o mtodo, procedimento ou controle requerido (especificaes de requisitos, especificaes de projeto, programas, casos de prova)
Hardware: Dispositivos eletrnicos que proporcionam a capacidade de processamento para a execuo dos mtodos (processador, memria RAM, disco rgido)
Pessoas: Indivduos (Usurios, Clientes, Operadores de hardware e software)
Bases de dados: Conjunto grande e organizado de informao ao qual se acessa pelo software e que uma parte integral do funcionamento do sistema
-
Engenharia de Software Prof. Rosrio Girardi
9
Documentao: Manuais e outra informao que explica o uso e a operao do sistema
Procedimentos: Os passos que definem o uso especfico de cada elemento do sistema
1.5.2 Evoluo dos sistemas de computao
Podemos distinguir trs eras em relao evoluo dos sistemas informticos:
(1950-1965) Primeira era
Caraterizada pelos sistemas batch
A maior parte do hardware se dedicava execuo de um nico programa por vez.
O desenvolvimento do software era um processo artesanal. O software era projetado a medida para cada problema e tinha uma distribuio relativamente pequena: para cada problema e para cada cliente.
O desenvolvimento dos sistemas estava personalizado. A mesma pessoa programava, executava, depurava e mantenha. O projeto era um processo implcito, executado na cabea de algum. Como documentao no existia e a mobilidade no trabalho baixa se esperava que a pessoa estaria l quando se encontrara algum erro
(1965-1975) Segunda era
Surge o uso de software como produto, Aparecem as primeiras software houses e comea a se organizar a industria do software.
Comea a distribuio de programas a mltiplas clientes
Nesta poca comearam problemas com a manuteno do software devido correes por falhas o por cmbios nos requerimentos do usurio.
Como conseqncia do desenvolvimento artesanal personalizado surgem grandes dificuldades para manuteno corretiva e evolutiva e o esforo dedicado manuteno do software comeou a absorver recursos de forma alarmante.
Os sistemas informticos de esta era foram sistemas multiusuarios, aparece a multiprogramaao, o seja vrios programas podem executar-se simultaneamente na mesma mquina.-
Por outro lado, o desenvolvimento personalizado de grande parte do software fazia com que muitos programas fossam impossveis de serem mantidos.
-
Engenharia de Software Prof. Rosrio Girardi
10
Isto deu origem crise do software.-
A diminuio de custos dos dispositivos de armazenamento em disco permitiu desenvolver SGDB (Sistemas de gerncia de bases de dados)
Comeam a surgir novas modalidades de interao homem-computador, como as interfaces de comando
Como conseqncia disso, as aplicaes de software se tornam cada vez mais sofisticadas
Nesta era tambm comea a se desenvolver a capacidade de comunicao de dados. Aparecem os sistemas de teleprocessamento. Estes sistemas possuem 3 funes combinadas:
processamento de software aplicativo
processamento das BD
processamento da rede de comunicao (controle das interfaces entre os componentes do ST e da transferencia da informao)
O crescimento nos sistemas de teleprocessamento comea a provocar sobrecarga do processador central por incremento funcional. Surgem os processadores de comunicaes e de BD independentes.
(75-90) Terceira era
Era caraterizada pelo grande desenvolvimento das redes de comunicao de dados. Surgem as redes de comunicao locais e de longa distancia
A demanda de acesso instantneo a os dados cada vez maior.
Surgem os sistemas distribudos onde vrios computadoras executam funciones concorrentemente, se comunicam entre si e compartem recursos (memria, dispositivos de E/S)
Os avanos na Microeletronica levam ao desenvolvimento do computadoras pessoais (PC), onde se verifica uma grande reduo da relao preo/capacidade de processamento.
A diminuio dos custos do hardware faz aumentar a demanda de software em novas reas
Se produz um crescimento das software houses e da distribuio no nmero de seus produtos
Os sistemas informticos se tornam cada vez mais complexos.
-
Engenharia de Software Prof. Rosrio Girardi
11
So propostos mtodos e ferramentas avanadas para o desenvolvimento de software.
Nesta era, a crise de software se mantm
Desde 90 Quarta era, atual
Caraterizada por:
incremento exponencial no desenvolvimento de sistemas Web
crescimento na complexidade das aplicaes
sistemas distribudos
sistemas de controle
Reutilizao e desenvolvimento orientado a objetos
objeto como abstrao de software
Novas reas de aplicao: educao, comercio eletrnico, jogos, aplicaes domsticas
Tendncias: sistemas baseados em conhecimento, agente como abstrao de software, automao do processo de desenvolvimento de software
1.5.3 Evoluo nas modalidades de processamento da informao
Os sistemas de processamento da informao tem evolucionado de sistemas de processamento centralizado sistemas de processamento distribudo.
1.5.3.1 Processamento centralizado
Nesta modalidade de processamento, vrias mquinas com capacidade de processamento so reunidas em um nico local
Os fatores contribuintes para esta modalidade de processamento tem sido:
Centralizao das atividades num nico local para otimizar (codificao, entrada, processamento e sada)
Primeiros SGBD - Dados centralizados
Economia de escala: Concentrao justificada pela necessidade de dividir custos entre mltiplas aplicaes (instalao, operao, manuteno)
-
Engenharia de Software Prof. Rosrio Girardi
12
Importncia do CPD
Centralizao reforava a influencia do CPD na empresa
Administradores do CPD
administradores da informao da empresa
centros de poder
O processamento centralizado apresentava os seguintes problemas:
Software de controle - maior parte do tempo de processamento
Congestionamento do software aplicativo
Interrupo no processamento - paralisao de atividades
Saturao de determinada tecnologia
Saturao de recursos do sistema centralizado por incremento na complexidade das aplicaes multiusurio
Na medida que o sistema utilizado por mais usurios, aumenta sua saturao
Novas Tecnologias substituem Tecnologias que j alcanaram seu ponto de saturao
As limitaes do processamento centralizado foram a justificativa econmica para a distribuio:
micros, minicomputadores e mainframes
distinguir de descentralizao
processamento e dados localizados em diferentes centros sem integrao
redundncia de atividades
aumento dos custos
1.5.3.2 Processamento distribudo
O principal fator contribuinte para o processamento distribudo foi o desenvolvimento das telecomunicaes:
-
Engenharia de Software Prof. Rosrio Girardi
13
Substituio de transferencia fsica de dados (papel) por teleprocessamento
Usurio - funes de entrada de dados e consulta de dados armazenados
terminais locais ligadas diretamente ao computador central
terminais remotas ligadas atravs de redes locais ou de longa distancia
Os componentes de um sistema distribudo so:
Processamento - Existem vrios processadores
Dados - compartilhados em diferentes ns com capacidade de processamento
Controle - componente fundamental, mais complexo que nos sistemas centralizados; Faz a coordenao de diferentes processos a travs da troca de mensagens
Os seguintes critrios de distribuio so geralmente utilizados:
reas geogrficas
Distribuio geogrfica dos dados
Dados distribudos e agrupados segundo freqncias de acesso de cada rea
Minimizao do trfego inter-ns
Grupos funcionais
Assinao de capacidade de processamento por departamento funcional
Funes do PD
Servidores especializados( De e-mail, De impresso,Com software especializado)
1.6 Elementos da Engenharia de Software
Modelos de desenvolvimento
Ciclo de vida
Mtodos e tcnicas - Indicam como construir o software (Estruturadas, orientadas a objetos, baseadas em agentes)
-
Engenharia de Software Prof. Rosrio Girardi
14
Procedimentos - definem a seqncia de aplicao dos mtodos
Metodologias - conjunto sistematizado de tcnicas para a ser aplicado em uma, varias ou todas as fases do ciclo de desenvolvimento de um produto de software
Ferramentas - Aplicaes de software que do suporte automtico ou semi-automtico a mtodos ou metodologias para o desenvolvimento de software
Ambientes de desenvolvimento
1.7 Deterioro do hardware vs software
O software se deteriora de forma diferente ao hardware. O hardware exibe poucas falhas ao comeo de sua vida e essas falhas so geralmente atribuveis a defeitos de projeto e fabricao (mortalidade infantil). Quando se corrigem os defeitos, as falhas caem a sua nvel ms baixo e permanecem estacionrios durante certo perodo de tempo. Conforme passa o tempo falhas voltam a apresentar-se a medida que os componentes de hardware sofrem os efeitos cumulativos de sujeira, vibrao, uso, etc .(Figura 1).
mortalidade infantil
deterioro
Figura 1- Deterioro do hardware vs Software - falhas do hardware
O software no susceptvel aos males do entorno como o hardware. Defeitos no descobertos faro que falhe durante as primeiras etapas de sua vida. Uma vez corrigidos, supondo que no se introduzem novos errores, a curva se aplanaria
O software se deteriora devido cmbios (manuteno) atravs dos quais se introduzam novos erros (defeitos). A curva de falhas tem picos. Antes que a curva volte ao estado estacionrio original, se solicita outro cambio, fazendo que de novo se crie outro pico e lentamente, o software vai-se deteriorando devido a os cmbios ( Figura 2).
-
Engenharia de Software Prof. Rosrio Girardi
15
Curva idealizada
Curva real
cambio
Figura 2 - Deterioro do hardware vs Software - falhas do software
1.8 Tipos de software
Software de sistemas
Aplicao de software - Executa tarefas especficas num domnio de problema Ex. Folhas de pagamento, Controle de estoque
Software de tempo real - mede, analisa e/o controla sucessos do mundo real na medida que ocorrem. Distinguir entre software de tempo real e software interativo. Um sistema de tempo real deve responder dentro de limites estritos de tempo. O tempo de resposta em um sistema interativo pode ser superado sem que se produza nenhum desastre.
Software de gesto o sistemas de informao: aplicaes para o processo de informao comercia e administrativa Constituem a maior rea de aplicao do software
Software cientfico: baseado na utilizao de algoritmos de clculo e anlise numrico (projeto assistido por computador, simulao de sistemas)
Software de PC: Processadores de palavra, planilhas eletrnicas, grficos, jogos, aplicaes educativas, financeiras e comerciais
Software de Web - Agentes e robots buscadores, aplicaes de comercio eletrnico, educativas, jogos, etc
Software de IA - aplicaes baseadas no conhecimento, incorporam mecanismos de raciocnio, cooperam e aprendem (ex.agentes inteligentes, sistemas expertos) Fazem uso de algoritmos no numricos (processamento simblico) para a resoluo de problemas complexos Reconhecimento de voz, processamento de linguagem natural, jogos, prova de teoremas)
-
Engenharia de Software Prof. Rosrio Girardi
16
1.9 A crise do software
Carateriza os problemas de desenvolvimento e manuteno do software:
Demanda crescente de software
Problemas na manuteno de software
falta de documentao
no aplicao de adequadas metodologias de desenvolvimento
quantidade e qualidade
desproporo entre os custos do hardware e o software
custo do software atualmente o elemento principal na distribuio de custos de um sistema informtico
crescimento em complexidade e domnios de aplicao
planejamento e estimao de custos geralmente muito pouco precisa
Geralmente os custos estimados so superados em ordenes de magnitude (de meses a anos)
formao de pessoal qualificado
falta de metodologias e ferramentas adequadas as novas aplicaes
a comunicao entre o que desenvolve o software e o usurio no , adequada
os requisitos do cliente so expressados de maneira vaga o pouco precisa
freqentemente o cliente fica insatisfeito com o sistema final
qualidade do software questionvel
recentemente tem comeado a praticar-se a prova sistemtica e completa do software
cmbios muito rpidos nos ambientes dos SC
Qual a soluo?
Dar um enfoque de Engenharia ao desenvolvimento de software
-
Engenharia de Software Prof. Rosrio Girardi
17
Melhorar as tcnicas e ferramentas existentes
Promover o desenvolvimento para e com reutilizao
1.10 Problemas do desenvolvimento de software
Crescimento da demanda de software
Novos domnios de aplicao
Complexidade das aplicaes
Custo da manuteno de software
Confiabilidade do software
Mudanas nos requisitos das aplicaes
Problemas na aquisio e especificao de requisitos
A crise de software se mantm. Avanos na ES provocam maior demanda em reas mais complexas.
-
Engenharia de Software Prof. Rosrio Girardi
18
Captulo 2 - Modelos de Desenvolvimento
Um modelo de desenvolvimento estabelece as fases do ciclo de vida que atravessa um produto de software durante seu desenvolvimento e manuteno e os passos donde se aplicaro tcnicas, ferramentas e procedimentos
A escolha de um paradigma depende de:
a natureza da aplicao
os mtodos e ferramentas a utilizar
os controles e entregas requeridos
Enfatizam as primeiras fases do ciclo de desenvolvimento
requisito
projeto
mais produtivo e efetivo fazer mudanas nas especificaes de requisitos e projeto que mudar e provar o cdigo fonte
Os principais modelos de ciclo de vida so:
Ciclo de vida clssico (modelo em cascata)
Paradigma da prototipao
Ciclo de vida em espiral
Paradigma dos linguagens de quarta gerao
Combinao de paradigmas
2.1 O ciclo de vida em cascata
2.1.1 Anlise u Engenharia de sistemas
Definio dos requerimentos de todos os elementos do sistema
hardware
-
Engenharia de Software Prof. Rosrio Girardi
19
software
pessoas
instalaes
Atribuio de parte de esses requerimentos ao software
2.1.2 Anlise de requerimentos do software
Compreenso do domnio da aplicao e especificao do problema do mundo real
Compreenso e especificao de
Funciones requeridas
Rendimentos
Interfaces
Produto: especificao de requisitos
2.1.3 Projeto
soluo computacional aos requerimentos estabelecidos
os requisitos so representados numa linguagem do mundo computacional
Produtos
A arquitetura do software (projeto global)
Estruturas de dados (projeto detalhado)
Detalhe dos procedimentos (projeto detalhado)
2.1.4 Codificao
representaes do projeto so traduzidas a um linguagem artificial (linguagem de programa convencional o de 4ta Gerao)
o resultado um conjunto de instrues executveis
Produto
-
Engenharia de Software Prof. Rosrio Girardi
20
um o mais programas
2.1.5 Prova
software provado para detectar os defeitos que possam existir na implementao
Prova se enfoca em
A lgica interna dos programas
As funciones externas atribuindo que para determinadas entradas se produziro os resultados requeridos
Produto
casos de prova (entradas e resultados esperados)
2.1.6 Integrao
os programas provados so integrados para compor o software aplicativo ou de sistema
Produto: aplicao de software
2.1.7 Manuteno
software sofre cmbios depois de que entregue ao cliente
cmbios ocorrem por:
erros do software
Cambio no entorno externo do software
Requerimentos de novas funciones o rendimento
As fases e produtos da manuteno so as mesmas que para o desenvolvimento
-
Engenharia de Software Prof. Rosrio Girardi
21
Engenharia desistemas
Codificao
Integraoe prova
Manuteno
Projeto
Engenharia de requisitos
Figura 3 - Ciclo de vida clssico ("cascata")
2.2 Crticas ao ciclo de vida em cascata
os projetos reais raramente seguem o fluxo seqencial (e top-down)que prope o modelo
combinao de top-down e bottom-up
sempre ocorrem interaes e a vezes existem problemas na aplicao do paradigma
difcil tanto para o cliente como para o analista estabelecer ao principio, explicitamente, todos os requerimentos
ciclo de vida clssico tem dificultadas em expressar possveis incertezas
muita pacincia do cliente
a verso funcionando da aplicao somente estar disponvel nas etapas finais do desenvolvimento do projeto
presena de erros nos requerimentos estabelecidos, nas etapas finais, pode ser uma situao grave
erros durante a especificao de requerimentos o cmbios nos requerimentos durante o desenvolvimento
-
Engenharia de Software Prof. Rosrio Girardi
22
produto gerado no atender adequadamente as necessidades do cliente
2.3 Contribuies do ciclo de vida em cascata
Enfoque sistemtico e seqencial do desenvolvimento de software
Desenvolvimento dividido em fases bem definidas
As atividades so executadas de forma iterativa e o refinamento permitido
2.4 Paradigma da prototipao
prottipo
verso do SC que contm as caractersticas bsicas do sistema final
pode utilizar-se somente para fines de experimentao o pode evolucionar a travs de sucessivos prottipos que incrementam a funcionalidade do sistema
PROTOTIPOCONSTRUIDOexperimentalsistema finalConstruo
do prottipo
Usar e avaliar o prottipo
Prottipo satisfatorio?
Projetorpido
Engenharia de requisitos
NAO
Figura 4 - Ciclo de vida baseado na prototipao
-
Engenharia de Software Prof. Rosrio Girardi
23
2.4.1 Quando aplica-lho
Quando os requerimentos da aplicao mudam rapidamente, porque o entorno da aplicao muda
Quando os requerimentos do usurio no so bem entendidos o no podem ser totalmente definidos em uma primeira etapa
Como mtodo para captar o especificar claramente os requerimentos
o prottipo a prpria especificao de requisitos
Quando existem problemas de comunicao entre o cliente e o analista
prottipo possibilita a comunicao e permite medir a satisfao do cliente com relao ao produto
Para experimentar a interface com o usurio
Para avaliar experimentalmente funciones o eficincia de um algoritmo
2.4.2 Vantagens da prototipao
prottipo real: da ao usurio e ao analista uma forma tangvel de compreenso e avaliao do problema permitindo uma retroalimentao de necessidades e requisitos
comum a usurios e analistas: oferece um ponto de referencia comum a usurios e analistas para a identificao de problemas e necessidades-
estimula a participao do usurio no projeto: melhora a comunicao
2.4.3 Problemas da prototipao
Na administrao e controle do projeto
dificuldade para planificar, estimar custos e controlar os prottipos
Pode gerar expectativas difceis de atingir
Ex.. O usurio pode pressionar para liberar o prottipo como sistema final
-
Engenharia de Software Prof. Rosrio Girardi
24
2.5 Tcnicas da quarta gerao
Geradores de aplicaes
Se orientam habilidade de especificar software em linguagem de alto nvel (prximo ao linguagem natural)
A partir da especificao a ferramenta gera automaticamente o cdigo fonte
Disponvel somente para domnio de aplicaes especficas
A curva de aprendizagem alta
Problemas de eficincia por grandes quantidades de dados
Redues importantes no tempo de desenvolvimento
Melhora na produtividade
A manuteno realizada na prpria especificao
Implementaousando L4G
Aplicao
Estrategia de projeto
Engenharia de requisitos
Figura 5 - Ciclo de vida para L4G
2.6 Modelo em espiral
Integra a prototipacao com o modelo em cascata
Anlise de requisitos, projeto e codificao so executados ciclicamente
Exemplifica a programao evolucionaria
-
Engenharia de Software Prof. Rosrio Girardi
25
Figura 6 - Ciclo de vida em espiral
2.7 Mtodos, metodologias e ferramentas de desenvolvimento
Desenvolvimento orientado a objetos
Ferramentas CASE
Desenvolvimento formal de software
Desenvolvimento baseado em Agentes
Engenharia de Software baseada na Reutilizao
Desenvolvimento PARA reutilizao
Desenvolvimento COM reutilizao
2.8 Engenharia de software baseada na reutilizao
DOO
Reuso em caixa preta (ex.. Instanciao)
Reuso em caixa branca, por especializao (ex. Herana)
Reuso de projetos (padres de projeto e arquiteturas)
-
Engenharia de Software Prof. Rosrio Girardi
26
Reuso de componentes de cdigo
2.9 Ferramentas CASE
Automatizam partes do processo de desenvolvimento
gerao automtica de cdigo
linguagens de quarta gerao
modelagem de requisitos (ex. DFD)
especificao e verificao formal de software (ex. Redes de Petri)
Groupware
2.10 Groupware
Trabalho em grupo no desenvolvimento de software assistido por computador
Necessrio para o desenvolvimento de grandes aplicaes
Ferramentas
tormenta de idias (brainstorming)
planificao
resoluo de conflitos
inspeo de software
2.11 Viso genrica do processo de desenvolvimento do software
trs fases genricas, independentemente do paradigma escolhido
-
Engenharia de Software Prof. Rosrio Girardi
27
Manuteno
Desenvolvimento
Definio
Figura 7 - Viso genrica do processo de desenvolvimento de software
2.11.1 Definio
O qu
Qu informao se processa
Qu funo e rendimento se deseja
Qu qual ser a interface com o usurio
Qu critrios de avaliao se utilizaro para provar a correo do sistema
Fases
Anlise do sistema
Planejamento
Anlise de requerimentos
2.11.2 Desenvolvimento
O como
Como se projetaro as estruturas de dados
Como se projetara a arquitetura do software
Como se detalham os procedimentos
Fases
-
Engenharia de Software Prof. Rosrio Girardi
28
projeto
Codificao
Prova
2.11.3 Manuteno
Cmbios que necessrios introduzir ao sistema por:
manuteno corretiva: correo de defeitos do software
migrao: adaptao por cmbios do entorno do sistema (por ex. CPU, sistemas operativos)
manuteno evolutiva: incorpora novas funciones
-
Engenharia de Software Prof. Rosrio Girardi
29
Captulo 3 - Engenharia de sistemas
A partir dos objetivos e restries definidos pelo usurio so detectadas e analisadas as funes que se desejam para o sistema de computao. As funes so atribudas a um ou mais elementos do sistema.
Nesta fase desenvolvida uma especificao das funes, do rendimento, das interfaces e das restries do projeto e da estrutura da informao.
3.1 Tarefas da Engenharia de Sistemas
As principais tarefas da Anlise de Sistemas so:
Identificar as necessidades do cliente e definir objetivos;
Avaliar a viabilidade do sistema
Atribuir funes ao software, ao hardware, s pessoas, s bases de dados e a outros elementos do sistema.
Estabelecer restries de custo e tempo
Criar uma especificao do sistema que seja a base para tudo o trabalho posterior
3.1.1 Identificao das necessidades do cliente e definio de objetivos
Esta atividade geralmente conduzida atravs da realizao de entrevistas. importante distinguir entre o que o cliente realmente necessita e o que o cliente quer.
Na definio de objetivos dever considerar-se:
Que informao vai produzir o sistema;
Que informao vai se subministrar ao sistema;
Quais as funes e rendimento requerido;
Quais os requisitos de segurana a serem considerados
Nesta fase tambm preciso avaliar:
-
Engenharia de Software Prof. Rosrio Girardi
30
A tecnologia disponvel;
As restries de custos e tempo de desenvolvimento
O mercado e a competitividade (mercado potencial; produtos da competncia)
Aspetos de confiabilidade e qualidade desejada no produto a ser desenvolvido
3.1.2 Estudo de viabilidade
Todos os projetos so realizveis porm dados recursos ilimitados e tempo infinito. O estudo de viabilidade determina a realizao ou discontinuao do projeto. As limitaes podem estar dadas por recursos ou tempo disponveis.
Os estudos de viabilidade incluem:
Econmica: Avaliao do custo de desenvolvimento em relao ao beneficio que oferecera o sistema
Operativa: Avaliao do impacto da introduo do sistema na organizao
Tcnica: Avaliao da existncia de tecnologia e recursos humanos para a construo do sistema
Legal: Determinar possveis infraes que possam surgir na construo do sistema
Viabilidade econmica (Anlise de custo-beneficio)
Beneficios
Tarefas de clculo e impresso
Manuteno da informao
Consulta da informao
Anlise e simulao
Custos
Compra e aluguel de equipamentos
Acondicionamento de instalaes
-
Engenharia de Software Prof. Rosrio Girardi
31
Capital
Custos relativos ao desenvolvimento
Figura 8 - Anlise de custo-beneficio
Viabilidade operativa
Avaliao do impacto da introduo do sistema na organizao
Viabilidade tcnica
Avaliao da existncia de tecnologia e recursos humanos para a cosntruo do sistema
Viabilidade legal
Determinar possveis infraes que possam surgir com a construo do sistema
Alternativas
Avaliao de possveis alternativas para o desenvolvimento do sistema
Custos
Anos
Benefcios
CustosPonto de igualdade
Perodo de amortizao
Custos
Anos
Benefcios
CustosPonto de igualdade
Perodo de amortizao
-
Engenharia de Software Prof. Rosrio Girardi
32
Captulo 4 - Engenharia de requisitos
4.1 Principais conceitos
Os requisitos do sistema definem o que solicitado ao sistema fazer e com quais limitaes ele requisitado a operar. Por exemplo:
O sistema deve manter registro de todos os materiais da biblioteca incluindo livros, sries, jornais e revistas, fitas de vdeo e udio, relatrios, colees de transparncias, discos de computadores, e CD-ROMs.
O sistema deve permitir os usurios pesquisar atravs do ttulo, autor ou ISBN.
A interface de usurio do sistema deve ser implementada usando um browser de WWW
O sistema deve suportar pelo menos 20 transaes por segundo.
As facilidades do sistema que esto disponveis para o pblico devem ser demonstradas em 10 minutes ou menos.
4.2 Tipos de requisitos
Requisitos funcionais que definem parte da funcionalidade do sistema.
Requisitos de implementao que dizem como o sistema deve ser implementado.
Requisitos de performance que especificam a performance mnima aceitvel do sistema.
Requisitos de usabilidade que especificam o tempo mximo o aceitvel para demonstrar o uso do sistema.
Requisitos No Funcionais que dizem respeito a restries, aspectos de desempenho, interfaces com o usurio, confiabilidade, segurana, manutenabilidade, portabilidade
Requisitos Organizacionais que dizem respeito s metas da empresa, polticas estratgicas adotadas, empregados da empresa com seus respectivos objetivos; enfim toda a estrutura da organizao.
-
Engenharia de Software Prof. Rosrio Girardi
33
4.3 Problemas dos Requisitos
Os requisitos no refletirem as reais necessidades dos clientes do sistema.
Os requisitos serem inconsistentes e/ou incompletos.
O custo alto para se fazer mudanas de requisitos depois de terem sido concordados.
Existirem mal entendidos entre clientes (que apresentam os requisitos do sistema) e os engenheiros de software que desenvolvem ou mantm o sistema.
4.4 E.R. Motivao
-
Engenharia de Software Prof. Rosrio Girardi
34
Alguns aspectos jurdicos:
o documento de requisitos um acordo contratual entre clientes e fornecedores
os desenvolvedores de software tem obrigao de inquirir os requisitos dos seus clientes e informar seus usurios acerca da soluo proposta (um manual de usurios no suficiente!)
4.5 Questes mais freqentemente perguntadas sobre requisitos (FAQS)
O que so requisitos?
Uma descrio de um servio ou de uma limitao
O que a engenharia de requisitos?
O processo envolvido no desenvolvimento de requisitos de um sistema
Quanto custa a engenharia de requisitos?
Cerca de 15% dos custos do desenvolvimento do sistema.
O que o processo de engenharia de requisitos?
Um conjunto estruturado de atividades envolvidas no desenvolvimento dos requisitos do sistema
O que acontece quando os requisitos esto errados?
-
Engenharia de Software Prof. Rosrio Girardi
35
Os sistema atrasam, ficam no confiveis e no satisfazem as necessidades dos clientes.
Existe um processo de engenharia de requisitos ideal?
No - os processos precisam ser adaptados as necessidades organizacionais.
O que um documento de requisitos?
Um descrio formal dos requisitos do sistema.
O que so stakeholders do sistema?
Qualquer pessoa afetada de alguma forma pelo sistema.
Qual o relacionamento entre requisitos e projeto?
Requisitos e projeto esto interligados. Idealmente eles deveriam ser separados, mas na prtica isto impossvel.
O que gerenciamento dos requisitos?
O processo envolvido no gerenciamentovdas mudanas dos requisitos
4.6 A engenharia de requisitos e as outras fases do ciclo de desenvolvimento
ENGENHARIADE
REQUISITOS
ENGENHARIADE
SISTEMAS
PROJETO
Refinamento das atribuies realizadas
ao software
Representao da informao e funes requeridas
ENGENHARIADE
REQUISITOS
ENGENHARIADE
SISTEMAS
PROJETO
Refinamento das atribuies realizadas
ao software
Representao da informao e funes requeridas
-
Engenharia de Software Prof. Rosrio Girardi
36
Figura 9 - A Engenharia de Requisitos e o processo de desenvolvimento de
software
4.7 Fundamentos da anlise de requisitos
Os requisitos do software devem ser expressos de forma completa e consistente
um processo de
Descobrimento e
Refinamento
Participao ativa de
Analista
Usurio/cliente
Dificuldades na comunicao
M interpretao
Falta de informao
Engenharia de sistemas
Codificao
Integraoe prova
Projeto
Engenharia de requisitos
Manuteno
Especificaode requisitos
Engenharia de sistemas
Codificao
Integraoe prova
Projeto
Engenharia de requisitos
Engenharia de sistemas
Codificao
Integraoe prova
ProjetoProjeto
Engenharia de requisitos
Engenharia de requisitos
Manuteno
Especificaode requisitos
-
Engenharia de Software Prof. Rosrio Girardi
37
4.8 Tarefas da anlise de requisitos
Reconhecimento do problema
Compreenso e representao de domnio
Especificao dos requisitos
Reviso
4.8.1 Reconhecimento do problema
Figura 10 - Canais de comunicao
Caratersticas ideais de um analista:
o Capacidade de abstrao
o Habilidade para compreender e organizar logicamente conceitos abstratos
o sintetizar solues a partir deles
o Habilidade para captura conceitos de fonte conflituosa ou confusas
o Habilidade de comunicao verbal e escrita
o Conhecimento dos modelos de desenvolvimento
CLIENTE/USURIOEQUIPE
DE DESENVOLVIMENTO
ANALISTA
ConsultaPergunta
Plano do projeto Especificao de requisitos
EspecificaProjeta em alto nvel
ConsultaModifica
ElaboraConsulta
Prottipo
Constri
CLIENTE/USURIOEQUIPE
DE DESENVOLVIMENTO
ANALISTA
ConsultaPergunta
Plano do projeto Especificao de requisitos
EspecificaProjeta em alto nvel
ConsultaModifica
ElaboraConsulta
Prottipo
Constri
-
Engenharia de Software Prof. Rosrio Girardi
38
4.8.2 Compreenso e representao de domnio
o funes
o fluxo de informao
o interface usurio
Deve compreender-se e representar-se o domnio da aplicao
o domnio da informao
o domnio funcional
O problema deve decompor-se de forma que os detalhes se descubram de forma progressiva
Devem especificar-se as representaes lgicas e fsicas
4.8.2.1 O domnio da informao
o Fluxo
o Contedo
o Estrutura
4.8.2.1.1 Fluxo da informao
Figura 11 -Fluxo da informao
4.8.2.1.2 Contedo da informao
REGISTRO EMPREGADO
Dados de
entradaTransformao 1 Transformao 2
Dados intermedirios
Dados de
sada
Armazm de dados
Dados de
entradaTransformao 1 Transformao 2
Dados intermedirios
Dados de
sada
Armazm de dados
-
Engenharia de Software Prof. Rosrio Girardi
39
NMERO
NOME
ENDEREO
SALRIO
4.8.2.1.3 Estrutura da informao
4.9 Princpios da anlise de requisitos
Deve compreender-se e representar-se o domnio da aplicao
o domnio da informao
o domnio funcional
O problema deve decompor-se de forma que os detalhes se descubram de forma progressiva
Devem especificar-se as representaes lgicas e fsicas
4.9.1 Decomposio do problema
Estudante Disciplina1 n
Estudante Disciplina1 n
SISTEMA DE BIBLIOTECA
EMPRESTARCOMPRAR RESERVAR
VERIFICARDISPONIBILIDADE
REGISTRAREMPRSTIMO
Detalhamento
Decomposio
SISTEMA DE BIBLIOTECA
EMPRESTARCOMPRAR RESERVAR
VERIFICARDISPONIBILIDADE
REGISTRAREMPRSTIMO
SISTEMA DE BIBLIOTECA
EMPRESTARCOMPRAR RESERVAR
VERIFICARDISPONIBILIDADE
REGISTRAREMPRSTIMO
Detalhamento
Decomposio
-
Engenharia de Software Prof. Rosrio Girardi
40
4.9.2 Vises lgicas e fsicas dos requisitos
4.10 A especificao de requisitos
Referncia a Figura 9
Contrato
cliente-equipe de desenvolvimento
usurio-equipe de desenvolvimento
Abstrao (modelo)
situao real o imaginada
documento (descries grficas e ling.natural)
prottipo (especificao executvel)
representao formal (especificao executvel, validao)
Mtodos e ferramentas
L4G, geradores de aplicaes
Reuso de componentes
Programao automtica
A especificao (documento) de requisitos:
LOGICA FISICA
-Funes a realizar- Informao a processar
Independente de detalhes de implementao
Uma primeira aproximao a como se implementaram funes e estruturas de informao
Atribuio a elementos do SC
LOGICA FISICA
-Funes a realizar- Informao a processar
Independente de detalhes de implementao
Uma primeira aproximao a como se implementaram funes e estruturas de informao
Atribuio a elementos do SC
-
Engenharia de Software Prof. Rosrio Girardi
41
um documento formal usado para comunicar os requisitos aos clientes, engenheiros e gerentes.
O documento de requisitos descreve:
Os servios e funes que o sistema deve prover;
As limitaes sobre as quais o sistema deve operar;
Propriedades gerais do sistema, isto limitaes nas propriedades emergentes;
Definies de outros sistemas com o qual o sistema deve se integrar.
4.10.1 Propriedades emergentes
So propriedades do sistema como um todo que somente emergem quando todos os sub-sistemas estiverem integrados.
Exemplos de propriedades emergentes
Confiabilidade
Manutenabilidade
Desempenho (Performance)
Usabilidade
Segurana
O documento de requisitos tambm descreve:
Informaes sobre o domnio da aplicao do sistema; ex.: como calcular um certo tipo de valor
Limitaes nos processos usados para desenvolver o sistema;
Descries sobre o hardware no qual o sistema ir executar.
Glossrio que explica a terminologia usada
4.10.2 Usurios do documento de requisitos
Clientes do Sistema
Especificam os requisitos e os lem para checar se eles satisfazem suas necessidades.
-
Engenharia de Software Prof. Rosrio Girardi
42
Gerentes de Projeto
Usam os documentos de requisitos para planejarem uma proposta para o sistema e o processo de desenvolvimento do sistema.
Engenheiros de Sistema
Usam os requisitos para entenderem o sistema em construo.
Engenheiros de teste do sistema
Usam os requisitos para desenvolverem testes de validao do sistema.
Engenheiros de manuteno do sistema
Usam os requisitos para entenderem o sistema.
4.10.3 A estrutura do documento de requisitos
Padro IEEE/ANSI 830-1993 uma estrutura para o documento de requisitos
1 Introduo
1.1 Propsito do documento de Requisitos
1.2 Escopo do produto
1.3 Definies, acrnimos e abreviaes
1.4 Referencias
1.5 Resumo do resto do documento
2 Descrio Geral
2.1 Perspectiva do produto
2.2 Funes do produto
2.3 Caractersticas do usurio
2.4 Limitaes gerais
2.5 Suposies e dependncias
3 Requisitos especficos
Cobrem requisitos funcionais, no-funcionais e interface.
4. Apndices
ndice
-
Engenharia de Software Prof. Rosrio Girardi
43
4.10.3.1 Adaptando um padro
O padro do IEEE genrico e pretende ser aplicado em uma variada gama de documentos de requisitos.
Em geral, nem todas as partes do documento so necessrias para todos os documentos de requisitos.
Cada organizao dever adaptar o padro de acordo com o tipo de sistema que desenvolve.
Padro da empresa XYZ
Considere uma companhia (XYZ) que desenvolve equipamentos cientficos.
Prefcio
Define os leitores do documento e descreve a histria das verses, incluindo um explicao da criao de novas verses e um resumo das mudanas feitas em cada verso.
Introduo
Define o produto no qual o software est embutido, seu uso esperado e apresenta um resumo da funcionalidade do software de controle.
Glossrio
Define todos os termos tcnicos e abreviaes usadas no documento.
Requisitos gerais do usurio
Define os requisitos do ponto de vista dos usurios do sistema. Isto inclui uma mistura de linguagem natural e diagramas.
Especificao detalhada de software
Descrio detalhada da funcionalidade esperada do software. Poder incluir detalhes de algoritmos especficos que devem ser usados na computao.
Especificao de Hardware
Parte opcional que especifica o hardware que o software dever controlar. Poder ser omitido se uma plataforma padro de instrumento for ser utilizada.
Requisitos de confiabilidade e performance
Este captulo deve descrever os requisitos de confiabilidade e performance esperados do novo sistema.
Quando apropriado, os seguintes apndices podero ser adicionados:
-
Engenharia de Software Prof. Rosrio Girardi
44
Especificao da interface de Hardware;
Componentes de Software que devero ser reusados na implementao do sistema;
Especificao da estrutura de dados;
Modelos de fluxo de dados do sistema de software;
Modelos detalhados de objetos do sistema de software.
ndice
4.11 Construo de prottipos
1 - Avaliar descrio preliminar do software:
rea de aplicao
complexidade
caratersticas do cliente
caratersticas do projeto
2 - Desenvolver descrio abreviada dos requisitos
3 -Esboar especificao de projeto
4 - Construir, testar e refinar o prottipo
5 - Apresentar prottipo ao cliente (eventualmente modifica-lho)
6 - Repetir passos 4-5 (especificao completa ou sistema final)
-
Engenharia de Software Prof. Rosrio Girardi
45
4.11.1 Paradigma da prototipao
4.12 Roteiro para a especificao de requisitos
1 - Introduo (descrio dos objetivos do software)
2 - Descrio da informao
a - Representao do fluxo
b- Representao do contedo
c- Representao da estrutura
d - Representao da interface usurio
3 - Descrio funcional
a - Texto explicativo de cada funo
b - Restries/limitaes
c - Requisitos de desempenho
d - Diagramas
PROTOTIPOCONSTRUIDOexperimentalsistema finalConstruo
doprottipo
Usar eavaliaro prototipo
(cliente/usuario)
Prottipo satisfatorio?
Projetorpido
Engenhariade requisitos
NAO
SIM
PROTOTIPOCONSTRUIDOexperimentalsistema finalConstruo
doprottipo
Usar eavaliaro prototipo
(cliente/usuario)
Prottipo satisfatorio?
Projetorpido
Engenhariade requisitos
NAO
Construodoprottipo
Usar eavaliaro prototipo
(cliente/usuario)
Prottipo satisfatorio?
Projetorpido
Engenhariade requisitos
NAO
SIM
-
Engenharia de Software Prof. Rosrio Girardi
46
4 - Critrios de validao (casos de testing)
4.13 Mtodos para a anlise de requisitos
Aplicao sistemtica dos princpios da anlise de requisitos
Mecanismos para a anlise do domnio da informao
Representao grfica
Mecanismos de abstrao, decomposio e refinamento
Representao de vises lgicas e fsicas
4.13.1 Classificao dos mtodos para a anlise de requisitos
Anlise orientado ao fluxo de dados
Anlise orientado s estruturas de dados
Anlise orientado a objetos
-
Engenharia de Software Prof. Rosrio Girardi
47
Captulo 5 - Interao Humana - Computador
5.1 Conceitos bsicos
A Interao Humana - Computador (HCI) a disciplina que aborda o projeto, implementao, uso e avaliao de sistemas interativos. De uma forma geral, ela tambm aborda os problemas associados ao impacto do uso de computadores nos indivduos, organizaes e na sociedade em geral.
A interao usurio - computador possui hoje as seguintes caractersticas. Os usurios (informticos e no informticos) possuem diferentes destrezas e diferentes idades. O tipo de usurio determina o xito de interface em funo do treinamento, tratamento de erros e adequao a destrezas oferecidas pelo sistema.
Por outro lado, o crescimento em complexidade das aplicaes tem provocado um incremento em complexidade ainda maior nas interfaces dessas aplicaes, por exemplo, de simples interfaces de editores de texto a interfaces de sistemas de controle de trfego areo.
Uma interface mal projetada afeta:
Usurio (fatiga, estresse, mal-estares fsicos)
Cliente (altos custos treinamento, rpidos e freqentes cmbios de turno)
Projetista (altos custos de manuteno, reaes dos consumidores)
5.1.1 Importncia da HCI
A HCI crtica para o desenvolvimento de aplicaes bem-sucedidas, efetivas e simples de aprender, permitindo:
diminuio de custos
incremento da produtividade
reduo de falhas (ex. Controle de vos)
-
Engenharia de Software Prof. Rosrio Girardi
48
5.1.2 reas de aplicao
Interfaces orientadas a documentos (ex., edio de texto, planilhas eletrnicas)
Interfaces orientadas s comunicaes (ex., correio eletrnico, telefonia, teleconferncia)
Ambientes de desenvolvimento (ex., ferramentas de desenvolvimento de software, CAD/CAM)
Sistemas tutoriais e de ajuda em linha
Sistemas de controle (ex., controle de processos, realidade virtual, simuladores, jogos de vdeo)
Sistemas embutidos (ex., elevadores, eletrodomsticos)
5.1.3 Interface usurio
Uma interface o lugar de contato entre pelo menos duas entidades.
Uma interface -usurio se define como o conjunto de objetos, ferramentas, linguagens e representaes visuais entre uma pessoa e um computador. Compreende canais de informao que permitem que usurio e computador se comuniquem
Toda interao implica uma relao emisor-receptor onde cada uma das partes tem uma imagem da outra segundo a qual se estruturam e interpretam as mensagens
5.1.4 Fatores humanos
A disciplina conhecida como "Fatores humanos" estuda a interface usurio no ambiente de trabalho do usurio. Associada a Ergonomia que aborda o problema de projetar um ambiente de trabalho. Aborda aspectos concernentes utilizao de dispositivos por usurios, tais como:
Fisiologia - caractersticas fsicas - ex. altura
Percepo - habilidades para sentir a informao - visual, auditiva
Cognio - habilidades para processar a informao
-
Engenharia de Software Prof. Rosrio Girardi
49
5.1.5 Metforas
Uma metfora uma imagem mental compreensvel de objetos reais. Os cones so uma forma de implementar as metforas.
A metfora usual nas interfaces grficas atuais a metfora do escritrio (lixeira, folders, etc)
A utilizao de uma boa metfora critica para o sucesso da aplicao interativa. Por isso, a pesquisa na rea de gerao de metforas muito importante e aborda:
a definio funcional das tarefas da interface
a identificao de problemas do usurio
Nos sistemas de informao da Internet experimenta-se com diferentes tipos de metforas em funo tanto das tarefas como dos tipos de usurios (imprensa, telefono, utilitrio, televisor, enciclopdia, centro comercial)
5.1.6 Hipertexto
Df. rede de associaes entre fontes distribudas.
Origem - V. Bush, MEMEX, 1945
T. Nelson, 1965 (def. hipertexto)
Tim Berners-Lee, CERN, Ginebra, WWW, hipertexto como interface de Internet
Modifica forma em que habitualmente se realiza uma leitura
Definio de objetivo
Guiar intuitivamente
Decises, orientao
Treinamento
5.1.7 Origens
A HCI multidisciplinar tendo recebido contribuies de vrias rea de conhecimento como:
-
Engenharia de Software Prof. Rosrio Girardi
50
Cincia de a computao
Sicologa cognitiva
Sicologa social
Psicologia da percepo
Lingstica
Inteligncia artificial
Antropologia
5.1.7.1 Psicologia cognitiva
Evoluo humana bem-sucedida devido a faculdades mentais para uso e acesso informao
MenteProcesador
deinformacin
Figura 12 - Associao de processos mentais ao processamento da informao
Os processos cognitivos bsicos so:
Sensao e percepo de a informao de entrada
Ateno informao relevante
Armazenamento em memria de corta durao enquanto es processada
Adquisicin de habilidades complexas
Produo lingstica de sada oral ou escrita
Resoluo de problemas para tomar aes apropriadas
Planificao de seqncia de aes
-
Engenharia de Software Prof. Rosrio Girardi
51
Existnalgumas limitaes nos processos cognitivos do ser humano, estudados por Miller (1956) em relao capacidade da memria de curto tempo que reduzida. S 5 a 9 elementos so lembrveis no curto tempo. Porm, essa capacidade sensitiva ao contexto: complexidade, familiaridade, possibilidade de ser discriminados.
Esse estudo tem contribudo Cincia da computao e a HCI (ex. Tamanho dos menus, tcnicas estruturadas de especificao de requisitos, etc)
5.2 Evoluo
A evoluo da HCI tem se caracterizado por longos perodos de estabilidade seguidos de rpidos cmbios. Podemos distinguir quatro geraes:
Primeira gerao (50-60)
Segunda gerao (60-80)
Terceira gerao (1970)
Quarta gerao (1990)
Na primeira gerao no existia interao usurio - computador propriamente dita. Primeiro foram utilizadas as configuraes "plugboards" e logo o processamento por lotes (entrada por cartes perfurados, sada impressa).
A segunda gerao esteve caracterizada pelo tempo compartido em mainframes e minicomputadores. A interao usurio computador era realizada a traves de comandos. Na dcada dos 80 , com o surgimento do PC e os sistemas operacionais DOS e Unix se popularizam as interfaces de comandos. A popularidade do PC comea o mudar o tipo de usurio, de especialista a no especialista. Os usurios no especialistas comeam a ter dificuldades na utilizao das interfaces de comandos , um dos motivos que leva a terceira gerao de interfaces.
A terceira gerao de interfaces caracterizada pelo surgimento das interfaces grficas (GUI ou WIMP). As GUI aparecem j na dcada dos 70, nos laboratrios da Xerox PARC. so interfaces grficas baseadas em janelas, cones, menus e dispositivo sinalizador (Figura 13).
-
Engenharia de Software Prof. Rosrio Girardi
52
Figura 13 - Elementos de uma GUI
A quarta gerao de interfaces comea na dcada dos 90, caracterizada principalmente por:
Hipertexto e hipermdia
Realidade virtual
Interfaces post-WIMP
Interfaces adaptativas
Manipulao indireta e agentes
Estas interfaces foram popularizadas pela Macintosh no 80s e logo difundidas atravs do sistema operacional Windows da Microsoft.
-
Engenharia de Software Prof. Rosrio Girardi
53
5.3 Requerimentos de uma interface
Controle por parte do usurio
Intuitividade
Consistncia
Interna: O uso das mesmas convenes e regras para todos os elementos de a interface
Externa: Seguir as regras dadas pela plataforma utilizada e pelas convenciones culturais existentes
Claridade e esttica
Retroalimentaao
Reversibilidade
Usabilidade
Funcionalidade
Aceitabilidade do usurio
Aceitabilidade da organizao
Transparncia e reusabilidade
Contraste visual
Legibilidade
5.3.1 Requerimentos de uma GUI
Metfora apropriada
Organizao apropriada de dados, funes, tarefas e roles
Esquema de navegao eficiente
Qualidade da aparncia (como se v)
Seqncia de interao efetiva (como se sente)
-
Engenharia de Software Prof. Rosrio Girardi
54
5.4 O som na interao
Importncia no projeto
facilita a realizao das tarefas (manos e olhos ocupados)
aumenta largura de banda
reduzir necessidade de entrada manual
Reconhecimento de voz (voz para indicar comandos)
reduzir necessidade de sadas grficas
incorpora naturalidade interface
da informao redundante que pode ser de utilidade
mostra informao que no pode mostrar-se graficamente
apresenta melhor que os grficos certos tipos de informao
Informao a comunicar pelo som:
eventos fsicos (queda de um vaso; impressora fora de linha)
cmbios dinmicos (ouve-se quando o lquido chegou ao tope de um vaso; termina-se impresso de um trabalho)
estruturas anormais (mquina com problema; controle de dispositivos)
Som vs. viso
Som -ouvido uma vez desde diferentes lugares
Objeto -visto desde um lugar muitas vezes
5.4.1 Sistemas de reconhecimento de voz
De controle (ex. "guardar arquivo")
De ditado -reconhecimento e processamento de conversao normal
Dependente (treinado por usurios individuais) maior confiabilidade
Independente - vocabulrio limitado
-
Engenharia de Software Prof. Rosrio Girardi
55
Estagio atual
reconhecimento de voz discreto (pausas)
reconhecimento de voz contnuo para reas especficas
fim e comeo de palavra
Problemas
interferncia da fala com a execuo de tarefas requerendo o uso de memria temporal
fala e lingstica competem por os mesmos recursos cognitivos
RVoz e PNL - compreenso
5.4.1.1 Sintetizadores da fala
"text to speech"
texto ASCII como entrada
leitura do texto como sada
processamento de morfemas
simples e econmico
5.5 Percepo na interao
ms que ver e ouvir - interpretao de a informao no seu contexto e atribuio de significado
reconhecimento de padres - brilho, contraste, movimento e cor
visual, auditiva
5.5.1 Percepo visual
objetos relacionados
leis
semelhana - objetos similares como pertencentes a grupo
-
Engenharia de Software Prof. Rosrio Girardi
56
proximidade fsica - objetos prximos formam grupos
lei do fecho - melhor percepo de figuras cerradas
sistema visual permite percepo organizada
caractersticas espaciais de a informao (tamanho, forma, distancia, posio relativa, textura) so percebidas como propriedades de objetos.
-
Engenharia de Software Prof. Rosrio Girardi
57
Captulo 6 - O projeto de software
Figura 14 - A fase de projeto no processo de desenvolvimento de software
Figura 15 - O mapeamento da especificao do problema soluo computacional
Engenharia de sistemas
Codificao
Integrao e prova
Projeto
Engenharia de requisitos
Especificao de requisitos
Especificao de projeto
Engenharia de sistemas
Codificao
Integrao e prova
Projeto
Engenharia de requisitos
Engenharia de requisitos
Especificao de requisitos
Especificao de projeto
P S
Especificao do problema (requisitos) Soluo computacional
P S
Especificao do problema (requisitos) Soluo computacional
-
Engenharia de Software Prof. Rosrio Girardi
58
Figura 16 A decomposio do problema e da soluo
6.1 Modularidade
O atributo de software que permite abordar sua complexidade
E mais fcil resolver um problema complexo quando ele dividido em partes mais simples
Independncia funcional
Atributo principal de um bom projeto
Critrios para medir a independncia funcional
Coeso: fora funcional relativa de um mdulo
Acoplamento (conexo): Interdependncia relativa entre mdulos
6.2 Fases do projeto de software
Projeto global
Produto: Arquitetura do software
Projeto detalhado
Produtos:
Detalhes de processamento de cada modulo
P1
P3P4
P5
P2 S1 S2
S3
S4 S5
Definio do problema(Especificao de requisitos)
Subproblemas resolvidos atravs de um ou mais mdulos do software
P1
P3P4
P5
P2 S1 S2
S3
S4 S5
Definio do problema(Especificao de requisitos)
Subproblemas resolvidos atravs de um ou mais mdulos do software
-
Engenharia de Software Prof. Rosrio Girardi
59
Projeto de dados
6.2.1 O projeto global
Estabelece a estrutura dos mdulos do software e seus relacionamentos
arquitetura de software
Enfatiza coordenao (interao) sob computao (funcionalidade)
6.2.1.1 Diagramas de estrutura
Figura 17 - Mapa estruturado
S1 S2 S3 S4 S5
P
Estrutura 1
Estrutura 3
S1
S2
S3
S4 S5
S3
S1
S4
S5S2
Estrutura 2
S1S1 S2S2 S3S3 S4S4 S5S5
P
Estrutura 1
Estrutura 3
S1
S2
S3
S4 S5S1S1
S2S2
S3S3
S4S4 S5S5
S3S3
S1S1
S4S4
S5S5S2S2
Estrutura 2
-
Engenharia de Software Prof. Rosrio Girardi
60
Figura 18 Leques de sada e entrada
6.3 Tcnicas de projeto
A
D
B
M
E
H I J
P
C
F G
Q
K L N O
Estabelece hierarquia de controle entre os mdulos que compem o software
No estabelece detalhes de processos
AA
DD
BB
M
EE
HH II JJ
PP
CC
FF GG
QQ
K L N OKK LL NN OO
Estabelece hierarquia de controle entre os mdulos que compem o software
No estabelece detalhes de processos
A
D
B
M
E
H I J
P
C
F G
Q
K L N O
Leque de sada
Leque de entrada
AA
DD
BB
M
EE
HH II JJ
PP
CC
FF GG
QQ
K L N OKK LL NN OO
Leque de sada
Leque de entrada
-
Engenharia de Software Prof. Rosrio Girardi
61
Figura 19 Como realizar o mapeamento
6.3.1 Projeto estruturado
Figura 20 Do DFD ao Diagrama de estrutura
6.3.1.1 Mtodo do projeto estruturado
Expandir DFD
PS
Especificao do problema (requisitos) Soluo computacional
?P
S
Especificao do problema (requisitos) Soluo computacional
?
DFD
S3
S1
S4
S5S2
Diagrama de estrutura
Monitorarlocalmente
Paciente
Enfermaria
Constantesvitais
Mensagem de aviso
Limites dos pacientes
Monitorarcentralmente
Limites das constantes vitais
Dadosdo paciente
Atualizaode informao
Dadosdo pacientea atualizar
Dados de paciente
Geraode
relatrio Dados
de
pacient
e
RelatrioDados de
paciente
DFD
S3S3
S1S1
S4S4
S5S5S2S2
Diagrama de estrutura
Monitorarlocalmente
Paciente
Enfermaria
Constantesvitais
Mensagem de aviso
Limites dos pacientes
Monitorarcentralmente
Limites das constantes vitais
Dadosdo paciente
Atualizaode informao
Dadosdo pacientea atualizar
Dados de paciente
Geraode
relatrio Dados
de
pacient
e
RelatrioDados de
paciente
Monitorarlocalmente
Paciente
Enfermaria
Constantesvitais
Mensagem de aviso
Limites dos pacientes
Monitorarcentralmente
Limites das constantes vitais
Dadosdo paciente
Atualizaode informao
Dadosdo pacientea atualizar
Dados de pacienteDados de paciente
Geraode
relatrio Dados
de
pacient
e
RelatrioDados de
paciente
-
Engenharia de Software Prof. Rosrio Girardi
62
Anlise de transformao
Determinar tipo de fluxo de informao
Indicar os limites do fluxo
Gerar mapa estruturado a partir do DFD
Aplicar fatorizao
Refinar mapa estruturado utilizando heursticas de bom projeto
Figura 21 -Anlise de transformao Primeiro nvel de fatorizao
MC
ME MT MS
E T SMdulo controlador
Controladorchegadas
Controladortransformaes
Controlador sadas
Primeiro nvel de fatorizao
MC
ME MT MS
E T SMdulo controlador
Controladorchegadas
Controladortransformaes
Controlador sadas
Primeiro nvel de fatorizao
-
Engenharia de Software Prof. Rosrio Girardi
63
Figura 22 - -Anlise de transformao Segundo nvel de fatorizao
Heursticas de projeto Independncia funcional Reduzir conexo e melhorar coeso
Figura 23 Exemplo de aplicao de heursticas de projeto
AB
C
M C
M E M T M S
Mdulo controlador
Segundo nvel de fatorizao
B C
A
AB
C
M C
M E M T M S
Mdulo controlador
Segundo nvel de fatorizao
B C
A
A
B C D E F
A
BCD EF
A
B C D E F
A
BCD EF
A
B C D E F
A
BCD EF
-
Engenharia de Software Prof. Rosrio Girardi
64
6.3.2 Projeto detalhado
Produtos:
Detalhes de processamento de cada modulo
Projeto de dados
Figura 24
Figura 25 -Construes da programao estruturada
C
G
Q
K L N O
M o d u lo K
CC
GG
QQ
K L N OKK LL NN OO
M o d u lo K
Seqncia
Condio (IF-THEN_ELSE)
F T
F
T
(DO WHILE)
F
T
(REPEAT UNTIL)
Repetio Extenso IF-THEN_ELSESeleo de caso
F
T
T
F T
Seqncia
Condio (IF-THEN_ELSE)
F T
F
T
(DO WHILE)
F
T
(REPEAT UNTIL)
Repetio Extenso IF-THEN_ELSESeleo de caso
F
T
T
F T
-
Engenharia de Software Prof. Rosrio Girardi
65
Figura 26 -Diagramas de Nassi-Schneiderman
1eira tarefa
2da tarefa
3eira tarefa
Seqncia
F TCondio
Parte ELSE
Parte THEN
IF-THEN-ELSE
Repetio
Condio
Parte REPEATUNTIL
Condio
ParteDO WHILE
Parte CASE
Seleo
Condio do CASE
Valor Valor
1eira tarefa
2da tarefa
3eira tarefa
Seqncia
F TCondio
Parte ELSE
Parte THEN
IF-THEN-ELSE
Repetio
Condio
Parte REPEATUNTIL
Condio
ParteDO WHILE
Parte CASE
Seleo
Condio do CASE
Valor Valor
-
Engenharia de Software Prof. Rosrio Girardi
66
Captulo 7 - GERENCIAMENTO E PLANEJAMENTO DE PROJETOS DE SOFTWARE
7.1 Introduo
A gerncia de projetos abrange todo o processo de desenvolvimento. Para se conduzir um projeto de software bem-sucedido, vrias etapas tm que ser bem compreendidas e s o gerenciamento de projetos que oferece essa compreenso. A gerncia de projeto de software comea antes do trabalho tcnico, prossegue medida que o software se desenvolve do modelo conceitual para a realidade e encerra somente quando o software se torna obsoleto. Neste captulo faremos uma abordagem geral sobre a gerncia de projetos, com nfase na gerncia de projeto de software, destacando os problemas mais comuns provenientes da falta de gerenciamento, como conduzir um projeto de software,quais as mtricas utilizadas que auxiliam no gerenciamento e quais as fase e funes do planejamento e controle tcnico e administrativo.
7.2 Fundamentos dos projetos
Projetos so executados em todos os setores da economia e representam um conjunto de esforos complexos interdependentes, exigindo elevado esforo de gerenciamento. O gerenciamento de projetos garante estrutura, foco, flexibilidade e controle na busca de resultados.
Um projeto tem pontos claros de incio e fim, uma srie de atividades entre eles e um conjunto de objetivos.
O gerenciamento de projetos permite focar prioridades, monitorar desempenhos, superar dificuldades e adaptar-se a mudanas.
Organizar as tarefas de um projeto pode demandar tempo no incio, mas a longo prazo economiza tempo e esforo, e reduz risco de erros.
A natureza dinmica e interdisciplinar de um projeto traz srias dificuldades para o seu gerenciamento, quando so usados mtodos tradicionais de administrao.
Problemas mais comuns:
eficincia limitada falta de controle de qualidade tcnica e planejamento integrado;
-
Engenharia de Software Prof. Rosrio Girardi
67
resultados no relacionais com as necessidades reais resultante da falta de uma definio do problema, de controle e falta de avaliao;
atrasos srios nos cronogramas falta de um sistema conveniente de controle e progresso;
custos excessivos falta de estrutura adequada de estimativa e controle de custos;
m direo falta de sistema de informao conveniente.
Nos processos de gerenciamento de software todos esses problemas tcnicos e administrativos so freqentes:
gerncia fraca;
prazos finais impossveis de serem cumpridos;
insatisfao dos usurios;
aumentos dos custos;
aumento na demanda de manuteno.
7.2.1 Como conduzir um projeto de software?
A gerncia de projetos de grande importncia para o sucesso de um projeto. Seria razovel presumir-se que todos os gerentes de projetos entendem como coloc-la em prtica e que todos os profissionais entendem como trabalhar dentro dos limites estabelecidos por ela. Entretanto, h uma certa dificuldade em gerenciar projetos de software utilizando mtodos tradicionais de administrao de projetos, pois trata-se de um produto que possui elementos chaves de gerenciamento.
Antes de que um projeto possa ser planejado, os objetivos e o escopo devem ser estabelecidos, solues alternativas devem ser consideradas e as restries administrativas e tcnicas identificadas.Sem essas informaes impossvel definir estimativa de custos razovel, divises realsticas de tarefas ou uma programao de projeto administrvel e um planejamento adequado.
O desenvolvedor de software e o cliente devem definir em conjunto os objetivos e o escopo do projeto. Os objetivos identificam as metas globais
-
Engenharia de Software Prof. Rosrio Girardi
68
do projeto sem levar em considerao como essas metas sero atingidas. O escopo identifica as funes primrias que o software deve realizar e tenta delimitar essas funes de uma forma quantitativa.
Para se conduzir um projeto de software bem-sucedido devemos compreender:
o escopo do trabalho a ser feito;
os riscos em que incorreremos;
os recursos exigidos;
as tarefas a serem executadas;
s marcos de referncia a serem acompanhados;
o esforo despendido;
a programao a ser seguida.
7.2.2 Como iniciar um projeto de software?
Estabelecendo os objetivos e o escopo;
Considerando solues alternativas
Identificando restries administrativas e tcnicas;
Sem essas informaes impossvel definir estimativa de custos razovel, divises realsticas de tarefas ou uma programao de projeto administrvel e um planejamento adequado.
7.2.3 O que considerar no planejamento de projeto de software?
Esforo humano exigido;
Durao cronolgica do projeto;
Custos.
Antes de comear o Planejamento de Projeto de Software, devemos, atravs de tcnicas administrativas:
-
Engenharia de Software Prof. Rosrio Girardi
69
responder a algumas questes importantes sobre riscos;
desenvolver uma estratgia para atacarmos o problema;
estabelecer um mecanismo para avaliarmos o progresso;
organizar o pessoal que foram escolhidos para construir o produto.
7.2.4 Os aspectos comuns que devem ser considerados nas tcnicas administrativas:
Escopo do projeto estabelecido antecipadamente;
Mtricas de software e histrico de aferies passadas so usadas como base;
Divises do projetos em partes.
7.2.5 Previso de riscos
Para um bom gerenciamento de projeto de software crucial que se faa a anlise dos riscos.
Passos para se prever riscos:
Identificao;
Avaliao;
Disposio por ordem de prioridades;
Estratgias de administrao;
Resoluo;
Monitorao.
Os passos de administrao de riscos esto organizados num Plano de Administrao e Monitoramento dos Riscos PAMR, que documenta todo o trabalho executado como parte da anlise de riscos e usado pelo gerente de projetos como parte do Plano de Projeto Global.
-
Engenharia de Software Prof. Rosrio Girardi
70
7.2.6 Determinao dos prazos
Existem mtodos de determinao de prazos. O PERT Programa Evoluation and Revew Techinique (mtodo de avaliao de riscos de programa ) e o COM Critical Path Method ( mtodo de caminho crtico) so os dois mtodos de determinao de cronograma que podem ser aplicados no desenvolvimento de software. Ambas as tcnicas desenvolvem uma descrio da rede de tarefas de um projeto.
Na fixao de prazos para projetos de software uma srie de perguntas pode ser feitas.
Como relacionarmos o tempo cronolgico com o esforo humano?
Muitos gerentes acreditam que se houver atraso s acrescentar mais pessoas e o problema ser resolvido, mas acrescentar pessoas num projeto tem um efeito desintegrador. O esforo deve ser distribudo ao longo do processo de engenharia.
A figura a seguir ilustra uma distribuio de esforo recomendado ao longo das fases de definio e desenvolvimento
7.2.7 Monitorao e controle
Com a monitorao e controle de recursos podem ser redimensionadas tarefas reordenadas, compromisso de entrega modificados para acomodar o problema que foi descoberto.
7.3 Medidas de software
A princpio parece que a realizao de medies evidente por si mesma, mas a realidade pode ser bem diferente. A medio muita das vezes leva a
Codificao
Atividade de testes
e depurao
Anlise e
Projeto
-
Engenharia de Software Prof. Rosrio Girardi
71
muitas dvidas e questionamentos. Atualmente algumas mtricas foram desenvolvidas a fim de oferecer a gerentes e profissionais tcnicos a devida compreenso sobre o processo de engenharia de software e sobre o produto que ele produz. Mas ainda existem muitas controvrsias. Quais as mtricas apropriadas para o processo e para o produto? Como os dados que so compilados devem ser usados? justo usar medies para se comparar pessoas, processo e produtos?
Dificuldades em medir:
O que medir?
Como avaliar as medidas que so obtidas?
As mtricas de software so dividas em 2 categorias:
Medidas diretas
Linhas de cdigo (LOC) produzidas;
velocidade de execuo;
tamanhos de memria;
defeitos registrados;
Medidas Indiretas:
Funcionalidade;
qualidade;
complexidade;
eficincia;
confiabilidade;
Manutenibilidade.
As mtricas de software podem, ainda, ser divididas nas seguintes categoria:
-
Engenharia de Software Prof. Rosrio Girardi
72
mtricas de produtividade (sada do processo de engenharia de software);
mtricas da qualidade (indica se o software est atendendo s exigncias do cliente);
mtricas tcnicas (concentram-se na caracterstica do software);
mtricas orientadas ao tamanho;
mtricas orientadas para a funo;
mtricas orientadas s pessoas.
Figura 27 - Diviso das mtricas em categorias
Mtricas orientadas A seres humanos
Mtricas orientadas funo
Mtricas orientadas ao tamanho
Mtricas de produtividade
Mtricas de qualidade
Mtricas tcnicas
Produtividade = kloc
Pessoa ms
Qualidade = defeitos
kloc
Custo = $
kloc
Documentao = Pginas de documentao
-
Engenharia de Software Prof. Rosrio Girardi
73
7.3.1 Mtricas orientadas ao tamanho.
Mtricas orientadas ao tamanho so medidas diretas do software e do processo por meio do qual ele desenvolvido. No so universalmente aceitas, pois as medidas giram em torno do uso das linhas de cdigos como uma medida chave. Os opositores afirmam que as medidas LOC so dependentes da linguagem de programao, que ela penaliza projetos bem projetados, porm mais curtos.
7.3.2 Mtricas orientadas funo.
So medidas indiretas. A mtrica orientada funo concentra-se na funcionalidade ou utilidade do programa.
Ponto por funo so reunidos dados como:
nmero de entradas do usurio;
nmero de sada do usurio;
nmero de consultas do usurio;
nmero de arquivos;
nmero de interfaces externas.
-
Engenharia de Software Prof. Rosrio Girardi
74
Aps os dados acima terem sido reunidos, um valor de complexidade associado a cada contagem, chamado fator de ponderao, que determinado de forma um tanto subjetiva.
Os pontos-de-funo sero usados como medidas de produtividade, qualidade e outros atributos de software:
A mtrica de ponto-de-funo, como as linhas de cdigo (LOC), controversa. Os opositores afirmam que o mtodo se baseia parcialmente em dados subjetivos, no objetivos.
Quando medir?:
Durante o processo de engenharia de software;
Depois que o software foi entregue ao cliente e aos usurios.
7.3.3 Mtricas de qualidade
Nessa categoria incluem-se:
Complexidade do programa;
Modularidade efetiva;
Produtividade = FP
Pessoa Ms
Qualidade = Defeito
FP
Custo = $
FP
Documentao=Pg. de documentao FP
-
Engenharia de Software Prof. Rosrio Girardi
75
Tamanho do programa.
As mtricas usadas aps a entrega concentram-se:
Nmero de defeitos descobertos;
Manutenibilidade do sistema.
As medidas de qualidade existentes so
Corretitute o grau com que o software executa a funo que dele exigida
Manutenibilidade a facilidade com que um programa pode ser corrigido se um erro for encontrado ou ampliado se o cliente desejar incluso e alterao nos requisitos funcionais. Uma mtrica simples orientada ao tempo o tempo mdio para a mudana (RATTC);
Integridade mede a capacidade de suportar ataques sua integridade (hackers e vrus)
Usabilidade - a tentativa de se quantificar se a interface amigvel ao usurio.
7.3.4 Fatores que influenciam a produtividade do software
fatores humanos tamanho e experincia da equipe de desenvolvimento;
fatores do problema a complexidade do problema e nmero de mudanas;
fatores do processo so tcnicas de anlises e projetos que so usadas, linguagem e ferramentas CASE;
fatores do produto confiabilidade e desempenho do sistema;
fatores relacionados a recursos disponibilidade de ferramentas CASE, recursos de hardware e software.
-
Engenharia de Software Prof. Rosrio Girardi
76
7.4 O planejamento de software
7.4.1 Porque planificar?
Estimar recursos requeridos
Definir tarefas a executar
Estimar o esforo requerido
Estabelecer a agenda a seguir
7.4.2 Quando planificar?
Ao longo de todo o ciclo de desenvolvimento de forma a melhorar a preciso do plano do projeto de software
Comear logo aps o estudo de viabilidade, antes da anlise de requisitos
7.4.3 Fatores que afetam a preciso e a eficcia das estimaes
Baseada em estimaes
Quanto maior a preciso, menor o risco
Fatores que afetam a preciso e a eficcia das estimaes
complexidade das aplicaes
familiaridade com aplicaes similares
tamanho do projeto
disponibilidade de informao histrica
7.4.4 Uma guia para a planificao
1. Determinar o escopo do software
2. Estimar os recursos necessrios para o desenvolvimento
3. Estimar os custos de desenvolvimento
-
Engenharia de Software Prof. Rosrio Girardi
77
4. Avaliar a possibilidade de adquirir software
5. Estabelecer plano cronolgico de tarefas
6. Estabelecer estrutura organizacional da equipe de desenvolvimento
7. Elaborar plano do projeto
7.4.4.1 Escopo do software
Delimitar o que vai ser realizado, claramente e sem ambigidades (disponvel na especificao do sistema)
Avaliar e eventualmente refinar as funes do software bem como o desempenho requerido
Avaliar as interfaces com outros elementos do SC (hard, perifricos, pessoas e procedimentos)
Analisar aspetos vinculados a viabilidade do software (natureza do projeto & esforo para manter o projeto vivel)
7.4.5 Estimao de recursos
Recursos humanos
Ferramentas de software para o desenvolvimento
Recursos de hardware para o desenvolvimento
Grau de participao no projeto
Fases do desenvolvimento
PL. AR PG PD C TU TI
GERENTES
tec
Grau de participao no projeto
Fases do desenvolvimento
PL. AR PG PD C TU TI
GERENTES
tec
-
Engenharia de Software Prof. Rosrio Girardi
78
Figura 28 - Estimao de recursos humanos
-
Engenharia de Software Prof. Rosrio Girardi
79
Captulo 8 - A Reutilizao de software
A Reutilizao de software uma das principias tcnicas para enfrentar a crise de software: ou problema de construir aplicaes de software confivel de forma controlada e a um custo acorde s estimaes realizadas
8.1 Conceitos bsicos
8.1.1 Problemas do desenvolvimento de software
Complexidade das aplicaes de software
Crescimento continuo da demanda
Novas reas de aplicao
Custo da manuteno
Confiabilidade
Cmbios nos requisitos das aplicaes
Problemas na definio de requisitos
Tcnicas para prototipao e a programao exploratria
Tcnicas e ferramentas que suportam a reutilizao
8.1.2 Qualidade e produtividade atravs da reutilizao
Melhor produtividade atravs da reutilizao de software j existente
O custo de desenvolvimento pode ser dividido entre varias aplicaes
Maior confiabilidade
componentes de software j testados
Promove a prototipao
Simplifica tanto a manuteno corretiva como evolutiva
-
Engenharia de Software Prof. Rosrio Girardi
80
8.1.3 Problemas atuais da reutilizao
Esforo requerido para criao de componentes reutilizveis (retorno em longo prazo)
Esforo necessrio para criar, adaptar e integrar componentes
Falta de mecanismos para recuperar software efetivamente
Conhecimento da rea ou domnio da aplicao
Sucesso em reas conhecidas ou domnios estveis
8.1.4 O desenvolvimento orientado a objetos e a reutilizao
Suporte s atividades associadas reutilizao:
Encapsulamento
Polimorfismo
Herana
Instanciao
Passagem de mensagens
8.1.5 Efetividade da recuperao