Apostila Eng SW

UNIVERSIDADE DO OESTE DE SANTA CATARINA CAMPUS XANXER Curso: Tecnologia em Informtica Disciplina: Engenharia de Software Professor: Andr Luiz
z Forchesatto
APOSTILA ENGENHARIA DE SOFTWARE
SUMRIO
Captulo 1 Introduo a engenharia de software - 3 -
1. Introduo
A engenharia de software surgiu da necessidade de se construir software com mais qualidade em menor tempo, antigamente se produzia software de uma maneira muito desordenada sem preocupao com o que realmente o software deveria fazer ou se erra possvel construir um software para executar tal tarefa, com isto surgiu famosa crise do software que fez com que as empresas ou fbricas de software pensassem em uma maneira de como desenvolver os softwares de maneira confivel e rpida. O software teve uma grande evoluo no decorrer de sua existncia ocasionada principalmente pelo barateamento do hardware e a evoluo das tcnicas de desenvolvimento, como podemos observar no quadro 1 abaixo. Perodo Evoluo
1950 1960 Orientao a Batch Software totalmente customizados Distribuio limitada Multiusurios Tempo Real Banco de Dados Produto de Software Sistemas distribudos Inteligncia embutida Hardware de baixo custo Impacto de consumo Sistemas de desktop poderosos Tecnologia orientada a objeto Sistemas Especialistas Redes neurais artificiais Computao Paralela
1960 1970
1980 1990
1990 2000
Quadro 1 Evoluo do software(fonte Pressmam, pg.5).
Como podemos observar houve uma grande evoluo nas tecnologias de software, hoje podemos dizer que produzimos software muito mais confivel do que no tempo que se trabalhava com sistema em batch, porm alguns problemas que tnhamos naquela poca ainda tempos hoje, como por exemplo, os problemas de comunicao, e alguns mitos levantados por (Presmman, pg.26) que sero demonstrados agora. 1.1. Mitos e Realidade Segundo Pressman, existem trs grandes mitos no desenvolvimento de software, que surgiram nos primrdios do desenvolvimento de software e continuam at hoje propagando desinformao e confuso. Mitos Administrativos: Envolve os gerentes que tem como responsabilidade de gerenciar cronogramas e custos. Mito Realidade
preciso que a equipe aplique efetivamente os conhecimentos apresentados no manual necessrio que o que conste no dado manual reflita a prtica de desenvolvimento de software e que esta prtica seja verificada com freqncia, para confirmar o uso do conhecimento.
Se a equipe dispe de um manual de padres e procedimentos de desenvolvimento de software, ento a equipe est apta a encaminhar bem o desenvolvimento. A equipe tem ferramentas
de O fato da empresa ter hardware de ltima gerao no garante
Captulo 1 Introduo a engenharia de software - 4 desenvolvimento de software de ltima que em nada a qualidade do software desenvolvido. Mais gerao, uma vez que eles dispe de importante que ter um hardware de ltima gerao ter computadores de ltima gerao. ferramentas para a automatizao do desenvolvimento de software. As chamadas ferramentas CASE. Se o desenvolvimento do software estiver Isto no condiz com a realidade. Quanto mais pessoas pegarem atrasado, basta aumentar a equipe para o barco andando, pior. Por que os novos profissionais devero honrar o prazo de desenvolvimento. ser treinados e isto ser feito por membros da equipe, o que vai implicar em maiores atrasos no cronograma.
Quadro 2 Mitos Administrativos
Uma descrio breve e geral dos requisitos do software o suficiente para iniciar o seu projeto maiores detalhes podem ser definidos posteriormente.
Mitos do Cliente: Envolve todos os clientes que podem ser deste de um atendente at o dono da empresa. Mito Realidade
Este um dos problemas que pode levar um projeto ao fracasso. O cliente deve ser questionado a fim de definir o mais precisamente possvel os requisitos importantes para o software: funes, desempenho, interfaces, restries de projeto e critrios de validao. Estes so pontos fundamentais para o sucesso do projeto. O software mais flexvel que a maioria dos produtos manufaturados, mas no existe software que suporte uma alterao significativa em seu escopo sem influenciar no custo e no prazo de entrega. O fator de multiplicao dos custos no desenvolvimento de software pode ser observado na figura abaixo.
Os requisitos de projeto mudam continuamente durante o seu desenvolvimento, mas isto no representa um problema, uma vez que o software flexvel e poder suportar facilmente as alteraes.
Quadro 3 Mitos Cliente
Aps a edio do programa e a sua colocao em funcionamento, o trabalho est terminado. Enquanto o programa no entrar em funcionamento, impossvel avaliar a sua qualidade. O produto a ser entregue no final do projeto o programa funcionando.
Quadro 4 Mitos Profissional
Mitos do Profissional: Envolve os profissionais que desenvolvem software que vem com uma cultura desde os primrdios da programao. Mito Realidade
A realidade justamente o contrrio. Segundo estatsticas, aps a implantao ocorrero 50% a 70% do esforo do desenvolvimento de software (manuteno). A preocupao com a qualidade do software deve ocorrer durante todo o processo de desenvolvimento, ao final de cada etapa deve ser feita uma verificao dos critrios de qualidade. O produto final no apenas o software funcionando, mas tambm um conjunto importante de documentos, que acompanham o mesmo.
1.2. Perguntas freqentes sobre engenharia de software A engenharia de software concentra seus esforos em uma grande gama de assuntos, gerando com isto muitas duvidas, atravs do livro Engenharia de Software do Ian Sommervile, onde o mesmo prope uma sesso de perguntas e respostas relativas a engenharia de software, ser possvel esclarecer as duvidas fundamentais da engenharia de software. Pergunta
O que Software? O que software? engenharia de
Resposta
Qual a diferena entre engenharia de software e cincia da computao? O que um processo de software? O que um modelo de processo de software? Quais so os custos da engenharia de software? O que so mtodos engenharia de software? de
O que CASE (computeraided software engineering engenharia de software com auxilio de computador)? Quais so os atributos de um bom software? Quais so os principais desafios enfrentados pela engenharia de software?
So os programas de computador e a documentao associada. Produtos de software podem ser desenvolvidos para um cliente especfico ou para o mercado. Engenharia de software uma disciplina da engenharia que se ocupa de todos os aspectos da produo de software. Pressman. O estabelecimento e uso de slidos princpios de engenharia para que se possa obter economicamente um software que seja confivel e que funcione eficientemente em mquina reais. A cincia da computao se ocupa de todos os aspectos relacionados ao desenvolvimento de sistemas com base em computadores, incluindo hardware, software e engenharia de processos. A engenharia de software parte desse processo. um conjunto de atividades, cuja meta desenvolvimento ou evoluo do software. uma representao simplificada de um processo de software, apresentada a partir de uma perspectiva especfica. Aproximadamente 60 por cento dos custos so relacionados ao desenvolvimento e 40 por cento so custos referentes aos testes. Para o software personalizado, os custos de evoluo freqentemente excedem os custos de desenvolvimento. So abordagens estruturadas para o desenvolvimento de software, que incluem modelos de sistemas, notaes, regras, recomendaes de projetos e diretrizes de processos. So sistemas de software destinados a proporcionar apoio automatizado s atividades de processo de software. Os sistemas CASE so freqentemente utilizados para proporcionar apoio aos mtodos. O software deve proporcionar ao usurio a funcionalidade e o desempenho requeridos e deve ser passvel de manuteno, confivel e de fcil uso. Lidar com sistemas legados, atender crescente diversidade e atender s exigncias quanto a prazos de entrega reduzidos.
Quadro 5 Perguntas freqentes sobre engenharia
1.3. Paradigmas de Desenvolvimento de Software (Processo) No Existe uma abordagem em particular que seja a melhor para a soluo da aflio de software. Entretanto, ao combinarmos mtodos abrangentes para todas as fases de desenvolvimento do software, melhores ferramentas para automatizar esses mtodos, blocos de construo mas poderosos para a implementao do software, melhores tcnicas para garantia da qualidade do software e uma filosofia de coordenao predominante, controle e administrao, podemos conseguir uma disciplina para o desenvolvimento do software. Como podemos analisar no relato acima Pressman afirma que uma boa combinao de mtodos e uma boa disciplina podemos elaborar um projeto de software com qualidade. Embora existam varias abordagem para o desenvolvimento de software a atividades que so inerentes a todos os processos de desenvolvimento de software como relata (Sommerville, pg. 36): 1. Especificao de software: preciso definir a funcionalidade do software e as restries em sua operao; 2. Projeto e implementao de software: Deve ser produzido o software de modo que cumpra suas especificaes. Normalmente est faze dividida em 3 partes: Projeto de software, codificao e testes; 3. Validao do software: O software precisa ser validado para garantir que ele faz o que o cliente deseja; 4. Evoluo de software: O software precisa evoluir par atender s necessidades mutveis do cliente. Com isto foi apresentada uma viso geral do que envolve um processo ou paradigma de desenvolvimento de software, mas existem diferentes abordagens onde as mesmas sero discutidas abaixo. 1.3.1. Modelo Cascata A figura 1 representa o modelo cascata ou ciclo de vida clssico que segundo (Pressman, pg.32) [...] o ciclo de vida clssico requer uma abordagem sistemtica, seqencial ao desenvolvimento de software, que se inicia no nvel do sistema e avana ao longo da anlise, projeto, codificao, teste e manuteno.. O Modelo Cascata envolve as seguintes atividades: Planejamento/Engenharia de Sistemas: preparar o plano de desenvolvimento do sistema com base nas conversas com o usurio. Ter uma viso global do sistema, incluindo hardware, software e as pessoas envolvidas. Anlise de Requisitos: definio dos requisitos de software. O resultado ser utilizado nas etapas posteriores de Projeto, Construo, Testes e Manuteno. recomendado o uso de ferramentas CASE. Projeto: transformar os requisitos da anlise, o modelo lgico em modelo fsico. Utilizando ferramenta CASE, banco de dados e linguagem de programao. Segundo Pressman
Construo/Codificao: fazer os programas e relatrios dos sistemas com base nas especificaes das fases anteriores. Teste e Integrao: realizar os testes no sistema e realizar as integraes com eventuais sistemas atuais. Operao e Manuteno: Fazer o acompanhamento do software durante um perodo. Liberar o uso para o usurio e efetuar alteraes no sistema que visem a soluo de erros, melhorias ou incluso de novas funcionalidades. Aps concluda uma etapa ou fase, deve ser feita uma homologao a fim de verificar se os documentos gerados condizem com os requisitos do sistema. Sendo necessrio, devem ser refeitas as tarefas com problemas. Uma vez aprovada a fase, ela no deve ser alterada, pois implica em alterao na fase seguinte, e conseqentemente aumento dos custos. Problemas: O modelo em cascata possui alguns problemas em virtude dele impor que seja seguida a ordem proposta, muitas vezes isto no possvel, outro problema que o usurio geralmente no consegue relatar todos seus problemas na faze de anlise como o modelo exige, outro problema que o usurio s ira conseguir visualizar um resultado aps um longo tempo de andamento do projeto.
Figura 1 Ciclo de Vida clssico
1.4. Desenvolvimento Evolucionrio O desenvolvimento evolucionrio segundo (Sommervile, pg.39) caracteriza por desenvolver uma implementao inicial e expor o resultado ao comentrio do usurio que devera solicitar as alteraes e com isto ser gerada uma nova implementao. Existem dois tipos de desenvolvimento evolucionrio onde os mesmos so descritos abaixo: Desenvolvimento exploratrio: Neste paradigma o cliente e o desenvolver trabalham junto sendo que o processo fazer o levantamento de requisitos bsicos desenvolver um sistema inicial e aps isto ir incrementando novas funcionalidades ao sistema.
Desenvolvimento de prottipos descartveis: O objetivo deste compreender melhor os requisitos do cliente que estejam mal compreendidos atravs do desenvolvimento de prottipos que depois sero descartados. O desenvolvimento evolucionrio possui algumas vantagens em relao ao modelo cascata, pois o mesmo possibilita que sejam desenvolvidos gradativamente os requisito levantados pelo usurio, possibilitando assim uma melhor compreenso sobre o sistema desejado. Na figura 2 pode-se observar como funciona o desenvolvimento evolucionrio. Este modelo proposto tambm possuiu algumas desvantagens, que entre elas podemos citar: O processo no visvel pelos seus gerentes, pelo fato de parecer que o processo se concentra s em desenvolvimento; Os sistemas se tornam mal estruturados pelo fato de serem desenvolvidos como uma cocha de retalho; Podem ser exigidas ferramentas e tcnicas especiais para desenvolvimento rpido.
ESPECIFICAO DESCRIO ESBOO
Verso Inicial Verso intermediria Verso Final
DESENVOLVIMENTO
VALIDAO
Figura 2 Modelo de desenvolvimento evolucionrio.(fonte sommerville, pg.39).
1.5. Desenvolvimento formal de sistema O desenvolvimento formal tem como base o modelo cascata, mas a grande caracterstica dele que o mesmo faz uma transformao matemtica formal nos requisitos do software para depois gerar o executvel, isto proporciona muito mais segurana no comprimento dos requisitos do cliente s que torna o processo de analise muito mais demorado. Geralmente o modelo de desenvolvimento formal de sistema aplicado em situaes que se exige uma grande segurana no comprimento de requisitos, como em sistema que mexe com a vida humana. As principais diferenas entre as abordagens modelo cascata e desenvolvimento formal de sistema segundo (Sommerville, pg.40) so:
1.
2.
Como podemos observar na citao de Sommerville o modelo extremamente formal, pois pega os requisitos e transforma em uma especificao formal como demonstrada na figura 3 abaixo.
A especificao de requisitos de software redefinida em uma especificao formal detalhada, que expressa em uma notao matemtica. Os processos de desenvolvimento de projeto, implementao e testes de unidade so substitudos por um processo de desenvolvimento transformacional, em que a especificao refinada por meio de uma srie de transformaes, em um programa.
Mas o modelo possui algumas desvantagens claras que so: necessria uma percia muito especializada para a transformao dos requisitos levantados pelo cliente em formas normal; No oferece vantagens em relao aos outros modelos nos requisitos custo e qualidade; Consome um esforo muito grande em desenvolvimento para a maioria dos sistemas;
Definio de requisitos
Especificao formal
Transformao formal
Integrao e testes de sistema
Figura 3 Desenvolvimento formal de sistemas.(fonte sommerville, pg.40).
1.6. Desenvolvimento orientado a reuso Pode-se dizer que na maioria dos softwares a reuso, por exemplo, quando desenvolvemos alguma aplicao em delphi estamos reutilizando uma srie de bibliotecas que o prprio delphi nos traz isto j reuso. S que o desenvolvimento orientado a reuso no s isto ele se preocupa em muito mais do que usar os componentes existentes, para ele todo componente tem que ser estudado em qual escopo ele pode ser aplicado. A abordagem de desenvolvimento orientada no se utiliza simplesmente de componentes ela pode-se utilizar de sistema propriamente ditos, como por exemplo os sistemas comerciais de prateleira, como explica (Sommervile, pg.41)
Essa abordagem orientada a reuso conta com uma ampla base de componentes de software reutilizveis, que podem ser acessados, e com alguma infra-estrutura de integrao para esses componentes. s vezes, esses componentes so sistemas propriamente ditos (os j mencionados COTS, sistemas comerciais de prateleira), que podem ser utilizados para proporcionar funcionalidade especfica, como formatao de textos, clculo numrico, entre outros.
O modelo desenvolvimento orientado a reuso pode ser dividido em: Anlise de componentes: feita uma busca de componentes para suprir os requisitos; Modificao de requisitos: Requisitos so analisados utilizando informaes sobres os componentes; Projeto de sistema com reuso: Desenvolvimento da infra-estrutura do sistema utilizando os componentes; Desenvolvimento e integrao: Desenvolver interfaces de comunicao entre os componentes escolhidos para o sistema.
Na figura 4 abaixo podemos observar o modelo orientado a reuso.

