Apostilha ES2003

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


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


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


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


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


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.


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


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.


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.


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)


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:


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)


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).


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)


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


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.


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


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


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


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


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


NAO

Figura 4 - Ciclo de vida baseado na prototipao


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


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


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


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)


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


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


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


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:


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


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


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.


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


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?


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


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


Manuteno

Especificaode requisitos


Codificao

Integraoe prova

Projeto



Codificao

Integraoe prova

ProjetoProjeto



Manuteno

Especificaode requisitos


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


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


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




REGISTRAREMPRSTIMO




REGISTRAREMPRSTIMO

Detalhamento

Decomposio


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


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.


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


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:


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)


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


doprottipo

Usar eavaliaro prototipo

(cliente/usuario)


Projetorpido

Engenhariade requisitos

NAO

SIM


doprottipo


(cliente/usuario)


Projetorpido


NAO

Construodoprottipo


(cliente/usuario)


Projetorpido


NAO

SIM


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


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)


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


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:


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


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).


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.


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)


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


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


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.


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


Codificao

Integrao e prova

Projeto


Especificao de requisitos

Especificao de projeto


Codificao

Integrao e prova

Projeto



Especificao de requisitos

Especificao de projeto

P S

Especificao do problema (requisitos) Soluo computacional

P S



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


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


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


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


?P

S


?

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




Dadosdo paciente



Dados de paciente

Geraode

relatrio Dados

de

pacient

e

RelatrioDados de

paciente

Monitorarlocalmente

Paciente

Enfermaria

Constantesvitais

Mensagem de aviso




Dadosdo paciente



Dados de pacienteDados de paciente

Geraode

relatrio Dados

de

pacient

e

RelatrioDados de

paciente


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


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


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


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


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;


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


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:


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.


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


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:


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


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.


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


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.


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


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


78

Figura 28 - Estimao de recursos humanos


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


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

Documents

Apostilha ES2003