Especificao de requisitos Anlise de componentes Modificao de requisitos Projeto de sistema com reuso
Desenvolvimento e integrao
Figura 4 Desenvolvimento orientado a reuso.(fonte sommerville, pg.42).
Validao de sistema
1.7. Modelos Hbridos Os modelos hbridos surgiram da necessidade de se utilizar diferentes tipos de modelos conhecidos em um s sistema, surgiu tambm em virtude de os modelos j conhecidos serem fracos no que se diz respeito ao desenvolvimento interativo, ou seja, quando algum pedao do processo deve ser refeito. Existem dois modelos que surgiram para tentar solucionar estes problemas onde os mesmo so descritos abaixo. 1.7.1. Desenvolvimento Incremental ou interativo A idia principal deste modelo de desenvolvimento a de que um sistema deve ser desenvolvido de forma incremental, sendo que cada incremento vai adicionando ao sistema novas capacidades funcionais, at a obteno do sistema final, sendo que, a cada passo realizado, novas modificaes podem ser introduzidas.Uma vantagem desta abordagem a facilidade em testar o sistema, uma vez que a realizao de testes em cada nvel de desenvolvimento , sem dvida, mais fcil do que testar o sistema final.O importante que mesmo sendo a implementao por funcionalidade, a arquitetura global deve estar pronta antes da construo do primeiro mdulo. Esta abordagem traz vrias vantagens ao cliente pois o mesmo pode adiar as decises sobre os requisitos mais importantes para uma etapa posterior, pois o mesmo estar recebendo varias verses do sistema onde o mesmo poder ir trabalhando at todo o sistema ficar pronto, abaixo na figura 5 podemos observar como deve funcionar este desenvolvimento. Contudo este tipo de desenvolvimento tambm traz desvantagens para os desenvolvedores como, por exemplo, difcil definir o tamanho exato de cada incremento, torna-se difcil tambm prever a independncia dos mdulos do sistema como desenvolver um sistema que no dependa de outras partes que ainda no foram desenvolvidas.
Definir esboo dos requisitos
Atribuir requisitos aos incrementos
Projetar arquitetura do sistema
Desenvolver incremento do sistema
Validar incremento
Integrar incremento
Validar sistema
Figura 5- Desenvolvimento incremental (fonte sommerville, pg.42).
1.7.2. Modelo Espiral O modelo espiral para a engenharia de software foi desenvolvido para abranger as melhores caractersticas tanto do ciclo de vida clssico como da prototipao, acrescentando, ao mesmo tempo, um novo elemento a anlise de riscos que falta a esses paradigmas. O modelo define quatro atividades representadas pelos quatro quadrantes da figura 7:
Figura 6- Modelo espiral
Planejamento: determinao dos objetivos, alternativas e restries. Anlise de riscos: anlise de alternativas e identificao/resoluo dos riscos. Engenharia: desenvolvimento do produto no nvel seguinte. Avaliao do cliente: avaliao dos resultados da engenharia.
Captulo 2 Projeto de software - 12 -
2. Projeto de software
Segundo (Pressmam, pg.415) O projeto o primeiro passo da fase de desenvolvimento de qualquer produto ou sistema de engenharia. Como pode-se observar nas palavras de Pressmam o projeto o inicio de qualquer coisa ligada a engenharia, por exemplo, um engenheiro civil no manda construir um prdio sem antes elaborar um planta, verificar o terreno e outras coisas que denominamos de projeto, assim tambm no desenvolvimento de software voc no pode construir nada sem antes projetar, mas como todo engenheiro, antes mesmo de projetar alguma coisa deve-se ser desenvolvido um estudo para verificar se o desenvolver do projeto vivel, cria-se tambm mecanismos de rastreamento deste projeto para ver se tudo o que ele projetou esta acontecendo conforme o previsto, isto na engenharia de software chamado de Gerncia de Projeto que o primeiro aspecto do projeto de software que estar sendo discutido agora. 2.1. Gerncia de Projetos Este tpico trata de conceitos fundamentais para uma administrao efetiva de projetos de software levando em considerao as mtricas de software utilizadas e o impacto que estas mtricas causam sobre a gerncia de projetos. O que significa Gerenciamento de Projeto? Gerenciar um projeto requer a realizao das seguintes atividades bsicas: Planejamento: - Identificar e planejar as atividades e tarefas, preparando planos de trabalho, estimativas e cronogramas viveis. - Identificar, planejar aes e eliminar fontes de risco, antes que aconteam - Planejar as necessidades e a obteno dos recursos humanos e tcnicos - Definir os produtos intermedirios e planejar a entrega destes. Execuo: - Criar condies para que as atividades previstas possam ser realizadas. - Atuar para que o grupo realize as tarefas com sinergia e supere as dificuldades previstas e imprevistas, visando atingir os objetivos, oramentos e cronogramas, com o menor desvio possvel. - Servir de tcnico entre o grupo do projeto e o mundo externo a este. - Estabelecer regras para as solicitaes de mudanas nas especificaes do projeto e negociar as condies para a aceitao destas. - Conduzir o processo para a obteno de mxima qualidade do produto. Controle: - Medir e avaliar o progresso do projeto (fsico e financeiro) em relao ao planejado, tomar aes corretivas e comunicar o andamento do projeto. O exerccio de todas essas atividades combinadas, realizadas por pessoas com grande energia e habilidade, se transforma num gerenciamento eficaz de projeto.
Gerncia de projetos a primeira camada da engenharia de software, abrangendo todo o processo de desenvolvimento do incio ao fim. Para a conduo de um projeto de software bem sucedido necessrio compreender: a) O escopo do trabalho; b) Os riscos; c) Os recursos exigidos; d) As tarefas a serem executadas; e) Os marcos de referncia a serem acompanhados; f) O esforo/custo despendido; g) E a programao a ser seguida. A gerncia comea antes do trabalho tcnico e prossegue durante o desenvolvimento do software e encerra somente quando o software se torna obsoleto, ao final da fase de gerencia de projeto um plano de projeto como o apresentado na figura 7 dever ser gerado.
Figura 7 Plano de projeto(fonte Pressman, pg.168)
2.1.1. Iniciando um projeto de software (Contexto) Segundo (Pressman, pg55),

Antes de iniciar o planejamento de um projeto de um software, o objetivo e escopo devem estar bem estabelecidos, solues alternativas devem ser consideradas e as restries administrativas e tcnicas identificadas. Sem essas informaes impossvel definir estimativas de custo precisas, dividir de forma realista as tarefas de um projeto de tal forma que oferea sinais significativos de progresso.
Como pode-se observar nas palavras de Pressmam um bom inicio de projeto deve-se concentrar-se em definio do escopo do software. O escopo de um software consiste em
definir quais so as funes primrias que o software deve realizar e procura delimitar a quantidade de funes, geralmente o escopo de um software definido em conjunto com o cliente e se divide em algumas etapas: Definio das funes: consistem em extrair do cliente quais as reais funes que o software devera ter; Questes de desempenho: extrair do documento ou do cliente quais so os fatores que influenciaro no desempenho do software, como por exemplo a quantia de dados, a no existem de servidores, problemas de rede, comunicao remota, etc.. Restries de hardware: definir com o cliente que tipo de mquina esta disponvel para o sistema rodar. Restries de interface: Verificar se haver a necessidade de interface de comunicao com perifricos como, por exemplo: impressoras fiscais, leitores de cdigo de barras, impressoras, etc... 2.1.2. Medidas e Mtricas (Estimativas) Medies e mtricas auxiliam a entender o processo usado para se desenvolver um produto. O processo medido a fim de melhor-lo e o produto medido para aumentar sua qualidade. Entretanto, medies s vezes levam argumentaes: a) Quais so as mtricas apropriadas para o processo e o produto ? b) justo usar medies para se comparar pessoas, processos e produtos ? Essas e outras perguntas sempre vm tona quando feita uma tentativa de se medir alguma coisa que no tenha sido medida no passado. Isso o que acontece com a engenharia de software (o processo) e com o software (o produto). As medidas so uma forma clara de avaliao de produtividade no desenvolvimento de software. Atravs da obteno de medidas relativas produtividade e qualidade, possvel que metas de melhorias no processo de desenvolvimento sejam estabelecidas como forma de incrementar estes dois fatores. Mtricas de software referem-se a uma ampla variedade de medidas de software. No contexto de gerenciamento de projeto de software, estamos preocupados com mtricas de produtividade e de qualidade - medidas do resultado do desenvolvimento de software como uma funo do esforo aplicado e medidas da "adequao ao uso" do resultado que produzido. O software medido por muitas razes: a) Indicar a qualidade do produto. b) Avaliar a produtividade das pessoas que produzem o produto. c) Avaliar os benefcios em termos de produtividade e qualidade derivados de novos mtodos e ferramentas de software. d) Formar uma linha bsica de estimativas. e) Ajudar a justificar os pedidos de novas ferramentas ou treinamento adicional. As medies do mundo fsico podem ser divididas em duas categorias: 1. Diretas: como o comprimento de algum componente de computador. 2. Indiretas: a qualidade do componente atravs da quantidade de componentes rejeitados.
Entre as medidas diretas do processo de engenharia de software incluem-se o custo e o esforo aplicados. Entre as medidas diretas do produto as linhas de cdigo (LOC) produzidas, velocidade de execuo, tamanho de memria e defeitos registrados ao longo de certos espao de tempo. As medidas indiretas do produto incluem funcionalidade, qualidade, complexidade, eficincia, confiabilidade, manutenibilidade e muitas outros aspectos do produto. Medidas diretas so fceis de serem medidas dado que um padro de medio seja adotado antecipadamente. Medidas indiretas como funcionalidade e qualidade so mais difceis de serem medidas. Podemos dividir o domnio das mtricas de software em: a) Mtricas de produtividade: concentram-se na sada do processo de engenharia de software com o objetivo de avaliar o prprio processo. b) Mtricas de qualidade: oferecem uma indicao de quo estreitamente o software conforma-se s exigncias implcitas e explcitas do cliente. c) Mtricas tcnicas: concentram-se nas caractersticas do software (por exemplo: complexidade lgica e modularidade). Ou ainda podemos dividir o domnio das mtricas de uma outra forma: a) Mtricas orientadas ao tamanho: medidas so derivadas a partir de atributos de tamanho do software como linhas de cdigo, esforo, custo, quantidade de documentao, etc... b) Mtricas orientadas para a funo: oferecem medidas indiretas. c) Mtricas orientadas s pessoas: usam informaes sobre a maneira pela qual as pessoas desenvolvem software e percepes humanas sobre a efetividade das ferramentas e mtodos. 2.1.2.1.Mtricas Orientadas ao Tamanho So medidas diretas do software e do processo por meio do qual ele desenvolvido. Uma tabela pode ser mantida sobre dados de projetos do ltimos anos, como mostra a tabela abaixo.
Projeto AAA-1 CCC-4 FFF-3 Esforo (pessoas-ms) 24 62 43 $ 168 440 314 KLOC 12,1 27,2 20,2 Pags doc. 365 1224 1050 Erros 29 86 64 Pessoas 3 5 6
Tabela 1- Mtricas Orientadas ao Tamanho
A partir dos dados descritos para cada projeto da tabela um conjunto de mtricas de qualidade e de produtividade orientadas ao tamanho pode ser desenvolvido para cada projeto. Mdias podem ser computadas levando-se em conta todos os projetos. Exemplos de algumas mtricas: Produtividade = KLOC/pessoa-ms. Qualidade = defeitos/KLOC Custo = $/LOC
Documentao = Pg.Doc/KLOC Repare que estas mtricas orientadas ao tamanho giram em torno do nmero de linhas de cdigo como a medida principal. Esta abordagem gera algumas discusses. As pessoas que so a favor afirmam LOC esto presentes em todos os projetos e so fceis de serem contadas, que muitos modelos existentes utilizam esta medida como chave e que j existe um grande volume de literatura e de dados baseados em linhas de cdigo. Por outro lado, opositores afirmam que as medidas LOC so dependentes da linguagem de programao, que penalizam programas bem projetados porm mais curtos, que elas no podem acomodar facilmente linguagens no procedimentais e que seu uso em estimativas requer um nvel de detalhes que pode ser difcil de se conseguir (ou seja, como estimar o nmero de linhas de cdigo de um programa muito antes de anlise e projeto terem sido concludos? ). 2.1.2.2.Mtricas orientadas funo So medidas indiretas do software e do processo atravs do qual o software desenvolvido. Mtrica orientada funo concentra-se na funcionalidade ou utilidade do software e no no nmero de linhas de cdigo. O mtodo Ponto por Funo (FP- function point) uma mtrica orientada funo e possibilita a medio de produtividade. Os pontos por funo so computados completando-se a tabela representada na figura 8 abaixo:
Figura 8 Mtricas orientada a funo
Onde: Nmero de entradas do usurio: cada entrada do usurio que proporcione dados distintos orientados aplicao contada. Nmero de sada do usurio: Cada sada do usurio que proporcione informaes orientadas aplicao contada. Relatrios, telas, mensagens de erro, etc. Os itens de dados individuais dentro de um relatrio no so contados separadamente. Nmero de arquivos: Cada agrupamento lgico de dados que pode ser uma parte do banco de dados ou um arquivo convencional contado. Nmero de interfaces externas: todas as interfaces legveis por mquina (por exemplo, arquivos de dados em fita ou disco) que sejam usadas para transmitir informaes a outro sistema so contadas.
A cada contagem, um valor de complexidade associado. Para computar os pontos por funo, a relao do quadro 6 usada: FP = contagem total x [0,65 + 0,01 x SOMA(Fi)]. Onde Contagem total: Representa a soma dos fatores da figura8; Fi: So valores de ajustes de complexidade baseados nas respostas s perguntas do quadro 7 abaixo, seguindo uma escala de pontuao conforme a tabela 2 abaixo: Pontos
0 1 2 3 4 5 Sem influncia Incidental Moderado Mdio Significativo Essencial
Quadro 6- Formula para calculo do FP
Resposta
Tabela 2 Pontos para os fatores
O sistema requer backup e recuperao confiveis? So exigidas comunicaes de dados? H funes de processamento distribudas? O desempenho crtico? O sistema funcionar num ambiente operacional existente, intensivamente utilizado? O sistema requer entrada de dados on-line? A entrada de dados on-line exige que a transao de entrada seja elaborada em mltiplas telas ou operaes? Os arquivos-mestres so utilizados on-line? As entradas, sadas, arquivos e consultas so complexos? O processo interno complexo? O cdigo foi projetado de forma a ser reusado? A converso e a instalao esto includas no projeto? O sistema projetado para mltiplas instalaes em diferentes organizaes? A aplicao projetada de forma a facilitar mudanas e o uso pelo usurio?
Quadro 7 Fatores de ajuste de complexidade
Fatores
Os valores constantes da equao e os fatores de peso que so aplicados s contagens do domnio de informaes so determinados empiricamente. Assim que forem calculados os pontos por funo sero usados de maneira anloga s LOC como medida de produtividade, qualidade e outros atributos de software: Produtividade = FP/pessa-ms. Qualidade = defeitos/FP. Custo = $/FP. Documentao = pginas de documentao/FP. Uma outra medida chamada de pontos de particularidades foi acrescentada a fim de acomodar aplicaes em que a complexidade algortmica elevada. Os pontos de particularidades so computados usando a figura 9 abaixo:
Figura 9 pontos de particularidade
O valor do ponto de particularidade global e calculado pela mesma frmula do quadro 6, pontos de particularidades e pontos por funo representam a mesma coisa - a funcionalidade do software. Assim como a mtrica de LOC, a de ponto por funo ou a de particularidades controversa. Os proponentes afirmam que FP independe da linguagem de programao tornando-o ideal para aplicaes que usam linguagens convencionais e no procedimentais. Alm disso, afirmam que se baseia em dados que tm maior probabilidade de ser conhecidos logo no comeo da evoluo do projeto. Os opositores afirmam que o mtodo se baseia parcialmente em dados subjetivos e que o FP no tem significado fsico direto - apenas um nmero. 2.1.2.3.Reconciliao entre diferentes abordagens de mtricas A relao entre linhas de cdigo e pontos por funo depende da linguagem de programao utilizada e da qualidade do projeto. A tabela 3 abaixo apresenta estimativas do nmero mdio de linhas de cdigo exigido para construir um ponto por funo em vrias linguagens de programao: Linguagem Quantidade de Linhas
Assembly Cobol Fortran Pascal Linguagens orientadas a objeto Geradores de cdigo 300 100 100 90 30 15
Tabela 3- Reconciliao entre diferentes abordagens de mtricas
Questes que devem ser consideradas com relao ao uso de medidas de produtividade de software: a) As LOC/pessoa-ms ou FP/pessoa-ms de um grupo devem ser comparadas com dados similiares de outros ? b) Os gerentes devem avaliar o desempenho de pessoas usando essas mtricas ? NO ! Muitos fatores influenciam a produtividade: Fatores humanos: tamanho e experincia da organizao de desenvolvimento. Fatores do problema: complexidade do problema a ser resolvido e o nmero de mudanas nos requisitos ou restries de projeto.
Fatores do processo: tcnicas de anlise e projeto que so usadas, linguagens e ferramentas CASE disponveis e tcnicas de reviso. Fatores do produto: Confiabilidade e desempenho do sistema baseado em computador. Fatores relacionados a recursos: disponibilidade de ferramentas CASE, recursos de hardware e software. Os pontos por funo e linhas de cdigo foram considerados previses relativamente precisas do esforo e custo do desenvolvimento. Porm, para que se possa usar estas mtricas, uma linha bsica de informao histrica deve ser estabelecida. Por que to importante medir o processo de engenharia de software e o produto que ele produz? Se no medirmos no haver nenhuma maneira real de sabermos se estamos ou no melhorando. A medio oferece benefcios em nvel estratgico, em nvel de projeto e em nvel tcnico. Para estabelecer metas de melhoria, a situao atual do desenvolvimento do software deve ser entendida. Portanto, a medio usada para estabelecer uma linha bsica de processo a partir da qual as melhorias possam ser avaliadas. Ao usar medies para estabelecer uma linha bsica de projeto, questes como qualidade, prazo e estimativas tornam-se mais fceis de serem administradas. 2.1.2.4.Estabelecimento de uma linha bsica (Baseline) A linha bsica consiste de dados compilados de projetos passados de desenvolvimento de software. Esta linha bsica pode conter medidas orientadas ao tamanho, funo e de qualidade. Os dados da linha bsica devem ter os seguintes atributos: a) Os dados devem ser razoavelmente precisos. b) Os dados devem ser obtidos de tantos projetos quanto for possvel. c) As medies devem ser consistentes, por exemplo, a linha de cdigo deve ser interpretada consistentemente ao longo de todos os projetos para os quais so compilados dados. d) As aplicaes devem ser idnticas ao trabalho que ser estimado. 2.2. Estimativa O planejamento uma das atividades fundamentais do processo de gerenciamento de software. No planejamento so colocados estimativas de esforo humano (pessoas-ms), durao cronolgica (em tempo de calendrio) e custo (em moeda). Mas como feito um planejamento? Muitas vezes, estimativas so feitas usando-se a experincia passada como nico guia. Mas se um novo projeto for totalmente diferente dos projetos realizados at o momento? Assim, apenas a experincia passada talvez no seja suficiente. Vrias tcnicas de estimativa esto disponveis. Embora cada uma tenha suas particularidades, todas tm os seguintes atributos: a) O escopo do projeto deve estar estabelecido. b) Mtricas de software so utilizadas e o histrico de aferies passadas usado como uma base a partir da qual estimativas so feitas. c) O projeto dividido em pequenas partes que so estimadas individualmente.
O processo de administrao de projetos de software inicia-se com um conjunto de atividades que so denominadas planejamento de projetos. A primeira dessas atividades a realizao de estimativas. Quando queremos que estimativas sejam feitas, olhamos para o futuro e aceitamos certo grau de incerteza como coisa esperada. Estimativas so baseadas em mtricas histricas e empricas. Mtricas histricas Obtidas a partir de experincias anteriores da equipe. Mtricas empricas Dados estatsticos de diferentes equipes. Planejar - estimar Para estimar: Experincia. Acesso a boas informaes histricas. Riscos Inerentes. Fatores que aumentam os riscos Complexidade do projeto Tamanho do Projeto Estrutura do Projeto Objetivos do Planejamento O objetivo do planejamento de projetos de software fornecer uma estrutura que possibilite ao gerente fazer estimativas razoveis de recursos, custos e prazos. Essas estimativas so realizadas dentro de um plano de tempo limitado ao incio de um projeto de software e devem ser regularmente atualizadas medida que o projeto progride. Para se obter uma boa estimativa algumas atividades devem ser cumpridas, abaixo esto algumas delas: Escopo do Software A funo e o desempenho atribudos ao software durante o trabalho de engenharia de sistema computadorizado devem ser avaliados para que se possa estabelecer um escopo de projeto que seja claro e compreensvel tanto em nvel tcnico como administrativo. O escopo do software descreve a funo, o desempenho, as restries, as interfaces e a confiabilidade. As funes descritas na declarao do escopo so avaliadas e, em certos casos, refinadas para oferecer mais detalhes antes do incio da estimativa. O desempenho abrange os requisitos de processamento e de tempo de resposta. As restries identificam os limites impostos ao software pelo hardware externo, memria disponvel e outros sistemas existentes. Recursos Cada recurso especificado segundo quatro caractersticas: descrio do recurso, uma declarao da disponibilidade, tempo cronolgico em que o recurso ser exigido e por quanto tempo o recurso ser aplicado. A disponibilidade do recurso para uma atividade especfica deve ser estabelecida o mais cedo possvel. Recursos humanos O planejador comea a avaliar o escopo e a selecionar as habilidades exigidas para concluir o desenvolvimento. Tanto os postos organizacionais (por exemplo, gerente,
engenheiro de software, etc.) como as especialidades (por exemplo, telecomunicaes, banco de dados, etc.) so especificados. Para projetos relativamente pequenos, uma nica pessoa pode executar todas as etapas de engenharia de software consultando especialistas quando necessrio. O nmero de pessoas pode ser determinado somente depois de uma estimativa de esforo de desenvolvimento. Recursos de Hardware Trs categorias de hardware devem ser consideradas durante o planejamento do projeto: o hardware de desenvolvimento, o hardware de produo e outros elementos de hardware do novo sistema. O hardware de desenvolvimento um computador e os perifricos relacionados que sero usados durante o desenvolvimento do software. O hardware de produo onde o software ser executado. Outros elementos de hardware do sistema podem ser especificados com recursos para o desenvolvimento. Recursos de Software Da mesma forma que usamos hardware para construir um novo hardware, usamos software para auxiliar no desenvolvimento de um novo software. Atualmente, os engenheiros de software usam um conjunto de ferramentas denominado engenharia de software auxiliada por computador (CASE- Computer-Aided Software engineering). Principais categorias: ferramentas de planejamento de sistemas de informao; ferramentas de gerenciamento de projetos; ferramentas de apoio; ferramentas de anlise e projeto; ferramentas de programao; ferramentas de integrao e testes; ferramentas de construo de prottipos e simulao; ferramentas de manuteno; ferramentas de framework. Reusabilidade Reuso dos blocos de construo do software. Duas regras qdo. o software reusvel for utilizado como recurso: Se o software existente cumprir os requisitos, adquira-o. O custo de aquisio de um software existente quase sempre ser menor do que o custo para desenvolver um software equivalente. Se o software existente exigir alguma modificao antes que possa ser adequadamente integrado ao sistema, proceda cautelosamente. O custo para modificar um software existente s vezes pode ser maior do que o custo para desenvolver um software equivalente. Estimativas para Projetos de Software Software - Elemento mais caro. Erros de estimativa diferena entre lucro e prejuzo. Estimativa no exata: variveis podem afetar o custo final do software - humanas, tcnicas, ambientais, polticas...
Usar tcnicas oferece estimativas com riscos aceitveis Atrasar a estimativa at um ponto tardio do desenvolvimento Usar tcnicas de decomposio Desenvolver modelo emprico Adquirir ferramentas de estimativas automatizadas. 2.2.1. Estimativas Utilizando COCOMO (Constructive Cost Model) O mtodo COCOMO foi desenvolvido por Barry Boehm, para estimar esforo, prazo, custo e tamanho da equipe para um projeto de software. O mtodo foi derivado de um data set que compreendia 63 projetos cobrindo reas como: negcios, controle, cientfica, suporte e sistema operacional. Existem trs modelos neste mtodo: COCOMO Bsico: um modelo esttico de valor simples que computa o esforo (e custo) de desenvolvimento de software como uma funo do tamanho de programa expresso em linha de cdigo estimadas. COCOMO Intermedirio: computa o esforo de desenvolvimento de software como uma funo do tamanho do programa e de um conjunto de direcionadores de custo que incluem avaliaes subjetivas do produto, do hardware, do pessoal e dos atributos do projeto. COCOMO Avanado: incorpora todas as caractersticas da verso intermediria, com uma avaliao do impacto dos direcionadores de custo sobre cada passo (anlise, projeto, etc.) do processo de engenharia de software. O COCOMO classifica os projetos em trs tipos : Modelo Orgnico (ou convencional): projetos de software simples, relativamente pequenos, nos quais pequenas equipes com boa experincia em aplicaes trabalham num conjunto de requisitos no to rgidos. Outras caractersticas: ambiente estvel de desenvolvimento, algoritmos simples, prmio relativamente baixo para trmino antes do prazo, tamanho relativamente pequeno, projetos na faixa de 50.000 linhas de cdigo. Modelo Semidestacado (ou difuso): projeto de software intermedirio (em tamanho e complexidade) onde a equipe mescla grande e pouca experincia com aplicaes, grande e pouca experincia com a tecnologia, o tamanho dos software varia at 300.000 linhas de cdigo. Modelo embutido (ou restrito): um projeto que deve ser desenvolvido dentro de um conjunto rgido de restries operacionais, de hardware e de software. COCOMO Bsico Estimativa de Esforo 1) Determinar o Modo do Projeto (Orgnico, Difuso ou Restrito) 2) Determinar o Nmero de Linhas de cdigo Esta uma das limitaes do mtodo, pois como, no incio do projeto, saberemos quantas linhas de cdigo sero produzidas? Uma alternativa vivel a utilizao combinada do mtodo FPA (ou FP) e COCOMO. Uma vez que o FP pode transformar pontos de funo em linhas de cdigo, poderamos usar o resultado da transformao para a aplicao das equaes de esforo do COCOMO.
3) Aplicar a Estimativa de LOC na equao do Esforo. O COCOMO propicia trs equaes para determinar o esforo previsto para o projeto, conforme o modelo do mesmo. Modelo Esforo
Orgnico Difuso Restrito P/M=2,4 (KLOC)1,05 P/M=3,0 (KLOC)1,12 P/M=3,6 (KLOC)1,20
Supondo: 50 KLOC para um software orgnico. 100 KLOC para um software difuso. 200 KLOC para um software restrito. Aplicando a frmula: Para o software orgnico: P/M=2,4 (50)1,05 =146 Para o software difuso: P/M=3,0 (100)1,12=521 Para o software restrito: P/M=3,6 (200)1,20=2077 Estimativa do Prazo O COCOMO tambm prov equaes para a determinao do prazo do projeto. Modelo
Orgnico Difuso Restrito Prazo=2,5 (P/M)0,38 Prazo=2,5 (P/M)0,35 Prazo=2,5 (P/M)0,32
Prazo
Aplicando as estimativas de esforo do exemplo anterior, os prazos estimados seriam: Para o software orgnico: Prazo=2,5 (146)0,38=16.61 meses Para o software difuso: Prazo=2,5 (521)0,35=22.33 meses Para o software restrito: Prazo=2,5 (2077)0,32=28,81meses
Estimativa de quantidade de Pessoal preciso dividir o esforo estimado pelo prazo estimado. Em nosso exemplo, os resultados seriam: Para o software orgnico: Equipe= 146/16,61=9. Para o software difuso: Equipe=521/22,33=23. Para o software restrito: Equipe=2007/28,81=72. Diversos fatores no-previstos podem alterar o planejamento. Um risco a ocorrncia de um evento que possa comprometer o andamento do projeto (cronograma, oramento, qualidade...). 2.3. Anlise de Riscos Segundo Robert Charette.
[...] o risco preocupa-se com acontecimentos futuros. Hoje e amanh esto alm da preocupao ativa, uma vez que j estamos colhendo aquilo que foi anteriormente plantado por nossas aes passadas. A questo , portanto: ao mudarmos nossas aes hoje, podemos criar oportunidade para uma situao diferente e esperanosamente melhor para ns mesmos amanh? Isso significa,
Captulo 2 Projeto de software - 24 em que o risco envolve mudanas, tais como mudanas de mentalidade, de opinio, de aes ou de lugares [...] o risco envolve escolha e a incerteza que a prpria escolha acarreta[...]
Quando o risco considerado no contexto da engenharia de software, trs pilares conceituais de Charette esto em evidncia: a) O futuro nossa preocupao - quais riscos poderiam fazer com que o projeto de software sasse fora do destino traado? b) A mudana nossa preocupao - mudanas nos requisitos do cliente, nas tecnologias de desenvolvimento, nos computadores de destino e em todas as demais entidades ligadas ao projeto afetaro o sucesso global e o cumprimento do cronograma? c) Escolhas - quais mtodos e ferramentas devem usar, quantas pessoas devem ser envolvidas, quanta nfase sobre a qualidade suficiente,...? A anlise de riscos composta por quatro atividades: Identificao, projeo, avaliao e administrao dos riscos. 2.3.1. Identificao dos riscos Peter Drucker diz "Embora seja ftil tentar eliminar o risco e questionvel tentar minimiz-lo, fundamental que os riscos assumidos sejam os riscos certos.". Antes de identificar os riscos certos, importante levantar todos os riscos que sejam bvios tanto aos gerentes quanto aos demais profissionais envolvidos no desenvolvimento. Os riscos de um projeto podem ser divididos em trs categorias: Riscos de projeto: identificam problemas oramentrios, de cronograma, de pessoal, de recursos, de clientes e de requisitos e o impacto dos mesmos sobre o projeto. Riscos tcnicos: identificam potenciais problemas de projeto, implementao, interface e manuteno. Ambigidade de especificao, incerteza tcnica, obsolescncia de tcnica so fatores de risco. Riscos de negcio: podem destruir os resultados at mesmo dos melhores projetos de software. Alguns riscos de negcio: (1) construir um excelente produto que ningum realmente quer (risco de mercado), (2) construir um produto que no mais se encaixe na estratgia global de produtos da empresa, (3) construir um produto que a equipe de vendas no sabe como vender, (4) perder o apoio da alta administrao devido mudana de enfoque ou mudana de pessoas (risco administrativo); (5) perder o compromisso oramentrio ou de pessoal (risco oramentrio). Nem todos os riscos so impossveis de ser prognosticados antecipadamente. A identificao dos riscos envolve a relao dos riscos especficos de projeto dentro das amplas categorias acima esboadas. Um dos melhores mtodos para se entender cada um dos riscos usar um conjunto de perguntas que ajude o planejador do projeto a compreender os riscos em termos tcnicos ou de projeto. Por exemplo, o planejador poderia atingir uma compreenso dos riscos de composio do pessoal ao responder s seguintes perguntas: 1. So as melhores pessoas disponveis? 2. As pessoas tm a combinao certa de habilidades? 3. H pessoas suficientes disposio? 4. O pessoal est comprometido com toda a durao do projeto?
5. Algum membro do pessoal do projeto estar trabalhando somente em tempo parcial nesse projeto? 6. O pessoal tem as expectativas certas sobre o trabalho que tem mo? 7. Os membros do pessoal receberam o necessrio treinamento? 8. A rotatividade entre os membros do pessoal ser baixa o bastante para permitir continuidade? As repostas a essas perguntas permitir que o planejador estime o impacto dos riscos na composio da equipe. 2.3.2. Projeo dos riscos A projeo ou estimativa dos riscos tenta classificar cada risco de duas maneiras probabilidade de que o risco seja real e as conseqncias dos problemas associados ao risco, caso ele ocorra. Algumas tarefas so desempenhadas para a projeo dos riscos. O primeiro passo definir uma escala em termos booleanos, qualitativos ou quantitativos. Ao extremo, cada pergunta poderia ser respondida com um "sim" ou "no". Mas isso altamente irreal. Como avaliar os riscos em termos to absolutos? Uma abordagem melhor seria adotar uma escala de probabilidades qualitativas que tivesse os seguintes valores: altamente improvvel, improvvel, moderado, provvel, altamente provvel. Alternativamente, o planejador poderia calcular a probabilidade matemtica de que o risco venha a ocorrer (por exemplo, uma probabilidade de 0.90 implica um risco altamente provvel). Probabilidades numricas podem ser estimadas usando-se a anlise estatsticas das mtricas compiladas de experincias passadas, da intuio e de outras informaes. Por exemplo, se as medidas compiladas de 45 projetos indicarem que 37 projetos experimentaram o dobro de mudanas feitas pelo cliente do que as originalmente previstas , a probabilidade de que um novo projeto experimente nmeros de mudana excessivos de 37/45 = 0,82 = muito provvel. Finalmente, os riscos so ponderados em funo do possvel impacto percebido sobre o projeto e depois colocados em ordem de prioridade. Trs fatores afetam o impacto: sua natureza, seu escopo e seu tempo de ocorrncia. A natureza do risco indica os problemas provveis se ele ocorrer. Por exemplo, uma interface externa com o hardware do cliente mal definida (risco tcnico) frustrar a realizao do projeto e dos testes e provavelmente levar a problemas na integrao do sistema posteriormente. O escopo de um risco combina a gravidade (quo ele srio) com sua distribuio global (quanto do projeto ser afetado ou quantos clientes sero prejudicados?). O tempo de ocorrncia de um risco considera quando e por quanto tempo o impacto ser sentido. 2.3.3. Avaliao dos riscos Neste momento do processo de anlise dos riscos possvel estabelecer um conjunto de termos que tem a forma [ri, li, xi] onde ri o risco, li a probabilidade do risco e xi o impacto do risco. Durante a avaliao dos riscos examinaremos mais detalhadamente a preciso das estimativas que foram feitas durante a projeo dos riscos, tentaremos determinar uma
ordem de prioridade e comearemos a pensar em maneiras de controlar e/ou evitar riscos que tm probabilidade de ocorrer. A fim de que a avaliao seja til, um nvel de risco referente deve ser definido. Para a maioria dos projetos de software, o custo, os prazos e o desempenho representam trs nveis de risco referentes tpicos. Um nvel de risco referente tem um ponto simples ou tambm chamado de breakpoint. A figura 10 abaixo representa esta situao:
Figura 10 Break-Point
Se o acontecimento de um risco levar a problemas que faam com que o custo ou os prazos seja ultrapassado haver um nvel, representado pela curva da figura, que provocar o encerramento do projeto. No ponto simples, a deciso de prosseguir ou encerrar possuem mesmo peso. Qualquer outro ponto alcanado na curva provoca o trmino do projeto, representado pela parte acima da curva. Ento, durante a avaliao dos riscos: 1. Definir nveis de risco referentes. 2. Procurar desenvolver um relacionamento entre cada [ri, li, xi] e cada um dos nveis referentes. 3. Determinar o conjunto de pontos referentes que define uma regio de encerramento. 4. Tentar levantar como associaes combinadas dos riscos afetaro um nvel referente. 2.3.4. Gerenciamento e monitorao dos riscos Para a atividade de gerenciamento e monitorao dos riscos, o trio (descrio, probabilidade e impacto dos riscos) associado a cada risco usado como uma base a partir da qual os passos de gerenciamento dos riscos so desenvolvidos.
Por exemplo, se a alta rotatividade de pessoal tomada como um risco r1, com uma probabilidade estimada l1 = 70% (bastante elevada) e o impacto x1 projetado para aumentar a durao do projeto em 15% e o custo global em 12%, os seguintes passos de administrao dos riscos so propostos: 1. Reunir-se com o pessoal atual para determinar as causas da rotatividade e pessoal. 2. Tomar providncias para suavizar aquelas causas que estejam sob nosso controle antes que o projeto se inicie. 3. Assim que o projeto iniciar, pressupor que haver rotatividade de pessoa e desenvolver tcnicas para garantir a continuidade quando as pessoas sarem. 4. Organizar equipes de projeto de forma que as informaes a respeito de cada atividade sejam amplamente difundidas. 5. Definir padres de documentao e estabelecer mecanismos para se certificar de que os documentos sejam desenvolvidos de maneira oportuna. 6. Realizar revises de todo o trabalho com os colegas de forma que mais de uma pessoa esteja a par das atividades desenvolvidas. 7. Definir um membro do pessoal que sirva de backup para cada profissional mais crtico. Estes passos de administrao dos riscos acarretam custos - por exemplo, manter um profissional backup para cada profissional crtico. Se as providncias para evitar os riscos da alta rotatividade de pessoal aumentarem o custo e a durao do projeto em 15% e o fator de custo predominante for o backup, a administrao poder decidir no implementar esse passo. Por outro lado, se os passos de administrao dos riscos forem projetados para aumentar os custos em 5% e a durao em apenas 3%, a administrao provavelmente os colocar em prtica. Ou seja, parte da administrao dos riscos significa avaliar quando os benefcios advindos das atividades tomadas para evit-los so ultrapassados pelos custos associados implementao dos mesmos. O gerenciamento pode ser representado graficamente pela figura 11 abaixo:
Figura 11 Gerenciamento dos riscos
Para um grande projeto, muitos riscos podem ser identificados. Se entre trs e sete passos de administrao dos riscos forem identificadas para cada um, a administrao dos riscos pode tornar-se um projeto em si mesmas! Entretanto, a experincia indica que 80% dos riscos globais do projeto podem ser correspondentes a apenas 20% dos riscos identificados. Durante os primeiros passos de anlise dos riscos possvel determinar quais riscos residem nesses 20%. Por esse motivo, alguns dos riscos identificados, avaliados e projetados podem no se encaixar no plano de administrao dos riscos eles no correspondem aos 20% crticos. 2.4. Definio do cronograma A determinao de um cronograma para desenvolvimento de software pode ser vista sob duas perspectivas diferentes: Uma data final para a entrega j foi estabelecida. A organizao de software v-se compelida a distribuir o esforo dentro do espao de tempo previsto. Limites cronolgicos aproximados foram discutidos, mas que a data final ser estabelecida pela engenharia de software. O esforo distribudo para que se possa tirar o melhor proveito dos recursos e uma data final definida aps cuidadosa anlise. A preciso na determinao de um cronograma s vezes pode ser bem mais importante do que a preciso na determinao dos custos. Os custos adicionados podem ser absorvidos por nova determinao de preos ou por amortizao aps o longo de um grande nmero de vendas. Um cronograma no cumprido, porm, pode reduzir o impacto de mercado, criar clientes insatisfeitos e elevar os custos internos. Quando abordamos a determinao de prazos para um projeto de software, uma srie de perguntas pode ser feita: Como relacionamos o tempo cronolgico com o esforo humano? Quais tarefas e paralelismos devem ser esperados? Quais marcos de referncia podem ser usados para mostrar o progresso? Como representaremos fisicamente o cronograma e como rastrearemos o progresso quando o projeto se iniciar? 2.4.1. Relaes pessoas-trabalho Num projeto de desenvolvimento de software pequeno, uma nica pessoa pode analisar os requisitos, executar o projeto, gerar o cdigo e realizar testes. medida que o tamanho do projeto aumenta, mais pessoas devem ser envolvidas. Raramente podemos abordar um esforo de 10 pessoas-ano com uma pessoa trabalhando durante 10 anos. Mito: se nos atrasarmos, sempre poderemos acrescentar mais programadores e posteriormente sairmos do atraso no projeto. Infelizmente, acrescentar pessoas tardiamente num projeto muitas vezes tem um efeito desintegrador fazendo com que o cronograma fuja ainda mais do controle: 1. Tempo dever ser despendido para treinar o novo pessoal. 2. Um nmero maior de pessoas aumenta o nmero de canais de comunicao e a complexidade desta ao longo de um projeto. Cada canal de comunicao adicional requer esforo e tempo adicionais. Por exemplo:
Sejam quatro engenheiros de software, cada um capaz de produzir 5000 LOC/ANO trabalhando individualmente num projeto. Se estes quatro engenheiros so inseridos num projeto em equipe, seis potenciais canais de comunicao so criados. Cada canal requer tempo que, de outra forma, seria usado para o desenvolvimento. Vamos supor que a produtividade da equipe seja reduzida em 250 LOC/ano para cada canal de comunicao devido ao consumo de recursos gerais associados comunicao. Assim a produtividade da equipe ser igual a (20.000 - (250x6)) = 18.500 LOC/ano = 7,5% menos do que aquilo que poderamos esperar. Supondo que o projeto de um ano em que a equipe est trabalhando tem o seu cronograma atrasado e restando apenas dois meses, mais duas pessoas so acrescentadas equipe. O nmero de canais de comunicao sobe para 14. A entrada de produtividade do novo pessoal equivalente a 840 x 2 = 1680 LOC para os dois meses at a entrega. A produtividade da equipe agora igual a 20.000 + 1680 (250x14) = 18.180 LOC/ano. 2.4.2. Definio de tarefa e paralelismo Quando mais de uma pessoa est envolvida num projeto de software, provvel que as atividades de desenvolvimento sejam executadas em paralelo. Marcos de referncia ao longo do processo de engenharia de software oferece ao gerente uma indicao do progresso. Um marco de referncia atingido assim que a documentao produzida como parte de uma tarefa de engenharia de software revisada e aprovada. A natureza concorrente das atividades de engenharia de software leva a uma srie de importantes exigncias de cronograma. Uma vez que as tarefas paralelas ocorrem de maneira assncrona, devem ser determinadas as dependncias intertarefas para garantir o contnuo progresso rumo concluso. 2.4.3. Distribuio do esforo Muitas tcnicas de estimativa de projetos produzem a estimativa de pessoas-ms exigidas para o desenvolvimento do software. A figura 12 abaixo ilustra uma distribuio do esforo exigido entre algumas macroatividades do desenvolvimento do software. Esta distribuio enfatiza as tarefas de anlise e projeto realizadas inicialmente e as tarefas de teste realizadas prximo do trmino do projeto.
Anlise e projeto (40 50%)
Atividades de teste e depurao (30-40%)
Codificao (15-20%)
Figura 12 Distribuio do esforo
Esta diviso do esforo proposta deve ser usada como uma diretriz. As caractersticas de cada projeto que devem ditar qual distribuio acomoda melhor para que os objetivos do projeto sejam alcanados dentro do custo e prazo estimados. O esforo gasto com planejamento de projeto raramente responsvel por mais do que 2 a 3% do esforo total, a menos que o plano envolva grandes gastos com riscos. A anlise de requisitos pode envolver de 10 a 25% do esforo de projeto. O esforo dependido em anlise e construo de prottipos deve elevar-se em proporo direta com o tamanho e complexidade do projeto. Em geral de 20 a 25% do esforo total gasto com projeto. Em geral, devido ao esforo empregado em anlise e projeto espera-se que da codificao seja exigido um esforo menor. Os testes podem consumir de 15 a 20%. A condio crtica do software dita a quantidade de testes exigida. Por exemplo, se uma falha no software pode causar a perda de uma vida humana, ento a fase de testes ter um esforo maior. 2.4.4. Mtodos de determinao de cronograma Na especificao de um cronograma devemos estabelecer prazos para o esforo de desenvolvimento. Dois mtodos de determinao de cronograma so: PERT Program Evaluation and Review Technique (mtodo de avaliao e reviso de programa). CPM Critical Path Method (mtodo do caminho crtico). Em ambas as tcnicas existem uma rede de tarefas a serem desenvolvidas desde o comeo at o final do projeto. A rede definida ao se desenvolver uma lista de todas as tarefas associadas a um projeto especfico e uma lista de disposies que indica em que ordem as tarefas devem ser executadas. As duas tcnicas permitem ao planejador de software: Determinar o caminho crtico cadeia de tarefas que determina a durao do projeto. Estabelecer as estimativas de tempo mais provveis para tarefas individuais ao aplicar modelos estatsticos. Calcular limites de tempo que definam uma janela de tempo para uma tarefa em particular. Alguns limites de tempo so definidos tanto para o PERT como para o CPM: O limite mais cedo em que uma tarefa pode iniciar-se quando todas as tarefas precedentes foram completadas no tempo mais curto possvel. O limite mais tarde para o incio da tarefa antes que o tempo de concluso mnimo do projeto seja atrasado. O trmino mais breve a soma do incio mais cedo com a durao da tarefa. O trmino mais tardio a soma do incio mais tardio com a durao da tarefa. A flutuao total a quantidade de supervit de tempo ou de margem de segurana permitida nas tarefas de determinao de prazos de forma que o caminho crtico da rede seja mantido dentro do prazo.
Os clculos do tempo-limite levam determinao do caminho crtico e proporcionam ao gerente um mtodo quantitativo para avaliar o progresso a medida em que as tarefas so concludas. O planejador deve reconhecer que o esforo despendido no software no se encerra ao final do desenvolvimento. O esforo de manuteno, ainda que no seja fcil de programar neste estgio, tornar-se-, por fim, o maior fator de custo. Uma meta primordial da engenharia de software ajudar a reduzir esse custo. 2.4.5. Grfico de Gantt O grfico de Gantt constitui-se de uma tima ferramenta para representar o cronograma do PLANO DO PROJETO. Permite uma comparao entre o previsto e o realizado, mostrando o andamento do projeto no tempo. Ele deve aparecer em dois nveis distintos, no mnimo: Cronograma Mestre - representando as atividades sumrias. Este cronograma d uma viso geral dos prazos do projeto, mostra sua durao total e interessa principalmente ao usurio ou superiores nos nveis estratgicos ou ttico de decises. Cronograma Parcial - representando o detalhamento das atividades sumrias. Este cronograma relaciona as atividades e usa uma escala de tempo menor do que no cronograma mestre, ele interessa mais aos componentes do projeto para controle operacional. O grfico de Gantt mantm o Gerente de Projeto ciente do progresso realizado na execuo do plano. A comparao da execuo com o previsto converte-se simplesmente, em um trabalho de menor nvel e a direo dispe de mais tempo para estudar as tendncias indicadas pelo grfico e agir de maneira mais conveniente. Este tipo de grfico evidencia a quantidade de trabalho executado, se esta quantidade inferior a prevista, indica a quem se deve a responsabilidade pelo xito ou fracasso de uma determinada tarefa ou projeto. O grfico de Gantt muito sinttico e muito fcil de traar e de ler, no apresenta linhas que se cruzam e, todas as anotaes avanam com o tempo, da esquerda para a direita da folha. Apresenta, normalmente, tal continuidade de traado que qualquer interrupo de registro ou qualquer lacuna de informao, relativa ao que se passou, tornase visvel, imediatamente. Torna visvel o transcurso do tempo e, por isso ajuda a reduzir a ociosidade e a perda de tempo. As linhas traadas horizontalmente no grfico representam a relao entre a quantidade de trabalho realizado durante um tempo dado e a quantidade prevista. Este o detalhe caracterstico que distingue o grfico de Gantt de todos os demais grficos de controle: cada coluna e a barra nela traada representam, simultaneamente: Quantidades iguais de tempo Quantidades variveis de trabalho previsto Quantidades variveis de trabalho realizado As vantagens do grfico de Gantt so que ele permite razoavelmente efetuar o planejamento, a programao, o controle, forar a definio de objetivos e responsabilidades; prevenir a omisso de tarefas e apropriar tempo, quantidade de trabalho realizados e as relaes entre tempos e quantidades. Como desvantagens temos a dificuldade de controlar um grande nmero de atividades e em perodo longo (muitas linhas e colunas).
Componentes O grfico de Gantt composto das seguintes variveis: Tarefas unidade de tempo tempo previsto(P) e realizado(R) Exemplo
Figura 13 Grfico de Gantt
2.4.6. Rastreamento e controle de projeto Um dos papis da administrao rastrear e controlar o andamento do projeto. O rastreamento pode ser levado a efeito de diversas formas: 1. Realizando reunies peridicas sobre a situao do projeto. 2. Avaliando-se os resultados de todas as revises levadas a efeito. 3. Determinando se os marcos de referncia foram alcanados at a data programada. 4. Comparando-se a data de incio real com a data de incio planejada para cada tarefa. 5. Reunindo-se informalmente com os profissionais envolvidos para se obter suas avaliaes subjetivas do progresso at o momento e os problemas que aparecem. 2.4.7. Aquisio de software Em muitas reas de aplicao de software, freqentemente mais efetivo em relao ao custo adquirir do que desenvolver software de computador. A deciso de comprar ou produzir pode ser ainda mais complicada por uma srie de opes: O software pode ser comprado ou licenciado. O software pode depois ser modificado para atender necessidades especficas. O software pode ser feito sob encomenda por terceiros para atender s especificaes do comprador.
As etapas envolvidas na aquisio do software dependem de quo crtico o software e o custo final. Se o custo no elevado, em alguns casos vlida a aquisio e a experincia do software para saber se atende s necessidades do cliente. Para pacotes mais caros, as seguintes diretrizes podem ser consideradas: 1. Desenvolva uma especificao funcional e de desempenho do software desejado. 2. Estime um custo interno para desenvolver e a data de entrega. 3. Escolha mais de um pacote de software candidatos. 4. Desenvolva uma matriz de comparao entre os softwares candidatos que confronte entre as funes chaves. 5. Avalie cada pacote de software baseado na qualidade do produto, suporte do vendedor, reputao do fornecedor. 6. Contate outros usurios do software e pea opinies. Na anlise final, a deciso de produzir ou comprar tomada em funo das seguintes condies: A data de entrega do produto precede a data do software desenvolvido internamente? O custo de aquisio e customizao ser menor do que o custo para se desenvolver internamente? O custo do suporte externo ser menor do que o custo do suporte interno? Outros critrios: A entrega e disponibilidade. A conformidade aos requisitos. A probabilidade de mudanas.
Captulo 3 Anlise de Requisitos - 34 -
3. Anlise de requisitos
O completo entendimento dos requisitos de software um ponto fundamental para o sucesso de um projeto de software. Independentemente da preciso com a qual um software venha a ser projetado e implementado, ele certamente trar problemas ao cliente/usurio se a sua anlise de requisitos foi mal realizada. A anlise de requisitos uma tarefa que envolve, antes de tudo, um trabalho de descoberta, refinamento, modelagem e especificao das necessidades e desejos relativos ao software que dever ser desenvolvido. Nesta tarefa, tanto o cliente quanto o desenvolvedor vo desempenhar um papel de grande importncia, uma vez que caber ao primeiro a formulao (de modo concreto) das necessidades em termos de funes e desempenho, enquanto o segundo atua como indagador, consultor e solucionador de problemas. Esta etapa de suma importncia no processo de desenvolvimento de um software, principalmente porque ela estabelece o elo de ligao entre a alocao do software em nvel de sistema (realizada na etapa de Engenharia de Sistema) e o projeto do software.
Engenharia de Sistema Anlise de Requisitos Projeto de Software Figura 14 Representao do vinculo dos requisitos
Desta forma, esta etapa permite: Ao engenheiro de software: - especificar as necessidades do software em termos de funes e de desempenho; - estabelecer as interfaces do software com os demais elementos do sistema e - especificar as restries de projeto. Ao engenheiro de software (analista): - uma alocao mais precisa do software no sistema e - a construo de modelos do processo, dos dados e dos aspectos comportamentais que sero tratados pelo software. Ao projetista: - a obteno de uma representao da informao e das funes que poder ser traduzida em projeto procedimental, arquitetnico e de dados. Alm disso, possvel definir os critrios de avaliao da qualidade do software a serem verificados uma vez que o software esteja concludo. Abaixo na figura 15 um fluxograma das funes que a analise de requisitos deve cumprir:
Figura 15 Fluxograma das funes da anlise de requisitos.
3.1. Atividades da Anlise de Requisitos 3.1.1. Anlise do Problema Nesta fase inicial, o analista estuda os documentos de Especificao do Sistema e o Plano de Software, como forma de entender o posicionamento do software no sistema e revisar o escopo do software utilizado para definir as estimativas de projeto. Um elo de comunicao entre o analista e o cliente deve ser estabelecido. A meta do analista nesta fase identificar os principais fatores do problema a ser resolvido, pela tica do cliente. 3.1.2. Avaliao e Sntese Esta fase envolve a anlise dos fluxos de informao e a elaborao de todas as funes de tratamento e os aspectos de comportamento do software. Ainda, importnate que uma definio de todas as questes relacionadas interface com o sistema, alm de uma especificao das restries do projeto. Terminada a anlise, o analista pode iniciar a sntese de uma ou mais solues para o problema. Na sntese das eventuais solues, o analista deve levar em conta as estimativas e as restries de projeto. Este processo de avaliao e sntese prossegue at que o analista e o cliente estejam de acordo sobre a adequao das especificaes realizadas para a continuidade do processo.
3.1.3. Modelagem A partir da tarefa de avaliao e sntese, o analista pode estabelecer um modelo do sistema, o qual permitir uma melhor compreenso dos fluxos de informao e de controle, assim como dos aspectos funcionais e de comportamento. Este modelo, ainda distante de um projeto detalhado, servir de referncia s atividades de projeto, assim como para a criao da especificao de requisitos. Em muitas situaes como forma de reforar o conhecimento sobre a viabilidade do software a ser desenvolvido, pode ser necessrio o desenvolvimento de um prottipo de software como alternativa ou como trabalho paralelo anlise de requisitos. 3.1.4. Especificao de Requisitos e Reviso A etapa de Anlise de requisitos culmina com a produo de um documento de Especificao de Requisitos de Software, que registra os resultados das tarefas realizadas. Eventualmente, pode ser produzido como documento adicional um Manual Preliminar do Usurio. Embora parea estranho, a produo deste manual permite que o analista passe a olhar para o software da tica do cliente/usurio, o que pode ser bastante interessante, principalmente em sistemas interativos. Alm disso, a posse de um Manual do Usurio, mesmo em estgio preliminar permite ao cliente uma reviso dos requisitos (de interface, pelo menos) ainda num estgio bastante prematuro do desenvolvimento de software. Desta forma, algumas decepes resultantes de uma m definio de alguns aspectos do software podem ser evitadas. 3.2. Processos de comunicao O desenvolvimento de um software , na maior parte das vezes, motivado pelas necessidades de um cliente que deseje automatizar um sistema existente ou obter um novo sistema completamente automatizado. O software, porm, desenvolvido por um desenvolvedor ou por uma equipe de desenvolvedores. Uma vez desenvolvido, o software ser provavelmente utilizado por usurios finais, os quais no so necessariamente os clientes que originaram o sistema. De fato, existem trs partes envolvidas no processo de desenvolvimento de um produto de software: o cliente, o desenvolvedor e os usurios. Para que o processo de desenvolvimento seja conduzido com sucesso, necessrio que os desejos do cliente e as expectativas dos eventuais usurios finais do sistema sejam precisamente transmitidos ao desenvolvedor. Este processo de transmisso de requisitos, do cliente e dos usurios ao desenvolvedor, invariavelmente apresenta relativa dificuldade, considerando alguns aspectos: - geralmente, os clientes no entendem de software ou do processo de desenvolvimento de um programa; - o desenvolvedor, usualmente, no entende do sistema no qual o software cao executar. A boa comunicao entre a equipe de desenvolvimento e o cliente fundamental para a realizao de sucesso da atividade de anlise de requisitos. Nem sempre a boa comunicao alcanada devido aos motivos j citados.
No incio do processo, em geral, uma entrevista realizada entre o cliente e o desenvolvedor. Durante as primeiras entrevistas com o cliente, o analista pode comear fazendo perguntas que levem a uma compreenso bsica dos seguintes pontos: a) O problema. b) Pessoas que querem uma soluo. c) Natureza da soluo desejada. O primeiro conjunto de perguntas concentra-se no cliente, nas metas globais e nos benefcios. Por exemplo: a) Quem est por trs do pedido deste trabalho? b) Quem usar a soluo? c) Qual o benefcio econmico de uma soluo bem-sucedida? d) H outra fonte para a soluo exigida? O prximo conjunto de perguntas possibilita ao analista compreender melhor o problema e ao cliente expressar sua percepo sobre uma soluo: a) Como voc caracterizaria um bom resultado que seria gerado por uma soluo bem sucedida? b) Qual(is) problema(s) essa soluo resolver? c) Voc poderia mostrar-me o ambiente em que a soluo ser usada? d) Existem questes de desempenho ou restries especiais que afetaro a maneira pela qual a soluo abordada? Outro conjunto de perguntas concentra-se na efetividade da entrevista: a) Voc a pessoa certa para responder estas perguntas? Suas resposta so oficiais? b) Minhas perguntas so pertinentes ao problema que voc tem? c) Estou fazendo perguntas demais? d) H mais algum que possa fornecer informaes adicionais ? e) Existe algo que eu deva perguntar-lhe? Estas perguntas podem auxiliar a introduzir uma comunicao para conduzir uma anlise de requisitos bem sucedida. Entretanto, esta forma de encontro onde o analista faz uma srie de perguntas e o cliente responde no deve persistir nas demais reunies que acontecero. Elementos que combinam soluo, negociao e especificao devem ser abordados. 3.2.1. Tcnicas facilitadas para especificao de aplicaes. Realizar um levantamento de requisitos tendo em mente um trabalho dividido em duas equipes clientes e desenvolvedores - tem demonstrado no ser uma abordagem de sucesso. Se cada pessoa define seu territrio e se comunica com a outra atravs de documentos, sesses de perguntas e respostas,... ocasiona mal-entendidos, omisso de informaes importantes e isso contribui para a falta do sucesso em um trabalho.
A fim de solucionar estes problemas, pesquisadores desenvolveram uma abordagem coleta de exigncias orientada equipes a qual aplicada durante as primeiras etapas da anlise e especificao. Denominada Tcnica Facilitada para Especificao de Aplicaes (Facilitaded Application Specification Techniques - FAST), esta abordagem estimula a criao de uma equipe conjunta de clientes e desenvolvedores a trabalharem juntos para: a) identificar o problema, b) propor elementos de soluo, c) negociar diferentes abordagens e e)especificar um conjunto preliminar de requisitos de soluo. Outras abordagens so propostas como, por exemplo, JAD (Joint Application Development Desenvolvimento Conjunto de Aplicao), desenvolvido pela IBM e The Method Performance Resources, Inc. Independente da tcnica de entrevista entre as equipes, todas seguem estas diretrizes: a) Encontro realizado em local neutro e contando com a participao de clientes e desenvolvedores. b) Regras para preparao e participao so estabelecidas. c) Uma agenda que seja formal o bastante para cobrir todos os pontos importantes, mas informal o suficiente para encorajar o livre fluxo de idias. d) Designar um moderador para controlar a reunio. e) Meta: identificar o problema, propor elementos de soluo, negociar diferentes abordagens e especificar um conjunto preliminar de requisitos de soluo. Ento, inicialmente desenvolvedores e clientes se renem com o objetivo de perceber o escopo do problema e uma soluo. Uma requisio de produto elaborada. Uma data e um lugar so marcados para a realizao da FAST. Um moderador designado. Clientes e desenvolvedores so convidados e uma cpia da requisio do produto distribuda para cada participante antes da data da reunio. Cada participante solicitado a fazer uma lista de objetos que: a) fazem parte do ambiente que interage com o sistema, b) so produzidos pelo sistema, c) so usados para que o sistema execute suas funes. 3.3. Princpios da anlise Pesquisadores desenvolveram vrios mtodos de anlise e especificao de software identificando problemas e suas causas. Cada mtodo tem suas caractersticas que so nicas mas todos compartilham alguns princpios fundamentais: 1) O domnio da informao deve ser representado e compreendido. -> a funo pode ser entendida melhor. 2) Modelos que descrevam a informao, funo e comportamento devem ser desenvolvidos. -> comunicao de forma resumida. 3) Modelos devem ser divididos em parties de tal forma que revele detalhes em camadas. -> reduo da complexidade.
4) O processo de anlise deve mover-se da informao essencial para os detalhes de implementao. 3.3.1. O domnio da informao Composto por dados e eventos. Para entender o domnio da informao cada um destes trs pontos de vista deve ser considerado para dados e eventos: a) fluxo da informao: representa a maneira pela qual os dados e eventos se modificam medida que cada um se movimenta pelo sistema. Ao longo deste caminho, novas informaes podem ser introduzidas a partir de um depsito. Uma entrada pode ser transformada em informaes intermedirias at alcanar a sada. b) contedo da informao: representa os dados e os itens de controle que compem um determinado item de informao mais amplo. c) estrutura da informao: representa a organizao interna dos dados que compe um item de informao. 3.3.2. Modelagem Obter maior compreenso do que deve ser construdo. Os modelos devem ser capazes de modelar a informao que o software transforma, as funes que possibilitam as transformaes e o comportamento do sistema quando a transformao est ocorrendo. Durante a anlise de requisitos construmos modelos que se concentram naquilo que o software deve fazer e no como ele deve fazer. Papis dos modelos criados durante a anlise dos requisitos: a) Ajuda o analista a entender a informao, funo e o comportamento. b) Torna-se ponto principal para reviso. c) Torna-se base para o projeto a qual pode ser mapeada para um contexto de implementao. 3.3.3. Particionamento Muitas vezes, os problemas a serem resolvidos so excessivamente complexos, apresentando grande dificuldade para a sua compreenso (e conseqente resoluo) como um todo. Para dominar de forma completa os problemas sob anlise, um princpio fundamental a decomposio em parte menores particionamento. A partir do particionamento de um problema e a partir da anlise de cada parte estabelecida, o entendimento fica mais facilitado. Desta forma, possvel estabelecer as interfaces de cada parte do problema de modo que a funo global do software seja realizada. O procedimento bsico de particionamento o estabelecimento de uma estrutura hierarquizada de representao da funo ou da informao, dividindo em parties o elemento superior, podendo esta diviso ser efetuada segundo uma abordagem vertical (deslocando-se verticalmente na hierarquia) ou horizontal. As figuras a seguir representam a aplicao sobre um exemplo das abordagens horizontal e vertical, respectivamente.
Neste o particionamento realizado sobre o aspecto funcional do software, mas poderia ser aplicado segundo uma abordagem sobre os aspectos informacionais ou comportamentais, por exemplo.
3.3.4. Concepes essenciais e de implementao A concepo essencial dos requisitos apresenta funes a serem executadas e as informaes a serem processadas sem levar em considerao detalhes de implementao. Considerando o exemplo da figura anterior, a concepo essencial da funo ler status ignora o formato dos dados de status ou o tipo de sensor que ser utilizado. A vantagem de realizar a concepo essencial de deixar em aberto as alternativas de implementao possveis, o que adequado para as atividades iniciais do desenvolvimento. A concepo de implementao dos requisitos de software apresenta a manifestao de funes de processamento e estruturas de informao do sistema real. Em alguns casos, uma representao fsica o ponto de partida da etapa de projeto do software mas, na maioria dos casos, grande parte dos sistemas computacionais especificada acomodando alguns detalhes de implementao. O conhecimento de alguns destes detalhes pode auxiliar o analista (e, em seguida, o projetista) na definio de restries impostas ao software pelo sistema. 3.4. Prototipao de software Em certas situaes um modelo do software baseado na especificao de anlise pode ser construdo. Outros casos, um prottipo precisa ser usado no incio da anlise para derivar as exigncias do software. Um panorama de prototipao:
Assim que um pedido para a construo de um software realizado, alguns passos podem ser aplicados para se a fim de utilizar a prototipao de software: Passo 1) Avaliar o pedido de software verificando se bom candidato prototipao: a) rea de aplicao. b) Caractersticas do cliente. c) Caractersticas do projeto. Interao homem-mquina muito forte. Muito processamento. Complexidade pode fazer com que o software no seja forte candidato a prototipao. Idia: dividir a complexidade em parties. Uma vez que o cliente deve interagir com o prottipo em etapas posteriores necessrio que recursos do cliente sejam comprometidos com avaliao e aprimoramento do prottipo. Outra questo: Experincia com mtodos de prototipao ? Ferramentas de prototipao esto disponveis ? Passo 2) Dado um projeto aceitvel, o analista desenvolve uma representao abreviada dos requisitos gerando um modelo de requisitos. Passo 3) Revisar o modelo de requisitos e criar uma especificao de projeto abreviada. Passo 4) Criar, testar e aprimorar o software prottipo. Passo 5) Apresentar o prottipo ao cliente. Deixar que o cliente dirija o teste da aplicao e faa sugestes. Passo 6) Repetir os passos 4 e 5 at que todas as exigncias sejam contempladas. 3.4.1. Mtodos e ferramentas de prototipao Para executar a prototipao de forma efetiva, um prottipo deve ser construdo rapidamente para a avaliao do cliente e futuras modificaes. Trs classes genricas de mtodos e ferramentas esto disponveis: a) Tcnicas de quarta gerao abrange linguagens de gerao de relatrios e de consulta ao banco de dados, geradores de aplicaes e programas, linguagens no procedimentais... b) Componentes reusveis os quais permitem a montagem do prottipo a partir de blocos de construo, dos quais no se conhece necessariamente o seu funcionamento
interno, mas as suas funes e interfaces so dominadas pelo analista. O uso desta tcnica s possvel a partir da construo (ou existncia) de uma biblioteca de componentes reusveis, catalogados para posterior recuperao; em alguns casos um software existente pode ser adotados como prottipo para a construo de um novo produto, mais competitivo e eficiente, o que define uma forma de reusabilidade de software. c) Especificaes formais e ambientes de prototipao, que surgiram em substituio s tcnicas baseadas em linguagem natural. As vantagens da utilizao destas tcnicas so, basicamente, a representao dos requisitos de software numa linguagem padro, a gerao de cdigo executvel a partir da especificao e a possibilidade de validao (da parte do cliente) de modo a refinar os requisitos do software. 3.5. Especificao O modo de especificao reflete na qualidade da soluo. Ela representa o que deve ser implementado. Princpios da especificao: 1) Separe funcionalidade de implementao. 2) Uma linguagem de especificao de sistemas orientada ao processo exigida expressar o comportamento de certas partes do sistema. 3) Deve levar em conta o sistema do qual o software faz parte e o ambiente no qual o sistema vai operar. 4)Deve ser um modelo cognitivo. Deve descrever o sistema da forma como ele percebido pela comunidade de usurios. As entidades que manipula devem pertencer ao domnio do problema. Pessoas, equipamentos, ... que fazem parte do domnio devem ser modelados. 6) Deve ser operacional, no sentido de que ela deve permitir, mesmo num nvel de abstrao elevado, algum tipo de validao; 7) Deve ser localizada e fracamente acoplada. O que so requisitos fundamentais para permitir a realizao de modificaes durante a anlise de requisitos. A figura 16 a seguir apresenta uma proposta de estrutura para o documento de Especificao dos Requisitos do Software.
Figura 16 Documento da especificao de requisitos
O documento inicia com uma introduo, que apresenta as principais metas do software, descrevendo o seu papel no contexto do sistema global. As informaes prestadas nesta seo podem ser, inclusive, inteiramente extradas do documento de plano de software. A Descrio da Informao deve apresentar informaes sobre o problema que o software deve resolver. Os fluxos e a estrutura das informaes devem ser descritos nesta seo (utilizando um formalismo adequado, como, por exemplo, os DFDs e os Dicionrios de Dados), assim como os elementos relacionados s interfaces internas e externas do software (incluindo hardware, elementos humanos, outros softwares, etc.). A Descrio Funcional apresenta as informaes relativas s funes a serem providas pelo software, incluindo uma descrio dos processamentos envolvidos no funcionamento de projeto, detectadas nesta etapa. Critrios de Validao, vai estabelecer os parmetros que permitiro avaliar se a implementao do software vai corresponder soluo desejada para o problema. Definir os critrios de validao significa ter um entendimento completo dos requisitos funcionais e de processamento de informao do software. Uma definio importante a ser encaminhada nesta seo o conjunto de testes que dever ser aplicado implementao para que se tenha uma garantia do funcionamento do software nos moldes estabelecidos pela especificao de requisitos. Finalmente devem ser registrados neste documento a lista de documentos relacionados ao software a ser desenvolvido (Plano de Software, por exemplo) e uma seo de Apndices, onde podem ser apresentadas informaes mais detalhadas sobre a especificao do software (descrio detalhada de algoritmos, diagramas, grficos, etc.). Um outro aspecto interessante, no apresentado na figura, refere-se a quando um software ter caractersticas de interatividade com usurios. Neste caso, interessante que um Manual do Usurio (em verso preliminar) seja elaborado, o qual vai conduzir a duas conseqncias positivas: forar o analista a enxergar o software do ponto de vista do usurio e permitir ao cliente uma avaliao do que ser o software nesta etapa de desenvolvimento. 3.6. Anlise estruturada A Anlise Estruturada ou SSA (para Structured System Analisis) foi desenvolvida em meados dos anos 70 por Gane, Sarson e De Marco. A tcnica SSA baseada na utilizao de uma linguagem grfica para construir modelos de um sistema, incorporando tambm conceitos relacionados s estruturas de dados.

Apostila Eng SW

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Apostila Eng SW

Uploaded by

Copyright:

Available Formats

UNIVERSIDADE DO OESTE DE SANTA CATARINA CAMPUS XANXER Curso: Tecnologia em Informtica Disciplina: Engenharia de Software Professor: Andr Luiz

APOSTILA ENGENHARIA DE SOFTWARE

Captulo 1 Introduo a engenharia de software - 3 -

Quadro 1 Evoluo do software(fonte Pressmam, pg.5).

de O fato da empresa ter hardware de ltima gerao no garante

Captulo 1 Introduo a engenharia de software - 5 -

Quadro 5 Perguntas freqentes sobre engenharia

Captulo 1 Introduo a engenharia de software - 6 -

Captulo 1 Introduo a engenharia de software - 7 -

Figura 1 Ciclo de Vida clssico

Captulo 1 Introduo a engenharia de software - 8 -

ESPECIFICAO DESCRIO ESBOO

Verso Inicial Verso intermediria Verso Final

Captulo 1 Introduo a engenharia de software - 9 -

Integrao e testes de sistema

Figura 3 Desenvolvimento formal de sistemas.(fonte sommerville, pg.40).

Captulo 1 Introduo a engenharia de software - 10 -

Na figura 4 abaixo podemos observar o modelo orientado a reuso.

Captulo 1 Introduo a engenharia de software - 11 -

Definir esboo dos requisitos

Atribuir requisitos aos incrementos

Projetar arquitetura do sistema

Desenvolver incremento do sistema

Figura 5- Desenvolvimento incremental (fonte sommerville, pg.42).

Figura 6- Modelo espiral

Captulo 2 Projeto de software - 12 -

Captulo 2 Projeto de software - 13 -

Figura 7 Plano de projeto(fonte Pressman, pg.168)

2.1.1. Iniciando um projeto de software (Contexto) Segundo (Pressman, pg55),

Captulo 2 Projeto de software - 14 -

Captulo 2 Projeto de software - 15 -

Tabela 1- Mtricas Orientadas ao Tamanho

Captulo 2 Projeto de software - 16 -

Figura 8 Mtricas orientada a funo

Captulo 2 Projeto de software - 17 -

Tabela 2 Pontos para os fatores

Captulo 2 Projeto de software - 18 -

Figura 9 pontos de particularidade

Tabela 3- Reconciliao entre diferentes abordagens de mtricas

Captulo 2 Projeto de software - 19 -

Captulo 2 Projeto de software - 20 -

Captulo 2 Projeto de software - 21 -

Captulo 2 Projeto de software - 22 -

Captulo 2 Projeto de software - 23 -

Captulo 2 Projeto de software - 25 -

Captulo 2 Projeto de software - 26 -

Captulo 2 Projeto de software - 27 -

Figura 11 Gerenciamento dos riscos

Captulo 2 Projeto de software - 28 -

Captulo 2 Projeto de software - 29 -

Anlise e projeto (40 50%)

Atividades de teste e depurao (30-40%)

Figura 12 Distribuio do esforo

Captulo 2 Projeto de software - 30 -

Captulo 2 Projeto de software - 31 -

Captulo 2 Projeto de software - 32 -

Figura 13 Grfico de Gantt

Captulo 2 Projeto de software - 33 -

Captulo 3 Anlise de Requisitos - 34 -

Captulo 3 Anlise de Requisitos - 35 -

Figura 15 Fluxograma das funes da anlise de requisitos.

Captulo 3 Anlise de Requisitos - 36 -

Captulo 3 Anlise de Requisitos - 37 -