engenharia de software - uniasselvi

2013

EngEnharia dE Software

Prof. Djone Kochanski

Copyright © UNIASSELVI 2013

Elaboração:


Revisão, Diagramação e Produção:

Centro Universitário Leonardo da Vinci – UNIASSELVI

Ficha catalográfica elaborada na fonte pela Biblioteca Dante Alighieri

UNIASSELVI – Indaial.

K766eKochanski, Djone

Engenharia de software / Djone Kochanski. Indaial : Uniasselvi, 2013.

172 p. : il

ISBN 978-85-7830-753-0

1. Engenharia de software. I. Centro Universitário Leonardo da Vinci.

COD 005.102

Impresso por:

III

aprEsEntaçãoCaro(a) acadêmico(a)! Seja bem-vindo à disciplina de Engenharia de

Software!

Você está iniciando os estudos de uma das disciplinas mais fascinantes da área de Computação/Informática. Ela é especial em função da amplitude de abrangência, quando software está em pauta. Nesta disciplina, você estudará importantes conceitos relacionados a aspectos técnicos da construção de software, bem como os aspectos gerenciais que envolvem o processo de software.

O conteúdo deste Caderno de Estudos foi elaborado de forma a permitir uma visão adequada dos principais elementos relacionados à Engenharia de Software. Este conteúdo servirá como base para aprofundamentos nas demais subáreas deste campo de conhecimento.

O campo da Engenharia de Software é bastante amplo, englobando, desde aspectos técnicos como arquitetura de software até métodos para gestão de pessoas em projetos. É uma importante área de conhecimento que poderá servir de fonte de informação para outras áreas, mesmo que não estejam relacionadas ao desenvolvimento de software.

Este Caderno de Estudos está dividido em três unidades. Iniciaremos nossos estudos a partir de uma perspectiva histórica da Engenharia de Software, complementando com importantes conceitos da área. Em seguida, estudaremos conceitos-chave relativos a Projetos de Software, uma das subáreas mais importantes da Engenharia de Software. Por fim, estudaremos importantes conceitos relativos à qualidade de software.

Desejo a você uma excelente experiência nos estudos dos conteúdos dessa disciplina!


IV

Você já me conhece das outras disciplinas? Não? É calouro? Enfim, tanto para você que está chegando agora à UNIASSELVI quanto para você que já é veterano, há novidades em nosso material.

Na Educação a Distância, o livro impresso, entregue a todos os acadêmicos desde 2005, é o material base da disciplina. A partir de 2017, nossos livros estão de visual novo, com um formato mais prático, que cabe na bolsa e facilita a leitura.

O conteúdo continua na íntegra, mas a estrutura interna foi aperfeiçoada com nova diagramação no texto, aproveitando ao máximo o espaço da página, o que também contribui para diminuir a extração de árvores para produção de folhas de papel, por exemplo.

Assim, a UNIASSELVI, preocupando-se com o impacto de nossas ações sobre o ambiente, apresenta também este livro no formato digital. Assim, você, acadêmico, tem a possibilidade de estudá-lo com versatilidade nas telas do celular, tablet ou computador. Eu mesmo, UNI, ganhei um novo layout, você me verá frequentemente e surgirei para apresentar dicas de vídeos e outras fontes de conhecimento que complementam o assunto em questão.

Todos esses ajustes foram pensados a partir de relatos que recebemos nas pesquisas institucionais sobre os materiais impressos, para que você, nossa maior prioridade, possa continuar seus estudos com um material de qualidade.

Aproveito o momento para convidá-lo para um bate-papo sobre o Exame Nacional de Desempenho de Estudantes – ENADE. Bons estudos!

NOTA

VII

UNIDADE 1 – PROCESSOS E REQUISITOS DE SOFTWARE ...................................................... 1

TÓPICO 1 – FUNDAMENTOS DE ENGENHARIA DE SOFTWARE ........................................... 31 INTRODUÇÃO ..................................................................................................................................... 32 PERSPECTIVA HISTÓRICA DA ENGENHARIA DE SOFTWARE ........................................... 43 ENGENHARIA DE SOFTWARE ........................................................................................................ 11RESUMO DO TÓPICO 1........................................................................................................................ 17AUTOATIVIDADE ................................................................................................................................. 18

TÓPICO 2 – PROCESSOS DE SOFTWARE ........................................................................................ 191 INTRODUÇÃO ..................................................................................................................................... 192 CICLOS DE VIDA DE SOFTWARE .................................................................................................. 223 MODELO CLÁSSICO .......................................................................................................................... 244 MODELO ESPIRAL ............................................................................................................................. 275 MODELO PROTOTIPAÇÃO ............................................................................................................. 296 MODELO RAD ..................................................................................................................................... 317 MODELO DE QUARTA GERAÇÃO ................................................................................................ 328 MODELO ALTERNATIVO ................................................................................................................. 35RESUMO DO TÓPICO 2........................................................................................................................ 38AUTOATIVIDADE ................................................................................................................................. 39

TÓPICO 3 – REQUISITOS DE SOFTWARE ....................................................................................... 411 INTRODUÇÃO ..................................................................................................................................... 412 REQUISITOS ......................................................................................................................................... 42LEITURA COMPLEMENTAR ............................................................................................................... 52RESUMO DO TÓPICO 3........................................................................................................................ 62AUTOATIVIDADE ................................................................................................................................. 63

UNIDADE 2 – DESIGN E DESENVOLVIMENTO DE SOFTWARE ............................................. 65

TÓPICO 1 – DESIGN DE SOFTWARE ................................................................................................. 671 INTRODUÇÃO ..................................................................................................................................... 672 TIPOS DE DESIGN ............................................................................................................................... 683 ARQUITETURA DE SOFTWARE ...................................................................................................... 704 MODULARIDADE ............................................................................................................................... 725 DESIGN DE INTERFACES COM O USUÁRIO ............................................................................. 746 INDEPENDÊNCIA DOS COMPONENTES ................................................................................... 76RESUMO DO TÓPICO 1........................................................................................................................ 78AUTOATIVIDADE ................................................................................................................................. 79

TÓPICO 2 – DESENVOLVIMENTO DE SOFTWARE ...................................................................... 811 INTRODUÇÃO ..................................................................................................................................... 812 PADRÕES DE CODIFICAÇÃO ......................................................................................................... 813 NOTAÇÕES ........................................................................................................................................... 87

sumário

VIII

4 ESTILOS DE Indentação ..................................................................................................................... 89RESUMO DO TÓPICO 2........................................................................................................................ 97AUTOATIVIDADE ................................................................................................................................. 98

TÓPICO 3 – GERENCIAMENTO DE PROJETOS DE SOFTWARE .............................................. 991 INTRODUÇÃO ..................................................................................................................................... 992 ABRANGÊNCIA DO GERENCIAMENTO DE PROJETOS ........................................................ 1003 DEFINIÇÃO DE PAPÉIS E RESPONSABILIDADES ................................................................... 1034 FUNÇÕES E RESPONSABILIDADES ............................................................................................. 1035 GESTÃO DE PESSOAS ....................................................................................................................... 105LEITURA COMPLEMENTAR ............................................................................................................... 112RESUMO DO TÓPICO 3........................................................................................................................ 117AUTOATIVIDADE ................................................................................................................................. 118

UNIDADE 3 – QUALIDADE DE SOFTWARE ................................................................................... 119

TÓPICO 1 – INTRODUÇÃO À QUALIDADE DE SOFTWARE .................................................... 1211 INTRODUÇÃO ..................................................................................................................................... 1212 FUNDAMENTOS DE QUALIDADE DE SOFTWARE .................................................................. 1223 MELHORIA DA QUALIDADE ......................................................................................................... 129RESUMO DO TÓPICO 1........................................................................................................................ 137AUTOATIVIDADE ................................................................................................................................. 138

TÓPICO 2 – MEDIÇÃO DE SOFTWARE ............................................................................................ 1391 INTRODUÇÃO ..................................................................................................................................... 1392 MODELO GQM .................................................................................................................................... 1403 MODELO PSM ...................................................................................................................................... 159LEITURA COMPLEMENTAR ............................................................................................................... 162RESUMO DO TÓPICO 2........................................................................................................................ 165AUTOATIVIDADE ................................................................................................................................. 166REFERÊNCIAS ......................................................................................................................................... 167

1

UNIDADE 1

PROCESSOS E REQUISITOS DE SOFTWARE

OBJETIVOS DE APRENDIZAGEM

PLANO DE ESTUDOS

Esta unidade tem por objetivos:

• compreender os conceitos fundamentais da Engenharia de Software;

• entender a área de Engenharia de Software de maneira sistêmica;

• compreender os principais processos de software;

• conhecer a importância de requisitos de software.

Esta unidade está dividida em três tópicos, sendo que ao final de cada um deles, você encontrará atividades que lhe auxiliarão na apropriação de conhecimentos.

TÓPICO 1 – FUNDAMENTOS DE ENGENHARIA DE SOFTWARE

TÓPICO 2 – PROCESSOS DE SOFTWARE

TÓPICO 3 – REQUISITOS DE SOFTWARE

3

TÓPICO 1UNIDADE 1

FUNDAMENTOS DE ENGENHARIA DE SOFTWARE

1 INTRODUÇÃOQuando se fala em Engenharia de Software, logo se imagina que, por se

tratar de uma engenharia, tenha um cunho técnico relativamente alto. Porém, embora as questões técnicas precisem ser consideradas, elas são apenas meios para atingir os objetivos. Para a Engenharia de Software o computador, a teoria da computação e até mesmo os algoritmos, são apenas ferramentas necessárias para prover a solução para um problema (PFLEEGER, 2004).

A Engenharia de Software tem como enfoque lidar com os aspectos de produção de software em todas as fases do seu ciclo de vida (SOMMERVILLE, 2003). O ciclo de vida de um software inicia no momento em que são registradas as primeiras especificações de funcionamento, até o momento em que o software deixa de ser utilizado pelos seus usuários. Isso significa que tipicamente um software possui um ciclo de vida longo, se considerarmos o esforço necessário para a produção de um software.

Por outro lado, a Engenharia de Software pode ser vista como um framework para o planejamento, conceituação e projeto de software (PETERS; PEDRYCS, 2001). Na abordagem de framework pode-se considerar o conjunto de aspectos construtivos, seus desafios e considerações sobre produzir tudo ou adquirir partes e fazer com que as mesmas funcionem de maneira harmoniosa.

Acrescentaria ainda a estas, a abordagem de gestão das pessoas que realizam os processos de software. A produção de software é altamente dependente de pessoas e seus talentos e habilidades, logo, também é tarefa da Engenharia de Software a gestão adequada desse importante componente. “A adição de recursos humanos a um projeto de software atrasado irá atrasá-lo ainda mais”. (BROOKS, 2009, p. 24). Considerando que a afirmação de Brooks é verdadeira, incorporar novos elementos à equipe ou substituir componentes desta, pode comprometer severamente o resultado final de um projeto de software.

O fato é que, independente da abordagem que se utilize, a Engenharia de Software lida com desafios constantemente. Produzir algo que ninguém sabe o que e como será, de forma que não se pode demonstrar de maneira precisa. Isso é no mínimo um trabalho a ser respeitado.

UNIDADE 1 | PROCESSOS E REQUISITOS DE SOFTWARE

4

2 PERSPECTIVA HISTÓRICA DA ENGENHARIA DE SOFTWARE

Ao iniciarmos os estudos de uma nova área de conhecimento, uma das primeiras dúvidas que temos é sobre sua origem e evolução que a trouxe ser o que é nos dias atuais. Refletindo sobre a origem da área de Engenharia de Software, pode-se iniciar a partir de seu nascimento formal que ocorreu no início da década de 1970 ou buscarmos raízes mais profundas lá no século XIX.

Almeida (2002) nos ensina que em 1843, Lady Ada, uma condessa considerada gênio na área da matemática trabalhou com Charles Babbage no desenvolvimento da máquina analítica, tratando dos conceitos relacionados às instruções que deveriam ser executadas. Na época, este conjunto de instruções era conhecido como sub-rotina. Nascia então o conceito das instruções de sequência, seleção e repetição. Estes conceitos podem ser considerados as raízes mais profundas do que conhecemos atualmente por software.

FIGURA 1 – MÁQUINA ANALÍTICA DE CHARLES BABBAGE

FONTE: O autor

A máquina proposta do Babbage foi concebida em uma época que a tecnologia disponível era apenas dispositivos mecânicos. Por conta dessa limitação tecnológica não foi possível concluir o projeto que ficou inacabado. Independente disso, os conceitos de Babbage e Ada foi de grande valia para a evolução tecnológica para chegarmos ao estágio atual.

A partir destes conceitos fundamentais, foram construídos os alicerces do funcionamento dos softwares. A primeira aplicação de processamento de dados em grande escala foi realizada no final do século XIX. Na oportunidade foram tabulados os dados do censo americano de 1890 através de máquinas concebidas por Herman Hollerith. Nestas máquinas os dados eram representados sob a forma de perfurações devidamente posicionadas em fita de papel.

TÓPICO 1 | FUNDAMENTOS DE ENGENHARIA DE SOFTWARE

5

Neste momento da história não se diferenciava com clareza o que era hardware e o que era software, pois os equipamentos eram basicamente eletromecânicos. Na realidade o termo software foi criado apenas na década de 1940 como forma de diferenciar a parte lógica da física de um sistema computacional.

FIGURA 2 – MÁQUINA TABULADORA DE HOLLERITH

FONTE: O autor

O terceiro grande marco fundamental para a área é plantado por Alan Turing no ano de 1937 ao propor um modelo de ações a serem realizadas por um tipo especial de máquina. “A Máquina Universal de Turing é capaz de calcular qualquer coisa que seja calculável”. (FOROUZAN; MOSHARRAF, 2011, p. 4).

A partir daqui o software deixa de ser apenas um conceito e passa a ter utilidade em uma máquina que o executa de forma autônoma. É aí que os desafios enfrentados atualmente pela Engenharia de Software tem sua origem. Embora neste momento o conceito de Engenharia de Software estivesse longe de ser formalizado.

O momento da criação do conceito de máquina universal é muito especial para a área de computação/informática, pois é uma espécie de “big bang“ a partir do qual surge um grande ciclo evolutivo de tecnologia. Turing defendia a teoria de que “todo problema desde que expresso de maneira lógica apropriada, poderia sempre ser resolvido”. (STRATHERN, 2000, p. 53).


6

FIGURA 3 – ALAN MATHISON TURING

FONTE: Disponível em: <www.computerhistory.org>. Acesso em: 10 mar. 2012.

Seguindo a corrente de evolução, foram criados os computadores eletromecânicos e posteriormente os eletrônicos. Um dos mais conhecidos é o ENIAC (Eletronic Numeric Integrator and Calculator), criado pelos Professores John William Mauchly e John Pesper Eckert Jr. da Universidade da Pensilvânia. O ENIAC entrou em operação no ano de 1946 (ALMEIDA, 2002). Naquele momento da história, os computadores executavam instruções com base em painéis de chaveamento.

Em seguida passou-se a realizar codificação com instruções de máquina, até que surgem as linguagens de programação. Uma das primeiras linguagens de programação consideradas na época de alto nível foi criada por John Mauchly em 1949 e denominada de Short Order Code. Na década de 1950, as principais linguagens de programação em uso eram APT, FORTRAN e FLOW-MATIC.

Logo surgiu a necessidade de uma linguagem de programação simples e padronizada para aplicações comerciais. Cria-se então a partir da linguagem Flow-Matic de Grace Murray Hopper o COBOL (Common Business Oriented Language). Grace Hopper compôs a equipe que desenvolveu o COBOL e por sua contribuição à humanidade, merece nosso respeito e admiração.

As linguagens de programação permitiram o desenvolvimento de softwares cada vez mais sofisticados e com quantidade crescente de funcionalidades. À medida que a complexidade e quantidade de funcionalidades crescia, também era crescente o volume de problemas enfrentados com a qualidade do software que estava sendo produzido.


7

FIGURA 4 – GRACE MURRAY HOPPER

FONTE: Disponível em: <www.computerhistory.org>. Acesso em: 10 mar. 2012.

A situação da indústria de software ao final da década de 1960 estava complicada. Os usuários e desenvolvedores enfrentavam diversos problemas relacionados ao processo de desenvolvimento. Estes problemas estavam intimamente ligados a como os softwares eram construídos, implantados e mantidos, bem como ao crescimento das demandas e problemas comportamentais. A esta situação denominou-se crise de software (MAFFEO, 1992). A crise de software é ocasionada por um conjunto de problemas que podem abranger (REZENDE, 1997):

• como softwares são construídos;• como softwares são implantados, sejam novos ou substituindo softwares

anteriores;• como softwares são mantidos, dada a crescente demanda e complexidade;• como as necessidades e demandas dos usuários são atendidas;• como as questões comportamentais, políticas, culturais e filosóficas são

tratadas.

A crise de software é reconhecida no momento que uma aplicação de software não satisfaz as necessidades das pessoas para as quais foi projetado. Estas pessoas podem abranger não apenas os usuários do software, mas também todas as demais pessoas afetadas pelas consequências geradas pela não realização adequada da funcionalidade para a qual o software foi projetado. Alguns exemplos de afetados são os desenvolvedores do software, os usuários diretos e indiretos, os administradores de negócios, entre outros.


8

Os principais fatores que levam à ocorrência da crise de software são aqueles diretamente relacionados à maneira como as aplicações de software são construídas, implantadas e mantidas. Além disso, a crise de software pode ocorrer quando as demandas de necessidades não são atendidas, seja por baixa produtividade, seja pela alta demanda de soluções de software para atender às necessidades de negócio. As questões comportamentais relacionadas ao processo de software também podem levar ao que se denomina crise de software.

Ao examinarmos algumas possíveis causas da crise de software podemos nos deparar com diversas. A cada dia que passa é crescente a necessidade de soluções de software mais eficientes. Além disso, a velocidade que os requisitos dos usuários mudam é tipicamente maior do que a equipe de desenvolvimento é capaz de atender. Pfleeger (2004, p. 111) nos ensina que “um requisito é uma característica do sistema ou a descrição de algo que o sistema é capaz de realizar, para atingir os seus objetivos”.

A velocidade de mudança nos requisitos, muitas vezes, vem de origens não controladas, como mudanças de legislação, normas ou processos aos quais as empresas estejam subordinadas. Neste caso podemos compreender que a crise de software pode ocorrer por fatores internos e teoricamente controláveis, bem como externos, ou seja, sobre os quais não exercemos qualquer controle.

É possível ainda que a complexidade da mudança imposta seja alta, requerendo maior tempo para sua realização. Muitos projetos de software nascem com prazos definidos antes mesmo de se ter os principais requisitos levantados. Isto definitivamente é algo que pode comprometer significativamente o processo de desenvolvimento. Um projeto de software iniciado com requisitos incompletos fatalmente terá um design deficitário.

Caro acadêmico! Neste Caderno de Estudos, o termo design é utilizado para designar a fase do ciclo de vida de software em que é realizada a definição de como o produto (software) será construído do ponto de vista técnico (arquitetura, dados e procedimentos). Esta fase também é tipicamente chamada de projeto (tradução do termo em inglês), porém na Engenharia de Software também utilizamos o termo projeto para denominar o processo de gestão de todas as atividades que envolvem o desenvolvimento do produto. Então, quando falarmos em design estaremos nos referindo à fase do ciclo de vida de software e quando falarmos em projeto estaremos nos referindo ao processo de gestão da construção do produto.

UNI


9

Para agravar ainda mais o cenário, a inexistência de métricas adequadas para obtenção de medidas de software antes de seu desenvolvimento, é a gota d’água final ou a “pá de cal” sobre a equipe de desenvolvimento. As métricas de software são um capítulo a parte nessa discussão, pois a questão é bem mais complexa do que se possa imaginar. Voltaremos ao assunto mais tarde.

O que pode ser observado em parcela significativa de equipes de desenvolvimento de software é a adoção de práticas absurdamente obsoletas. Aliado a estas práticas, tipicamente se encontra uma grande desigualdade na distribuição do tempo dedicado às fases do ciclo de vida de software. É muito comum reduzir requisitos em função da falta de tempo ou eliminar atividades do processo de desenvolvimento com o objetivo de reduzir o tempo total do processo.

As atividades que tipicamente são mais sacrificadas são a análise, design e testes. Um agravante é a inexistência da definição de um padrão de processo a ser seguido. Padrões desenvolvidos e publicados não faltam, porém a adoção destes é que não se observa em muitas equipes de desenvolvimento. A inexistência de padrão de processo de software multiplica a dificuldade de realizar manutenção.

Muitos ainda subestimam a atividade de desenvolvimento de software, acreditando ser simples e fácil iniciar um software sem a definição de uma estrutura e arquitetura adequadas e evoluir este software até ele se tornar um produto com um conjunto significativo de funcionalidades. Desenvolver software não é uma atividade simples, logo, requisitos, arquitetura e estruturas de programas e dados não podem ser colocadas em segundo plano. Se as bases do novo software desenvolvido não forem sólidas, todo o restante do software desenvolvido será igualmente frágil.

Encontra-se também a ausência de valorização da fase de análise, na qual os requisitos são obtidos e especificados. Muitos dos softwares que há em uso mundo afora não precisariam existir se as necessidades tivessem sido devidamente entendidas e o processo de trabalho adequadamente analisado e modelado. Muitas vezes implementamos softwares para solucionarmos problemas que sequer existem.

Caro acadêmico! Neste Caderno de Estudos nos referiremos às pessoas que atuam no desenvolvimento de software como profissionais de software. Esta forma foi escolhida pelo fato de que no Brasil chamamos de engenheiros de software apenas profissionais formados em cursos de graduação em Engenharia de Software. Se você aprofundar seus conhecimentos com literaturas clássicas da área provavelmente encontrará o termos “engenheiro de software” sendo largamente utilizado. Isto se dá em função do profissional de software ser chamado de “Software Engineer” nos EUA, de onde vem boa parte das grandes contribuições científicas da área.

UNI


10

Além destes fatores podemos encontrar também um abismo de concordância entre os pesquisadores da área de Engenharia de Software e os profissionais que estão diariamente envolvidos com o processo de software. Pesquisadores acreditam que os profissionais não dão importância para o conteúdo de suas pesquisas e os profissionais acreditam que os resultados de pesquisas não podem ser aplicados à suas realidades.

Quanto maior for o abismo entre as teorias de pesquisadores e os profissionais de software, maiores serão as dificuldades enfrentadas e maior será a crise resultante. É importante que profissionais de software empreendam iniciativas de adoção de modelos formais.

Para o sucesso nesta adoção é recomendado que esta seja feita de maneira evolutiva e controlada. Apenas após comprovados os resultados com a adoção de uma parcela do processo é que se deveria seguir com novas iniciativas.

Devido à natureza intangível do software, há a tendência de entendimento de que só há algo realizado se houver código construído. Isso de fato pode ser uma verdade em algumas metodologias, porém não se pode ignorar que, por exemplo, casos de uso, diagramas de classes, diagramas E-R etc., também são artefatos valiosos e representam entregas do processo.

Ao ler este conteúdo em seu Caderno de Estudos, uma das perguntas que pode lhe ocorrer é: Com toda evolução tecnológica ocorrida desde a década de 1970, será que ainda enfrentamos estes problemas? A resposta é sim. Na verdade, atualmente estamos enfrentando uma crise ainda maior, pois a natureza dos problemas com os quais lidamos também evoluiu e a complexidade dos processos cresceu.

Com o crescimento da complexidade dos problemas de negócio a serem resolvidos, cresceu também a necessidade de crescimento da equipe de desenvolvimento. O crescimento da equipe de desenvolvimento adiciona força de trabalho, porém traz desafios gerenciais. A partir daí começa a entrar em cena a importância dos aspectos gerenciais da Engenharia de Software. O maior clássico sobre este assunto “O Mítico Homem-Mês” está na leitura complementar desta unidade. Não deixe de ler!


11

FIGURA 5 – LIVRO: O MÍTICO HOMEM-MÊS

FONTE: O autor

O livro O Mítico Homem-Mês rendeu a Frederick Books Jr. diversas premiações, dentre elas a Medalha Nacional de Tecnologia americana no ano de 1985 e o Turing Award no ano de 1999. O Turing Award é uma honraria concedida anualmente pela ACM (Association for Computing Machinery) para uma pessoa que tenha realizado contribuições significativas à área da computação. Este prêmio é conhecido como “Prêmio Nobel da Computação” e leva o nome de Turing pelas contribuições de Alan Turing para a ciência da computação moderna.

UNI

Embora tenham se passado várias décadas desde que a existência de uma crise de software tenha sido reconhecida, ainda hoje enfrentamos muitos dos problemas identificados lá no final da década de 1960. Ainda hoje enfrentamos problemas no processo de análise, no processo de construção, na forma como o software é implantado e mantido e nas consequências geradas aos usuários finais. As atuais exigências de disponibilidade de funções executadas por software requerem que os profissionais de software melhorem continuamente os processos de Engenharia de Software. Mas afinal o que é Engenharia de Software? Vejamos em detalhes no tópico a seguir.

3 ENGENHARIA DE SOFTWARE

No final da década de 1960 nasceu o termo Engenharia de Software. Fritz Bauer (Friedrich Ludwig Bauer) foi quem definiu em 1968 o termo pela primeira vez como sendo “o estabelecimento e uso de sólidos princípios de engenharia para que se possa obter economicamente um software que seja confiável e que funcione eficientemente em máquinas reais” (PRESSMAN, 1995).

http://pt.wikipedia.org/wiki/Computa%C3%A7%C3%A3o

http://pt.wikipedia.org/wiki/Pr%C3%AAmio_Nobel


12

A definição de Bauer de fato abrange o que pode ser reconhecido como importante no que conhecemos por Engenharia de Software. Por sólidos princípios de engenharia podemos entender os processos necessários para a construção de software de forma adequada. O software deve ser confiável e também funcionar de maneira eficiente em nossos equipamentos.

FIGURA 6 – FRIEDRICH LUDWIG BAUER

FONTE: Disponível em: <www.computerhope.com>. Acesso em: 10 mar. 2013.

O objetivo da Engenharia de Software é prover soluções de software aplicáveis às necessidades para as quais foi concebido, construídos de forma produtiva e entregando alto grau de qualidade. O engenheiro de software ao aplicar de forma adequada os métodos, ferramentas e procedimentos da Engenharia de Software torna-se um criador de soluções que atendam as necessidades do mundo real.

No início da década de 1990 se apregoava que no futuro próximo seria tão simples desenvolver software que programadores não seriam mais necessários. Diante disso, muitos estudantes da área e profissionais passaram por momentos de preocupação em relação a seus futuros. Alguns visionários acreditavam que em breve as ferramentas de desenvolvimento seriam tão sofisticadas a ponto de qualquer usuário poder definir sua aplicação sem a necessidade de programadores.

Felizmente as previsões não se confirmaram e programadores são cada vez mais importantes e valorizados. Porém, se considerarmos que o processo de software tem forte dependência de material humano poderíamos caracterizá-lo como artesanal. Certo? Certíssimo! Por mais que tenhamos ferramentas modernas para auxiliar o processo de software, o elemento humano ainda é e deverá continuar sendo o principal pilar do processo.


13

Porém o fato do processo de software ainda poder ser caracterizado como um processo artesanal não significa que ele não possa ou não deva seguir processos formalizados. Na realidade, é justamente por este motivo que se faz tão importante a adoção de melhores métodos e formalização de procedimentos.

Diante desse contexto, a Engenharia de Software é uma área que ganha importância a cada dia, pois a dependência humana de softwares é cada vez maior. Atualmente uma parcela significativa da população utiliza software com um grau relevante de dependência. Dependemos de softwares para nos comunicarmos, nos informarmos, fazermos operações bancárias, fazermos compras num supermercado etc.

Nos escritórios de empresas e instituições são utilizados editores de textos, planilhas, softwares de apresentação, entre outros diversos softwares e sistemas computacionais. Nossas contas do dia a dia são controladas por sistemas computacionais e sem os mesmos nossa realidade seria muito diferente, pois estaríamos bastante limitados em relação às possibilidades atuais.

Os processos precisam ser cada vez mais eficientes e ágeis para que as empresas possam se manter competitivas, gerar empregos e renda para os colaboradores. Toda essa realidade seria significativamente diferente sem a existência de softwares como temos atualmente. Porém, toda essa dependência pode aumentar também as consequências do funcionamento inadequado destes softwares.

Os softwares utilizados diariamente precisam estar livres de falhas. Dado o grau de dependência que indistintamente temos dos softwares que utilizamos no dia a dia. Quaisquer falhas que venham a ocorrer podem ter sérias consequências. Os softwares devem estar disponíveis aos usuários e executar suas funcionalidades de acordo com as regras de negócios, além de atender à legislação.

Para Sommerville (2003) a Engenharia de Software está focada em todos os aspectos relacionados à construção de software. É uma disciplina de engenharia cujo objetivo é tratar das questões ligadas ao processo de software. A abrangência é bastante ampla, iniciando muito antes de haver uma especificação de software, indo até o último momento de utilização do referido software. Na verdade estamos utilizando o software como elemento base, mas a Engenharia de Software abrange também todos os artefatos relacionados ao processo de software, como documentação, gestão e muitos outros.

Contribuindo na explicação do que é Engenharia de Software, Pfleeger (2004) argumenta que software abrange muito mais nosso mundo que efetivamente imaginamos, tornando nossas vidas mais confortáveis, eficientes e efetivas. Há aplicações de software sendo utilizadas nas mais diversas situações do cotidiano que nos afetam direta ou indiretamente. Por este motivo, é crescente a importância da existência de softwares que atendam às necessidades para as quais eles foram


14

projetados e construídos. A abordagem que se pretende dar é a de que “as boas práticas de engenharia de software devem assegurar que o software tenha uma contribuição positiva em nossas vidas”. (PFLEEGER, 2004, p. 1).

De forma mais objetiva, a mensagem que Pfleeger (2004) pretende passar é que a Engenharia de Software é um meio para solucionar problemas de forma adequada. Isso pode implicar inclusive a decisão de que eventualmente a melhor solução seja não implementar um software para realização da atividade em questão. Devemos empregar as ferramentas, técnicas e procedimentos da Engenharia de Software para a solução de problemas e/ou necessidades.

Quando nos referimos à Engenharia de Software há a tendência de se pensar apenas nos aspectos tecnológicos, porém é importante observar que compreende também aspectos gerenciais. Na realidade, se considerarmos o aspecto que representa os maiores desafios, decididamente os aspectos gerenciais são os que mais consomem energias dos profissionais de software.

Em relação à questão gerencial Maffeo (1992) argumenta sabiamente que o elemento básico do processo de desenvolvimento de software são as pessoas. Diante da evolução tecnológica que vivemos, reconhecer que os seres humanos são o elemento chave para o sucesso pode causar um choque de paradigmas para muitas pessoas. Porém, de fato o elemento humano é fundamental no processo de construção de softwares. E efetivamente isso se comprova cada vez mais nas equipes de desenvolvimento mundo afora.

Embora tenhamos disponíveis diversas ferramentas sofisticadas para apoiar o processo de software a Engenharia de Software ainda tem forte dependência do fator humano. O desenvolvimento de software pode ser considerado como uma forma sistemática de fazer arte. E o que confere beleza a esta arte é quanto ela auxilia na solução de problemas impostos.

Pelo fato do processo de software ter forte dependência do fator humano, a Engenharia de Software lida também com a questão da produtividade. As questões de produtividade envolvem medição de software, estimativas de esforço, definição de indicadores, desenvolvimento de cronograma, coleta de dados de produtividade, análise dos dados de produtividade, entre outras atividades. O processo requer planejamento, organização, controle, além dos aspectos de motivação e liderança.

Toda a preocupação com a melhoria dos processos de Engenharia de Software tem como finalidade a produção e entrega de software de qualidade. E qualidade é algo que merece especial atenção. O assunto será devidamente abordado na Unidade III deste Caderno de Estudos.

Pressman (1995) categoriza os elementos fundamentais da Engenharia de Software em três: métodos, ferramentas e procedimentos. Os métodos podem ser entendidos como os roteiros a serem seguidos para realização de determinada


15

atividade. Exemplos são as atividades de planejamento, realização de estimativas, design de sistemas, definição de arquitetura de software, técnicas de programação, formas de realização de testes e manutenção de softwares, entre outros.

As ferramentas podem ser entendidas como o meio para realização das atividades. Elas servem de apoio aos métodos, permitindo que as atividades sejam desenvolvidas de forma mais eficiente e eficaz. Exemplos de ferramentas são as linguagens de programação, bancos de dados, softwares de modelagem de dados, softwares para modelagem de projetos, entre outros.

Os procedimentos podem ser entendidos como as ações realizadas, ou seja, a aplicação dos métodos e das ferramentas. Os procedimentos são as atividades detalhadas que são executadas para realização, por exemplo, de um método de planejamento apoiado por uma ferramenta de cronograma. Do ponto de vista técnico, a utilização adequada destes três elementos fundamentais é que nos permitirão obtenção de melhores resultados em processos de Engenharia de Software.

Em relação às ferramentas, houve um grande salto evolutivo a partir da década de 1990. Por volta dessa época surgiram ferramentas de requisitos, de modelagem, de design, de testes e principalmente de programação. E a partir da metade da décade de 1990 iniciou-se de maneira mais intensa a corrida para o paradigma de orientação a objetos. Nos primeiros anos desse período a opinião dos desenvolvedores ainda estava dividida entre permanecer no modelo estruturado ou migrar para a orientação a objetos.

Neste período de transição o que se viu foram muitos softwares sendo construídos em linguagens orientadas a objetos com porções significativas de código idêntico ao escrito no paradigma estruturado. A migração para a orientação a objetos não foi tão suave e simples quanto poderia ter sido. A partir do início dos anos 2000 é que a orientação a objetos começou a ser utilizada de forma mais intensa. É certo que ainda hoje há softwares utilizando linguagens baseadas ou orientadas a objetos com códigos estruturados. Porém atualmente poucos questionam a orientação a objetos como principal paradigma.

Algo muito semelhante ocorreu com iniciativas de adotação de bancos de dados orientados a objetos. Houve um vai e vem de paradigmas. A principal causa dessas situações está relacionada à falta de uma análise prévia criteriosa em relação à aderência do modelo à realidade de negócio para a qual o software deverá ser desenvolvido.

Da mesma forma como linguagens estruturadas não foram criadas para desenvolver quaisquer aplicações, as orientadas a objetos não o foram. Não seria a falta de aderência entre negócio e tecnologia uma das causas dos baixos níveis de qualidade de alguns softwares? Fica a questão para reflexão.


16

Em relação à Engenharia de Software, Sommerville (2003) destaca alguns pontos-chave:

• a Engenharia de Software é uma disciplina da engenharia que se ocupa de todos os aspectos da produção de software;

• os produtos de software consistem de programas desenvolvidos e da documentação associada. Os atributos essenciais dos produtos são a facilidade de manutenção, a confiança, a eficiência e a facilidade de uso;

• o processo de software consiste em atividades envolvidas no desenvolvimento de produtos de software. As atividades básicas são a especificação, o desenvolvimento, a validação e a evolução do software;

• métodos são os meios organizados de produzir software. Eles incluem sugestões sobre o processo a ser seguido, as notações a serem utilizadas, as regras que regem as descrições de sistema produzidas e as diretrizes do projeto;

• as ferramentas CASE são sistemas de software projetados para dar apoio às atividades de rotina no processo de software, tais como editar diagramas de projeto, verificar a consistência de diagramas e manter o controle dos testes de programa que são realizados;

• os engenheiros de software têm responsabilidades para com a engenharia como profissão e a sociedade. Eles não devem se preocupar exclusivamente com questões técnicas.

17

Caro(a) acadêmico(a)! Nesse tópico, você estudou que:

• A Engenharia de Software é uma área que passou a ser formalizada a partir do início da década de 1970. Até este momento, as ferramentas, métodos e procedimentos utilizados não estavam formalmente subordinados a uma área específica. Cada desenvolvedor utilizava as ferramentas mais úteis aos seus processos de trabalho.

• A Engenharia de Software surgiu a partir da necessidade de formalização e aperfeiçoamento dos métodos de construção de software. A principal motivação foram as consequências geradas a partir de processos de software inadequados. Esta consequência foi denominada de crise de software entre o final da década de 1960 e início da década de 1970.

• A partir do momento em que a Engenharia de Software passou a ser reconhecida como uma subárea da Computação/Informática diversos pesquisadores desenvolveram métodos e técnicas para aperfeiçoar as práticas diárias no processo de desenvolvimento de software. Tais subsídios permitiram compartilhamento de experiências e métodos para melhorar a qualidade do software produzido.

• A Engenharia de Software veio para auxiliar os profissionais de software nas dificuldades encontradas no processo de produção de soluções de software para atender à crescente necessidade de soluções. Isso tudo sem deixar de considerar os aspectos técnicos e aspectos gerenciais.

• A produção de software é uma atividade que depende fortemente da habilidade humana. Diante disso, o fator humano é um importante quesito a ser considerado e gerenciado. Tais características consideram a necessidade de desenvolvimento de habilidades interpessoais, trabalho em equipe, motivação, liderança, entre outros.

RESUMO DO TÓPICO 1

18

Caro(a) acadêmico(a)! Como forma de fixar o conteúdo estudado realize a autoatividade proposta a seguir:

1 Aponte dois problemas que podem levar à crise de software.

2 Quando podemos reconhecer que há uma crise de software?

3 Quais são as atividade do desenvolvimento de software que são tipicamente mais sacrificadas?

4 Quais são os elementos fundamentais da Engenharia de Software?

AUTOATIVIDADE

19

TÓPICO 2

PROCESSOS DE SOFTWARE

UNIDADE 1

1 INTRODUÇÃONuma atividade de engenharia é necessário que se defina o método de

construção que será adotado. No momento em que se decide construir um software para atender a uma necessidade de negócio ou entregar alguma ferramenta, recurso ou opção de entretenimento é importante que se decida qual o processo que será seguido.

A criação de um software é uma atividade intelectual de alto nível de complexidade. E é justamente por se tratar de uma atividade complexa que é fundamental que se saiba quais são as etapas que comporão tal processo. A adoção de processos bem definidos melhora a visibilidade da construção de software.

Aparentemente todo e qualquer software pode ser construído sem que um roteiro pré-definido seja seguido. Isso pode ser verdade se você estiver desenvolvendo um software por interesse pessoal nas horas vagas e para passar o tempo (hobby). Neste caso o seu compromisso está tipicamente limitado à sua satisfação em construir o software.

No desenvolvimento de software por hobby a necessidade de refazer uma parte do trabalho pode representar apenas mais algumas horas dedicadas a um feito que lhe proporcionará satisfação. Já no desenvolvimento profissional de software o cenário pode ser radicalmente diferente. Até mesmo o desenvolvimento de uma PoC (Proof of Concept – Prova de Conceito) que requeira muito retrabalho poderá se tornar algo bastante indesejado.

No desenvolvimento profissional de software é altamente desejável que se siga um processo que reduza, dentro do possível, o desperdício de tempo e maximize os resultados obtidos. Os resultados esperados são tipicamente funcionalidades de software com alta qualidade.

Dada à importância do processo de desenvolvimento de software é imperativo que se estabeleça e siga um modelo que possibilite obter software de alta qualidade. Deverá haver equilíbrio entre otimização do tempo e realização das etapas críticas do processo. O segredo do universo está no equilíbrio.

Em relação ao processo de desenvolvimento de software, Brooks (2009) sugere que se explorem as opções existentes no mercado para evitar construir algo que pode ser comprado. Ele indica a utilização de prototipação para o


20

estabelecimento de requisitos de software. Crescer os softwares organicamente através da adição de funções à medida que são executados, usados e testados. Identificar e desenvolver os grandes profissionais da geração em ascensão.

Todo produto de software é construído com base em um modelo de processo, também conhecido como paradigma de desenvolvimento ou ainda ciclo de vida. Um ciclo de vida de software compreende um conjunto de etapas envolvendo métodos, ferramentas e procedimentos para a obtenção do produto de software desejado (PRESSMAN, 1995).

O ciclo de vida de software é um processo de engenharia que notadamente requer que algumas etapas sejam seguidas em determinada ordem para que se possa obter um produto final com o grau de qualidade desejado. De acordo com Pfleeger (2004, p. 36), todo processo tem as seguintes características:

• o processo prescreve todas as principais atividades;• o processo gera produtos intermediários e finais, com base nos recursos e

restrições existentes;• o processo pode ser composto por uma hierarquia de processos onde cada

subprocesso possa ter seu modelo;• cada atividade do processo possui critérios de entrada e saída, permitindo

saber quando ele começa e quando termina;• as atividades são organizadas sequencialmente, de forma que a ordem entre as

atividades seja clara;• todo processo possui um conjunto de diretrizes que ajudam a explicar os

objetivos de cada atividade.

Não é necessário seguir na íntegra um modelo de ciclo de vida proposto por algum pesquisador da área de Engenharia de Software. O ciclo de vida adotado pode ser adaptado de algum modelo anteriormente proposto por algum pesquisador ou totalmente personalizado de acordo com as necessidades e realidade da equipe e natureza do software a ser desenvolvido. Um ciclo de vida de software também pode ser construído através de melhores práticas de diversos modelos amplamente conhecidos.

De uma forma geral, qualquer processo de software ou ciclo de vida possui três fases que são comuns a qualquer abordagem adotada. Pfleeger (2004) diz que estas três fases são definição, desenvolvimento e manutenção.

De fato não há como desenvolvermos algo sem que seja definido, mesmo que superficialmente. O desenvolvimento é o processo principal, pois é o momento em que os artefatos são produzidos. Já a manutenção é a fase de maior duração dentro do ciclo de vida de um software, pois tipicamente ocorre até próximo de sua desativação.

A fase de definição está focada em descrever o que o software deverá fazer (PRESSMAN, 1995). É nesta fase que são definidos os requisitos funcionais

TÓPICO 2 | PROCESSOS DE SOFTWARE

21

e não funcionais. Os requisitos funcionais estão relacionados à descrição das funcionalidades que o software deverá atender. Já os requisitos não funcionais estão relacionados aos recursos tecnológicos que deverão ser atendidos.

Para facilitar o entendimento dos requisitos não funcionais vejamos alguns exemplos: um requisito não funcional pode ser a necessidade de utilizar o software em ambiente local, em rede local e/ou numa rede de longa distância, se o software deverá ser utilizado em diferentes Sistemas Operacionais, se o software deverá utilizar determinado banco de dados, entre outros requisitos que não estejam relacionados às regras de negócio que deverão ser atendidas.

Na fase de desenvolvimento ocorre a definição de como o software deverá ser desenvolvido (PRESSMAN, 1995). A fase de desenvolvimento pode compreender diversas subfases, dentre as quais as mais comuns são definição das estruturas de dados, modelagem de banco de dados, arquitetura, design, programação e testes. Boa parte dos ciclos de desenvolvimento utiliza algumas destas subfases como fases, conforme a importância no processo.

Na fase de manutenção são realizadas as mudanças necessárias no software (PRESSMAN, 1995). Estas mudanças podem ser exigidas por diversos motivos que podem ser categorizadas como corretivas, adaptativas, perfectivas e evolutivas (SWEBOK, 2004).

As manutenções corretivas tipicamente reativas e visam eliminar falhas ou erros encontrados após a entrega do software para utilização. Este tipo de manutenção é pouco desejada e deve representar um pequeno percentual do esforço da equipe de desenvolvimento.

As manutenções adaptativas são menos comuns de ocorrer. Elas visam, por exemplo, a mudança ou atualização de plataforma tecnológica. Ela também pode ser realizada para manter o software em uso num ambiente diferente ou num ambiente em mudança. Este tipo de manutenção também não é desejável, pois pode representar grande volume de esforço para sua realização.

As atividades realizadas para tornar o software mais performático ou melhorar sua estrutura de construção de forma a facilitar o processo de manutenção é definido como manutenção perfectiva. Este tipo de manutenção pode ser necessário nas primeiras vesões do software para aperfeiçoamento no desempenho de determinadas rotinas. Também pode ocorrer no momento que se identifica a necessidade de reescrever partes do código para deixa-lo melhor para realizar manutenções.

Já as manutenções evolutivas visam promover melhorias em requisitos funcionais e/ou não funcionais. A manutenção evolutiva é realizada para evitar que determinadas falhas, tipicamente de especificação, se tornem falhas efetivas, corrigindo-as antecipadamente. Esta manutenção deve entregar funcionalidades de alto valor para o negócio.


22

A fase de manutenção pode ser vista sob duas óticas: nobre e não nobre. A manutenção é considerada nobre quando as alterações que estão sendo realizadas são motivadas por alterações nos requisitos ou necessidades dos usuários. Ela é considerada não nobre quando alterações precisam ser promovidas para corrigir falhas, tipicamente conhecidas como bugs.

Uma das grandes dúvidas que surge em relação aos tipos de manutenção é a distribuição ideal de esforço em cada uma delas. Esta distribuição pode variar com base em diversos fatores técnicos e ambientais. Porém uma distribuição desejável é 20% do esforço dedicado a manutenções corretivas, adaptativas e perfectivas e 80% em manutenções evolutivas. Destes 80% de manutenção evolutiva, seria interessante dedicar 30% para projetos de inovação e 50% com inclusão, alteração e exclusão de funcionalidades.

É certo que esta não é uma meta facilmente atingível, porém serve como indicador e norteador a ser observado e perseguido. Podemos comparar grosseiramente à qualidade total, que é uma meta ousada e que requer constante esforço e trabalho em melhoria contínua para aproximação à mesma.

2 CICLOS DE VIDA DE SOFTWARE

Existem diversos modelos de processo de software propostos. Alguns apresentam superficialmente a concepção do modelo e outros detalham exaustivamente as fases e subfases do processo. É importante que cada equipe de desenvolvimento se inspire no modelo de processo que esteja mais aderente à sua realidade, customize e promova melhorias contínuas neste modelo. Pfleeger (2004) apresenta algumas razões para a realização dessa modelagem de processo:

• melhora o entendimento do processo para a equipe de desenvolvimento;• permite a melhoria do processo pela equipe envolvida;• o modelo reflete os objetivos do desenvolvimento de software;• proporciona visibilidade sobre necessidades de adequação em função da

natureza do projeto.

Pfleeger (2004, p. 38) descreve ainda que “todo processo de desenvolvimento de software tem como entrada os requisitos do sistema e como saída um produto fornecido”.

Todo software possui um ciclo de vida através do qual ele é ou será construído, logo, compreender os aspectos dos principais modelos de ciclo de vida pode auxiliar na adoção de um dos modelos. Também servirá de importante embasamento teórico para a construção de um ciclo de vida mais adequado à realidade e necessidade da organização. Os ciclos de vida de software podem ser categorizados como, linear, incremental ou iterativo.


23

2 CICLOS DE VIDA DE SOFTWARE

No modelo linear, o software será entregue com todas suas funcionalidades em apenas uma fase. Este ciclo de vida é mais simples de entender, pois segue o fluxo natural do desenvolvimento de qualquer outro tipo de produto. Este ciclo de vida entra na fase de manutenção quando todas as funcionalidades definidas estiverem concluídas e entregues.

Foi a primeira categoria de ciclos de vida descrita de maneira formal, justamente pelo fato de seguir um fluxo mais natural e compreensível. Ele pode ser adotado na construção de qualquer software, porém vem sendo cada vez menos utilizado pelo fato do tempo de entrega ser tipicamente longo.

No modelo incremental uma versão básica é disponibilizada ao final do primeiro ciclo e nos ciclos seguintes novas funcionalidades são agregadas até que se tenha o produto completo. Este modelo pode ser utilizado de forma independente ou em conjunto com o iterativo.

Já no modelo iterativo uma versão básica de boa parte das funcionalidades é disponibilizada no primeiro ciclo e funções mais aperfeiçoadas são disponibilizadas em ciclos posteriores. A cada ciclo são realizados aperfeiçoamentos nas funcionalidades até que todas as funcionalidades estejam completas.

Para cada uma destas categorias de ciclos de vida de software há um ou mais modelos formais disponíveis para adoção. Entre os modelos de ciclo de vida de software mais conhecidos está o clássico, também conhecido como modelo cascata (waterfall), espiral e prototipação. Além deste, há os modelos RAD, modelo de quarta geração ou técnicas de quarta geração, modelo em V, modelo transformacional, modelo evolucionário, entre outros.

Independente do ciclo de vida que seja adotado é muito importante que se tenha clareza do que deve ser realizado em cada fase do referido ciclo de vida. Por exemplo, na fase de análise é realizada a determinação do que o software deverá fazer. E na fase de design é realizada a determinação de como o software será construído.


24

FIGURA 7 – INFLUÊNCIA DE CADA FASE DO CICLO DE VIDA NOS CUSTOS DO SOFTWARE

FONTE: O autor

Cada fase de um ciclo de vida de software tem sua finalidade e importância, logo, tratar determinada fase sem a devida atenção pode ser nocivo à saúde do software que será construído. O resultado típico que se observa é software com baixa qualidade.

A falta de valorização das fases de análise e design tipicamente geram sérias consequências no processo de manutenção. Não é incomum vermos softwares entrando em manutenção antes mesmo de serem concluídos. Se analisarmos a distribuição de tempo investido em cada fase do ciclo de vida poderemos observar que a manutenção é a mais longa e tipicamente a que mais consome recursos (humanos e financeiros).

3 MODELO CLÁSSICO

O ciclo de vida clássico, também muito conhecido como modelo cascata (waterfall), é uma abordagem sequencial sistemática do desenvolvimento de software. Este ciclo de vida foi modelado com base no ciclo da engenharia convencional (PRESSMAN, 1995). O conjunto de fases que o compõe pode variar conforme a necessidade da equipe em questão.

O ciclo de vida clássico foi proposto por Winston W. Royce no ano de 1970

como um conjunto de estágios a serem seguidos para a obtenção de um produto de software. Posteriormente diversas variações do modelo foram propostas. Cada uma com o objetivo de eliminar fragilidades ou promover adaptações para melhorar a utilização do modelo.


25

Royce (1970) propôs o modelo clássico com as fases de requisitos de sistema, requisitos de software, análise, design de programa, codificação, teste e manutenção. O ciclo de vida clássico tem como característica marcante o fato de todas as fases de desenvolvimento ter momentos de início e término bem definidos, ou seja, uma fase só inicia se a anterior estiver concluída.

FIGURA 8 – CICLO DE VIDA CLÁSSICO

FONTE: Royce (1970)

Na fase de requisito de sistemas são estabelecidos os requisitos para todos os elementos do sistema. Nesta fase são coletados requisitos em nível de sistemas ou alto nível sem aprofundamento em análise ou design.

Os requisitos necessários ao software são coletados na fase de requisitos de software. Nesta fase também é compreendido o domínio da informação, desempenho e interfaces necessárias. O artefato resultante é um conjunto de requisitos devidamente documentados.

A fase de análise compreende as atividades de análise do sistema no

contexto da aplicação e análise das integrações com os demais sistemas. Nesta fase é intensificada a coleta de requisitos em níveis de detalhes mais específicos. É importante que o analista compreenda o domínio de informações necessárias ao software, permitindo detalhar as funções que o mesmo deve desempenhar. Tipicamente o artefato gerado nesta fase é a documentação dos requisitos que será utilizada nas fases seguintes do ciclo de desenvolvimento.


26

O design de programa ou simplesmente design é uma fase que compreende a definição das estruturas de dados, arquitetura de software, decisão sobre detalhes procedimentais e caracterização de interfaces (PRESSMAN, 1995). Esta fase também deve gerar artefatos de documentação. As definições realizadas nesta fase são vitais para o processo de construção e manutenção do futuro software, pois uma vez definida a arquitetura do software a sua forma de construção estará apoiada nesta arquitetura.

Embora tipicamente se acredite que a maior dificuldade em criar uma nova geração de software esteja na linguagem ou ambiente de programação, na realidade os maiores desafios poderão estar relacionados às questões arquiteturais.

UNI

A fase de codificação é destinada à transcrição do design para uma linguagem de programação. O objetivo é realizar a programação do que foi definido nas fases de análise e design. Esta fase é amplamente beneficiada em termos de esforço na maioria dos projetos. Porém ela pode ser reduzida caso nas fases anteriores os artefatos gerados tenham a riqueza e consistência necessárias.

Nos testes é verificado se o produto está atendendo aos requisitos estabelecidos e também se o produto está livre de falhas. E por último, na fase de operação que é tipicamente referenciada como fase de manutenção, as eventuais falhas identificadas são corrigidas e novas funcionalidades são agregadas ao produto.

O modelo clássico tem como potencialidade a visibilidade da fase em que o projeto se encontra. O que também favorece o modelo é a necessidade de conclusão de uma fase para iniciar a seguinte. Ao seguir tal premissa do modelo, podemos nos beneficiar da existência de artefatos completos para subsidiar a fase seguinte.

Neste modelo pode ser interessante adotar também uma metodologia de processo de passagem de portões (stage-gate process). A ideia básica é realizar um processo de validação dos artefatos produzidos na fase para início da fase seguinte. Uma forma prática de implementar pode ser através de uma revisão por pares dos artefatos gerados.

O que conspira contra o modelo clássico é que geralmente é difícil poder seguir um fluxo sequencial no desenvolvimento de software. Outra dificuldade é conseguir que o usuário detalhe todas as suas necessidades no início do projeto. O que é relativamente natural, pois na medida em que o projeto avança e os


27

requisitos são transformados em funcionalidades de software, novas possibilidades e funcionalidades poderão ser percebidas. Ameaça o uso do modelo também, o fato de que o usuário só terá algo para utilizar quando todo o processo estiver concluído.

Outros autores destacam diferentes fases do modelo clássico. Por exemplo, Sommerville (2003) destaca as fases de definição de requisitos, projeto de sistemas e de software, implementação e teste de unidades, integração e teste de sistemas e operação e manutenção. Já Pfleeger (2004) descreve as fases de análise de requisitos, projeto do sistema, projeto do programa, codificação, teste de unidades e de integração, teste do sistema, teste de aceitação e operação e manutenção.

Neste caso não cabe discutir quem está certo ou não. O que importa é que cada autor chama a atenção para as fases que são mais relevantes de acordo com sua experiência e realidade em termos de processos de software.

4 MODELO ESPIRAL

O modelo espiral foi proposto por Barry Boehm no ano de 1988 como uma abordagem para contribuir na melhoria da situação dos processos de software da época. O maior diferencial está na abordagem orientada a riscos, ao invés das abordagens orientadas à documentação e codificação.

O ciclo de vida espiral permite acompanhar a evolução dos requisitos, disponibilizando-os segundo a prioridade das necessidades do usuário. Este modelo facilita a incorporação de novos requisitos de forma evolutiva. Ele combina características do ciclo de vida clássico e da prototipação.

No modelo espiral, o desenvolvimento é progressivo a cada ciclo, sendo que em uma ou mais fases de engenharia e protótipos podem ser desenvolvidos para definir melhor o problema e refinar os requisitos. A técnica de prototipação é utilizada como um mecanismo de redução dos riscos.

De acordo com Sommerville (2003), cada ciclo da espiral é dividido em quatro setores:

• Definição de objetivos: são definidos os objetivos para a fase, identificadas as restrições, preparado um plano de gerenciamento detalhado, identificados os riscos e planejadas estratégias para tratamento dos riscos identificados.

• Avaliação e redução de riscos: para cada risco identificado é realizada uma análise detalhada e estabelecidos planos para tratamento dos riscos de forma a reduzir sua probabilidade e impacto.

• Desenvolvimento e validação: com base nos riscos identificados uma estratégia de desenvolvimento é adotada para reduzir a probabilidade de ocorrência do risco.


28

• Planejamento: é realizada uma revisão do projeto e decidido pela sua continuidade ou não do próximo ciclo. Havendo a decisão de continuar, os planos para a próxima fase são estabelecidos.

Uma consideração importante sobre este modelo é que um risco pode ser simplesmente algum evento que se ocorrer pode resultar em problemas para o projeto. Estes eventos podem representar problemas de performance, atrasos em entregas do projeto, incompatibilidade de ferramentas, entre outros que representem algum impacto no resultado final do software. Este resultado alterado pode representar diversas influências sobre o software entregue.

FIGURA 9 – MODELO ESPIRAL

FONTE: Sommerville (2003)

Além da característica de avaliação dos riscos, neste modelo podem ser implementados ciclos com quantidade de requisitos a ponto de facilitar o controle do progresso. Dessa forma é possível realizar entregas de artefatos de valor em períodos de tempo menores, gerindo a expectativa dos usuários e realizando entregas de valor.

O que conspira contra o modelo espiral é a dificuldade de convencer os usuários das vantagens do uso do modelo evolutivo. Este modelo exige que a equipe de desenvolvimento tenha experiência na avaliação dos riscos. Caso um grande risco seja descoberto, este fato poderá inviabilizar o produto. Contribui também o fato de não haver um histórico suficiente de projetos desenvolvidos nesse modelo para que possa ser determinada sua real eficácia.


29

5 MODELO PROTOTIPAÇÃO

Dentre o grande conjunto de desafios que representam os processos de Engenharia de Software está a dificuldade em certificar-se de que os requisitos definidos são efetivamente o que o usuário/cliente necessita. Para reduzir a lacuna de entendimento foi criada a técnica de prototipação.

A prototipação é uma técnica em que são produzidas versões iniciais ou modelos visuais que representam como o software ficará depois de pronto. A ideia dessa representação é permitir avaliar as características do software antes que ele seja efetivamente desenvolvido. Um modelo visual permite melhorar o entendimento dos requisitos que se pretende implementar no software.

No modelo de prototipação é elaborada uma representação do modelo do produto através de suas principais funcionalidades. O modelo permite realizar a validação de um conjunto de requisitos que deverão ser implementados. A prototipação é um modelo utilizado com grau de sucesso satisfatório, pois permite ao usuário compreender com mais clareza como o software ficará depois de pronto.

FIGURA 10 – MODELO PROTOTIPAÇÃO

FONTE: Pressman (1995)

A característica fundamental do modelo de prototipação é a representação do produto através de suas funcionalidades. A ideia chave deste ciclo de vida é a criação de um modelo para validar o conjunto de requisitos a serem atendidos.


30

Ele pode ser entendido como uma técnica para a identificação de requisitos de entrada e saída por parte dos usuários, representando aspectos visíveis a ele, o que permite melhor entendimento daquilo que será entregue no final do projeto. Ele permite ainda a verificação da eficiência de determinadas rotinas ou fluxos de atividades.

Outra característica que pode ser de grande valia é a possibilidade de verificação do comportamento do software em determinado ambiente operacional. Em resumo, neste ciclo de vida, é realizado o desenvolvimento de um protótipo que permita ao usuário identificar as tarefas que deverão ser executadas pelo software.

O modelo de prototipação abrange as atividades de coleta e refinamento dos requisitos, projeto rápido, construção do protótipo, avaliação do protótipo pelo usuário/cliente, refinamento do protótipo e engenharia do produto.

Na fase de coleta e refinamento dos requisitos é realizada a definição dos objetivos globais do produto, são identificadas as exigências conhecidas e identificadas as necessidades de definições adicionais.

No projeto rápido é criada uma representação dos aspectos visíveis do produto, construído um protótipo para avaliação com o usuário/cliente e realizado o refinamento dos requisitos do produto que será desenvolvido.

Uma vez com as características básicas definidas pode-se partir para a construção do protótipo. No processo de construção do protótipo tipicamente não são levadas em consideração quaisquer boas práticas de construção de software, pois o protótipo será apenas uma representação do software a ser construído.

Tendo o protótipo pronto, este poderá ser avaliado pelo usuário/cliente. Em se tratando de haver necessidade de alterações, o processo segue para a fase de refinamento. Uma vez validado o modelo e reduzida a lacuna de entendimento dos requisitos, pode-se partir para a construção do produto.

Na fase de engenharia do produto é que o software representado pelo protótipo será construído. A ideia básica deste modelo de processos é que o protótipo seja descartado e o processo construtivo siga as boas práticas de Engenharia de Software.

Este modelo de ciclo de vida devidamente utilizado pode auxiliar significativamente o processo de desenvolvimento de software, reduzindo retrabalho e principalmente gerenciando adequadamente a expectativa dos usuários/clientes. No momento que o software funcional é entregue ao usuário/cliente não deverá haver diferenças significativas entre o que foi validado em termos de protótipo e o software construído.


31

A utilização de prototipação é recomendada por diversos autores e também por personalidades da área como Brooks (2009, p. 174) que sugere ”usar a prototipagem rápida como parte de uma iteração planejada no estabelecimento de requisitos de software”.

Uma das fragilidades do ciclo de prototipação é a dificuldade do usuário/cliente compreender que o software apresentado é apenas um modelo e não possui as funcionalidades que apresenta nas interfaces que ele vê. O usuário imagina que o protótipo é uma versão que ele poderá utilizar imediatamente e não sabe que o protótipo foi construído sem levar em consideração requisitos de qualidade e manutenibilidade.

Em geral o que ocorre é grande pressão por parte do usuário em tornar o protótipo a versão de trabalho, efetuando apenas pequenos ajustes. O risco neste caso é de fragilizar o software pela falta de um processo de desenvolvimento adequado.

6 MODELO RAD

Com a crescente necessidade de modelos de processos de software mais ágeis, no início da década de 1990, James Martin propôs o Modelo de Desenvolvimento Rápido de aplicações. Este modelo é conhecido como RAD (Rapid Application Development) e é um processo interativo e incremental que possui tipicamente um ciclo bastante curto.

O tempo deste ciclo pode variar de equipe para equipe, porém é recomendado que ele não seja superior a 90 dias. Este modelo pode ter diversas fases e estas variam de acordo com o autor consultado. De forma genérica, ele possui as fases de definição, desenvolvimento e manutenção.

FIGURA 11 – MODELO RAD

FONTE: O autor

A fase de definição é realizada a análise global do sistema, ou seja, a fase em que são coletados os requisitos. Nesta fase é realizado também o design que compreende o planejamento do processo de desenvolvimento. Além disso, são realizadas as validações necessárias.

Na fase de desenvolvimento é feito um desenho de interface, realizada a codificação e os testes de software. Esta fase é geralmente baseada em uma ou mais linguagens de programação.


32

Já na fase de manutenção é realizada a evolução do software durante sua vida operacional. Nesta fase são realizadas modificações por alterações de requisitos, identificação de falhas ou alterações no ambiente do usuário.

Este modelo é recomendado para o desenvolvimento de software com pequena distribuição. Ele é apropriado para ambientes em que se possa fazer uso de componentes visuais ou classes pré-existentes como APIs (Application Programming Interface ou Interface de Programação de Aplicativos).

O modelo RAD pode ser eficientemente utilizado em projetos cujo escopo seja restrito e que o desempenho não seja requisito determinante. Também pode ser utilizado em projetos em que o software pode ser dividido em diversos módulos independentes.

Neste ponto cabe observarmos que o modelo de processo RAD não é adequado para qualquer tipo de software ou necessidade de aplicação. O desejo por modelos mais ágeis e eficientes existe desde que os primeiros softwares foram criados, porém a “natureza força ao equilíbrio”. Em outras palavras se quer dizer que não há como utilizar um modelo ágil em todas as situações. Softwares que requerem uma abordagem mais robusta requerem modelos de processos mais formais.

Para adoção de modelos mais ágeis como o RAD é recomendado que a plataforma de desenvolvimento privilegie a agilidade. O uso de linguagens de programação baseadas em componentes visuais e que tenham recursos de assistente de criação de aplicações é altamente recomendado em conjunto com este modelo.

7 MODELO DE QUARTA GERAÇÃO

À medida que as ferramentas de desenvolvimento passaram a oferecer novos recursos aos profissionais de software, novos modelos de processos também foram desenvolvidos. E o momento em que surgiram as ferramentas de quarta geração foi marcante para a Engenharia de Software, pois se vislumbrou um possível divisor de águas em relação à como softwares eram especificados e desenvolvidos.

Naquele momento da história acreditava-se que em pouco tempo os usuários poderiam criar suas aplicações de maneira simples e rápida, sem a necessidade do esforço gigantesco de programadores e demais profissionais envolvidos no processo de software. Acreditava-se vque em breve o papel dos profissionais de desenvolvimento de software seria extinto.

Na época, tal crença era tão forte que Edward Yourdon, um consultor na área de Ciência da Computação, professor universitário, defensor da programação estruturada e autor de diversos livros, escreveu a obra entitulada Declínio e Queda dos Analistas e Programadores.


33

Yourdon realizou importantes contribuições para a área de Engenharia de Software, porém, aos olhos da maioria dos profissionais de software, nesta obra, do ano de 1992, ele exagerou. A comunidade de profissionais de software criticou Yourdon de maneira bastante dura, até que em 1996 ele escreveu uma obra para se retratar. A esta obra ele chamou Ressurreição e Ascenção dos Analistas e Programadores.

FIGURA 12 – LIVRO DECLÍNIO E QUEDA DOS ANALISTAS E PROGRAMADORES

FONTE: O autor

FIGURA 13 – LIVRO RESSURREIÇÃO E ASCENÇÃO DOS ANALISTAS E PROGRAMADORES

FONTE: O autor

Não foi a primeira vez e não será a última que alguém não acertou em suas previsões. O papel dos visionários tem grande valor para o progresso da tecnologia. Mesmo que as previsões não se confirmem. No ano de 1997, Yourdon publicou a obra Projetos Virtualmente Impossíveis. Nela são descritas diversas razões pelas quais os projetos se tornam virtualmente impossíveis.


34

Entre estas razões destacadas estão as questões políticas, promessas e otimismos ingênuos em relação às entregas e à mentalidade de que programadores não precisam dormir. Acrescenta-se também pressão intensa provocada pela globalização de mercados, aparecimento de novas tecnologias e mudanças de legislação, além de crises inesperadas.

FIGURA 14 – LIVRO: PROJETOS VIRTUALMENTE IMPOSSÍVEIS

FONTE: O autor

Para a felicidade dos profissionais de software as previsões em relação à sua obsolecência profissional estavam equivocadas. O que se observa mais de vinte anos depois de tais previsões é que profissionais de software são cada vez mais importantes e valorizados. Mas vamos às características do modelo de processo de quarta geração.

O modelo de quarta geração, também conhecido como técnica de quarta geração, é baseado na utilização de ferramentas de alto nível para especificação e desenvolvimento de softwares. Este modelo visa permitir ao desenvolvedor especificar software de uma forma que esteja próxima à linguagem natural. É uma técnica adequada para desenvolvimento de aplicações pequenas e intermediárias.

A técnica de quarta geração pode abranger as ferramentas de consulta a bancos de dados, geração de relatórios, manipulação de dados, interação e definição de telas, geração de códigos e capacidade gráfica de alto nível.


35

FIGURA 15 – MODELO DE QUARTA GERAÇÃO

FONTE: Pressman (1995)

Este modelo de processo de software abrange as atividades de coleta de requisitos, estratégia de projeto, implementação usando ferramentas de quarta geração e testes. Na coleta de requisitos é realizado o levantamento dos requisitos junto ao usuário e tradução dos mesmos num protótipo operacional. Já a estratégia de projeto abrange o planejamento de como desenvolver o produto para garantir a qualidade e manutenibilidade.

Na implementação é realizada a representação dos requisitos numa ferramenta de desenvolvimento, resultando em geração automática de código e a ligação da aplicação com a estrutura de dados necessária. Os testes visam à verificação do produto gerado versus especificações iniciais e o desenvolvimento da documentação do produto gerado.

O que conspira contra o modelo de quarta geração é que cada ferramenta permite o desenvolvimento de produtos para domínios de aplicações muito específicos. Além disso, ainda não há ambientes de quarta geração que possam ser utilizados com igual facilidade para todas as categorias de software.

Registrem-se ainda dificuldades de utilização das ferramentas, ineficiência do código gerado e manutenibilidade questionável. Por estes motivos, em geral o uso da técnica de quarta geração é limitado ao desenvolvimento de um universo restrito de sistemas.

8 MODELO ALTERNATIVO

O modelo alternativo incorpora as características dos demais modelos, utilizando em maior grau, os processos mais adequados para a aplicação a ser desenvolvida. Além disso, podem-se adotar boas práticas de metodologias de desenvolvimento de software clássicas ou ágeis.


36

Neste modelo de processo de software pode, por exemplo, ser efetuado o levantamento do problema e dos requisitos do software, determinados os objetivos do projeto, efetuado o planejamento do produto, desenhado o projeto e desenvolvido o plano de projeto.

Ainda podem ser estabelecidas as prioridades e expectativas em relação ao produto, feita uma avaliação dos riscos, construída uma solução de software que atenda à especificação funcional, feita a especificação do processo de testes, efetuados os testes e eliminadas as falhas identificadas, promovidos ajustes e implementadas novas funcionalidades.

O modelo alternativo é o modelo que permite à equipe de desenvolvimento realizar suas atividades de maneira organizada e com bom nível de qualidade nas entregas. Se analisarmos o ciclo de vida de um software qualquer, concluiremos que dificilmente se adota um modelo na íntegra.

Tipicamente segue-se um modelo e realizam-se diversas adaptações a este, de acordo com a necessidade de cada projeto, fase do ciclo de vida ou maturidade do processo ou equipe. É preciso estar disposto a mudar sempre que preciso. É preciso estar disposto a aprender sempre sobre melhores formas de fazer o que não está mais dando certo.

É necessário avaliar qual é o modelo de processo de software mais adequado para a realidade da equipe envolvida e para a realidade da aplicação a ser desenvolvida. É importante que todas as fases do ciclo de vida adotado, sejam valorizadas. Valorizar as fases não é a mesma coisa que empenhar grande volume de esforço. É realizar as atividades que precisam ser realizadas no tempo requerido.

No livro Projetos Virtualmente Impossíveis, Yourdon (1999) reproduz o texto de Scott Adams da incrivelmente popular tira “Dilbert” que diz:

Quando comecei a ouvir histórias [de comportamento irracional por parte das empresas] fiquei perplexo; porém, depois de uma análise cuidadosa desenvolvi uma sofisticada teoria para explicar a existência deste bizarro comportamento no ambiente de trabalho. As pessoas são idiotas.Inclusive eu. Todo mundo é idiota, e não apenas aqueles que têm baixo quociente de inteligência. A única diferença entre nós é que somos idiotas em relação a diferentes coisas em diferentes épocas. Independentemente do seu nível de inteligência, você passa boa parte do dia sendo um idiota.

Na Engenharia de Software lidamos fortemente com processos e precisamos estar com a mente aberta para aprender sempre. Reflita sobre isso. Certamente você chegará a conclusões interessantes.


37

Sobre processos de software, Sommerville (2003) destaca alguns pontos-chave que merecem nossa atenção:

• Os processos de software são as atividades envolvidas na produção de um sistema de software. Os modelos de processo de software são representações abstratas desses processos.

• Todos os processos de software incluem especificação de software, design, implementação de software, validação de software e evolução de software.

• Os modelos de processo genéricos descrevem a organização dos processos de software. Entre os exemplos de modelos genéricos destacam-se o modelo em cascata, o desenvolvimento evolucionário, o desenvolvimento formal de sistemas e o desenvolvimento orientado ao reuso.

• Os modelos de processo iterativos apresentam o processo de software como um ciclo de atividades. A vantagem dessa abordagem é que ela evita compromissos prematuros com uma especificação ou projeto. Entre os exemplos de modelos iterativos destavam-se o desenvolvimento incremental e o modelo em espiral.

• A engenharia de requisitos é o processo de desenvolvimento de uma especificação de software. Ela se refere a desenvolver uma especificação que possa ser compreendida pelos usuários do sistema e uma especificação mais detalhada para os desenvolvedores do sistema.

• Os processos de software e implementação se ocupam da transformação de uma especificação de requisitos em um sistema executável. Métodos de projeto sistemático podem ser utilizados como parte dessa transformação.

• A validação de software é o processo de verificar se o sistema está em conformidade com sua especificação e se ele atende às reais necessidades dos usuários do sistema.

• A evolução de software se ocupa de modificar os sistemas de software existentes, para que eles atendam a novos requisitos. Isso está se tornando a abordagem normal de desenvolvimento de software para sistemas pequenos e de porte médio.

• A tecnologia CASE proporciona apoio automatizado aos processos de software. As ferramentas CASE oferecem apoio às atividades de processo individuais; as workbenches CASE apoiam um conjunto de atividades relacionadas; os ambientes CASE são compatíveis com todas ou com a maioria das atividades de processo de software.

38

RESUMO DO TÓPICO 2


• No processo de desenvolvimento de software é altamente desejável que se reduza desperdício de tempo ou retrabalho, maximize os resultados obtidos em termos de artefatos entregues e se obtenha níveis adequados de qualidade.

• Todo software possui um modelo de processo de desenvolvimento ou ciclo de vida de software. Este ciclo de vida é composto por etapas que fazem uso de métodos, ferramentas e procedimentos para a construção do produto de software de forma adequada.

• Pfleeger (2004) nos ensina que, independente do modelo de processo de software adotado, todos possuem as fases de definição, desenvolvimento e manutenção. O que diferencia estas fases em cada modelo são o detalhamento e existência ou não de subfases.

• Os requisitos funcionais estão relacionados às características de negócio que o software deverá atender. Já os requisitos não funcionais estão relacionados às características técnicas do software em construção.

• A manutenção nobre é aquela que promove melhorias no software. Já a manutenção caracterizada como não nobre é aquela que visa corrigir falhas apresentadas pelo software, tipicamente conhecido como bug.

• Os principais modelos de processos de software podem ser categorizados como, linear, incremental ou iterativo. No ciclo de vida adotado, estes podem ser utilizados isoladamente ou em conjunto.

39


1 Em qual fase do ciclo de vida de software é determinado o que o software deverá possuir de funcionalidades?

2 Em qual fase do ciclo de vida de software é determinado como o software deverá ser construído?

3 Quais são as categorias de manutenção definidas pelo SWEBOK?

4 Em qual(is) ciclo(s) de vida a prototipação está formalmente declarada no processo?

AUTOATIVIDADE

41

TÓPICO 3

REQUISITOS DE SOFTWARE

UNIDADE 1

1 INTRODUÇÃO

A determinação da criação de um novo software ou da ampliação das funcionalidades de um software já existente surge tipicamente em função do motivo pelo qual a maioria dos projetos é iniciada. Essencialmente estes projetos são iniciados em função de algum problema, oportunidade ou necessidade de negócio, ou seja, eles são motivadores para a construção de alguma solução de software que irá suprir algum problema da vida real.

A construção de um software geralmente é realizada na forma de um projeto. Isso porque em geral a construção de software é uma atividade com momentos de início e término bem definidos e resulta em uma entrega ou resultado único. A partir do momento que foi decidido iniciar um processo de construção de software depara-se com a necessidade de definir quais funcionalidades ele deverá disponibilizar.

Na gestão de projetos o que deve ser desenvolvido é denominado de escopo. Já no processo de software o que deve ser desenvolvido é denominado de requisitos. Para Sommerville (2003) os requisitos são as descrições das funções e restrições de um software. Requisitos também são definidos por alguns profissionas de software como características do produto a ser desenvolvido.

De acordo com Pfleeger (2004, p. 111), “um requisito é uma característica do sistema ou a descrição de algo que o sistema é capaz de realizar, para atingir os seus objetivos”. O primeiro passo no processo de análise de sistemas é a identificação de necessidades (PRESSMAN, 1995).

Embora possa parecer óbvio, é importante que se chame a atenção para o fato de que os requisitos são a base sobre a qual serão apoiadas todas as demais atividades do processo de software. Se os requisitos não forem devidamente especificados o sucesso do projeto poderá estar comprometido desde seu início. Carvalho e Chiossi (2001) apontam algumas dificuldades no processo de obtenção de requisitos:

• falta de conhecimento do usuário das suas reais necessidades e do que o produto de software pode lhe oferecer;

• falta de conhecimento do desenvolvedor do domínio do problema;• domínio do processo de extração de requisitos pelos desenvolvedores de

software;

42


• comunicação inadequada entre desenvolvedores e usuários;• dificuldade do usuário em tomar decisões;• problemas de comportamento;• questões técnicas.

Os requisitos são a base do processo de software. Basta dizer que os requisitos são a definição do que o software deverá realizar. Esta deveria ser uma fase do processo de software altamente valorizada, pois iniciar a construção de um software a partir de requisitos vagos é algo extremamente árduo. A falta de definição clara afeta inclusive a motivação da equipe envolvida no processo.

Ter uma definição clara dos requisitos não está associado com o grau de formalismo na descrição. Independente do modelo de processo adotado os requisitos devem ser adequadamente entendidos e detalhados até o nível necessário. Isso é fundamental para reduzir um dos grandes vilões do processo de desenvolvimento, o retrabalho.

A declaração de requisitos deve valorizar inclusive a importância dos cuidados com sua salvaguarda e demais artefatos relevantes que estejam associados ao mesmo. É importante que se estabeleça uma gerência de configuração do software que está sendo desenvolvido. Pfleeger (2004) nos ensina que a gerência de configuração é um conjunto de procedimentos para controlar:

• os requisitos que definem o que o sistema deverá fazer;• os módulos de projeto que são gerados a partir dos requisitos;• o código do programa que implementa o projeto;• os testes que verificam a funcionalidade do sistema;• os documentos que descrevem o sistema.

De outra forma, podemos entender que o gerenciamento de configuração tem por objetivo garantir que todos os elementos que constituem o projeto do software estejam devidamente identificados e versionados. Estes elementos do projeto são todos os artefatos produzidos durante o processo de construção do software, logo, envolve documentação, código, casos de teste, planos de projeto etc.

2 REQUISITOS

Partindo do entendimento de Pfleeger (2004) sobre as fases de definição, desenvolvimento e manutenção que ocorrem em qualquer modelo de processos de software, estamos tratando neste momento da fase de definição. Dependendo do modelo de processo esta fase poderá ser chamada de fase de requisitos, fase de análise ou ainda fase de design que faz parte das definições de como o software será construído.

TÓPICO 3 | REQUISITOS DE SOFTWARE

43

No caso deste tópico estamos tratando de assuntos da fase de definição que antecedem a fase de design. O entendimento desta delimitação é necessário para que não ocorra confusão no entendimento dos conceitos de obtenção de requisitos e análise. De acordo com Pressman (1995) a análise de sistemas tem os seguintes objetivos:

• identificação de necessidades dos usuários;• avaliação da concepção do sistema;• execução da análise econômica e técnica;• atribuição de funções aos elementos do sistema;• estabelecimento das restrições de prazo e custo;• criação de uma definição de sistema para subsidiar as demais fases de

engenharia.

No momento da declaração e especificação de requisitos, um dos grandes desafios enfrentados pelos profissionais de software é definir o nível de detalhamento adequado. Este nível de detalhamento pode estar associado ao público alvo e/ou objetivo da descrição. Uma forma simples de diferenciar é identificar para quem o requisito está sendo descrito.

FIGURA 16 – FONTES DE POSSÍVEIS REQUISITOS

FONTE: Pfeeger (2004)

Se estivermos descrevendo requisitos para os usuários, chamaremos esta descrição de requisitos de usuários e faremos uma descrição de alto nível sobre o que o software oferecerá de funcionalidades. Esta descrição de alto nível pode ter detalhamentos quando necessário, porém este detalhamento sempre deve estar em nível de abstração compreensível pelo usuário.

44


Já quando estivermos realizando uma especificação de requisitos para profissionais de software, podemos chamar esta descrição de requisitos de sistema. Esta é tipicamente uma descrição mais detalhada das funções que o software deverá realizar. Aqui podem ter exemplos de cálculos, fluxos e outros elementos que facilitem o entendimento.

Caso algum software ou parte de um software requeira um nível de profundidade ainda maior de detalhamento dos requisitos, este é tipicamente denominado de especificação de design de software. Este nível de profundidade de descrição é utilizado quando há necessidade de associar a engenharia de requisitos com as atividades de design do software.

Os requisitos de usuário, os requisitos de sistema e a especificação de design de software, são definidos da seguinte forma por Sommerville (2003):

1. Requisitos de usuário são declarações descritivas e gráficas sobre as funções que o software deverá disponibilizar e as restrições sob as quais ele precisará operar.

2. Requisitos de sistema são declarações detalhadas das funções a serem realizadas pelo software e as restrições existentes. O documento produzido também é tipicamente conhecido como especificação funcional.

3. A especificação de design de software é uma declaração abstrata do design do software que tipicamente é utilizada como base para o design e implementação mais detalhados.

Para deixar mais clara esta ideia, o quadro a seguir apresenta um requisito de usuário e seu detalhamento em termos de requisito de sistema. É recomendado que seja criada uma relação forte entre ambos para que seja fácil de localizá-los e atualizá-los em caso de necessidade.

QUADRO 1 – EXEMPLO DE TIPOS DE REQUISITOS

Requisitos de usuário

1. O software deve oferecer um meio de representar e acessar arquivos externos criados por outras ferramentas.

Requisitos de sistema1.1. O usuário deve dispor de recursos para definir o tipo dos arquivos externos.1.2. Cada tipo de arquivo externo pode ter uma ferramenta associada que pode ser aplicada a ele.1.3. Cada tipo de arquivo externo pode ser representado como um ícone específico na tela do usuário.1.4. Devem ser fornecidos recursos para o ícone que representa um arquivo externo, a ser definido pelo usuário.1.5. Quando um usuário seleciona um ícone que representa um arquivo externo, o efeito dessa seleção é aplicar a ferramenta associada com o tipo de arquivo externo ao arquivo representado pelo ícone selecionado.

FONTE: Adaptado de Sommerville (2003)


45

A Engenharia de Software nos ensina que existem formas de lidar com problemas de quaisquer tamanhos. Muitas vezes nos deparamos com problemas cuja grandeza nos assusta ao ponto de acharmos que não conseguiremos lida com ele. O segredo para lidar com quaisquer problemas é reduzir o seu tamanho.

Podemos utilizar diversas técnicas para reduzir o tamanho dos problemas que nos são apresentados diariamente. Uma delas é a construção de uma estrutura analítica de projeto, também conhecida como WBS (Work Breakdown Structure). Podem-se utilizar outras técnicas conhecidas como refinamentos sucessivos ou ainda o método KISS (Keep it Simple, Stupid) para software.

A ideia central é redução da complexidade do problema em subproblemas até o nível de granularidade em que possa ser resolvido de forma simples. Tornar algo complexo num conjunto de diversos elementos simples. A técnica pode ter sido inspirada na máxima “simplicidade é o último grau de sofisticação” de Leonardo da Vinci. Ou ainda na declaração de Albert Einstein de que “tudo deve ser feito da forma mais simples possível, mas não mais simples que isso”.

Uma técnica interessante para lidar com os requisitos definidos pelos usuários é categorizá-los. Uma vez identificados os requisitos no nível de granularidade adequado, estes podem ser categorizados para que seja dada a devida priorização na construção dos requisitos. Esta priorização tipicamente é realizada em função da importância e/ou relevância. Pfleeger (2004) indica que é recomendado dividi-los nas seguintes categorias:

1. Requisitos que devem ser totalmente satisfeitos.2. Requisitos que são altamente desejáveis, mas não necessários.3. Requitos que são possíveis, mas poderiam ser eliminados.

Utilizando adequadamente tal categorização é possível entender de forma mais global o conjunto de necessidades dos usuários, além de manter o foco nos requisitos realmente relevantes. Esta é mais uma técnica simples que proporciona resultados significativos ao processo de software.

Quando perguntado sobre a aplicabilidade real de processos de software e metodologias que possuem alto grau de formalismo, prefiro apresentar minha visão da seguinte forma: processos de software e metodologias com alto grau de formalismo são eficientemente aplicáveis em organizações e/ou equipes de desenvolvimento com alto grau de maturidade. Se o grau de maturidade de sua organização e/ou equipe de desenvolvimento for baixo, inicie o processo de melhoria contínua adotando técnicas que requeiram baixo esforço e que proporcionem resultados relevantes.

No processo de requisitos são produzidos dois documentos para atendimento de propósitos distintos, porém relacionados. Estes são o documento de definição de requitos e o documento de especificação de requisitos.

46


De forma objetiva, o documento de definição de requisitos é uma lista contendo tudo que o usuário espera que o software faça. Este documento deve estar em linguagem objetiva, simples, clara e que possa ser entendida tanto pelo usuário quanto pelo profissional de software.

Já o documento de especificação de requisitos aprofunda o detalhamento da definição de requisitos em termos de detalhes técnicos. Estes detalhes servirão de subsidio para o desenvolvimento do design do software.

Por que requisitos são importantes?

Em 1994, o Standish Group pesquisou mais de 350 empresas sobre os seus mais de 8.000 projetos de software, para descobrir como eles estavam se saindo. Os resultados são esclarecedores. Trinta e um por cento dos projetos de software foram cancelados antes de serem concluídos. Além disso, em grandes empresas, somente nove por cento dos projetos foram entregues dentro do prazo e do valor estimado no orçamento, e dezesseis por cento satisfizeram estes critérios nas pequenas empresas (Standish, 1994).

Para entender o porquê disso, Standish (1995) pediu aos entrevistados para explicarem as causas dos projetos terem falhado. Os fatores principais são relatados a seguir:

1. Requisitos incompletos (13,1%).2. Falta de envolvimento por parte do usuário (12,4%).3. Falta de recursos (10,6%).4. Expectativas não realistas (9,9%).5. Falta de apoio dos executivos (9,3%).6. Modificações nos requisitos e nas especificações (8,7%).7. Falta de planejamento (8,1%).8. O sistema não era mais necessário (7,5%).

Observe que algumas partes do processo de identificação, definição e gerenciamento de requisitos estão envolvidas em quase todas as causas. A falta de cuidado com o entendimento, a documentação e o gerenciamento de requisitos podem levar a uma grande quantidade de problemas: a construção de um sistema que resolve o problema errado, que não funciona como esperado, ou que é difícil para os usuários entenderem e utilizarem. Além disso, um processo de requisitos ineficiente pode custar caro. Boehm e Papaccio (1988) relataram que, se custa US$ 1,00 identificar e resolver um problema referente aos requisitos durante o processo de definição de requisitos, essa identificação e solução poderão custar US$ 5,00 durante o projeto; US$ 10,00 durante a codificação, US$ 20,00 durantes os testes de unidade e US$ 200,00, depois que o sistema tiver sido entregue! Assim, vale a pena utilizar algum tempo para entender o problema e seu contexto, e obter os requisitos certos na primeira vez.

FONTE: Pfleeger (2004, p. 112)


47

Conforme pode ser observado anteriormente, o adequado entendimento dos requisitos de software, além de evitar retrabalho pode aumentar significativamente a probabilidade de sucesso em projetos de desenvolvimento de software. Embora a pesquisa do Standish Group seja de 1994, os resultados apresentados não mudaram significativamente até os dias atuais.

Nas últimas décadas houve importantes avanços em relação à valorização das práticas da Engenharia de Software. Porém o que ainda pode ser observado em parcela significativa das equipes de desenvolvimento é pouca valorização dos requisitos, excessiva valorização da fase de codificação e constante negligência na fase de qualidade.

Em relação às categorias de requisitos, podemos classificá-los como funcionais ou não funcionais. Os requisitos funcionais são as declarações de funções que o software deverá oferecer, como entradas específicas deverão ser tratadas e qual o comportamento esperado em determinadas situações. Já os requisitos não funcionais tipicamente representam restrições sobre os serviços e/ou funções oferecidas pelo software (SOMMERVILLE, 2003).

Uma recomendação básica feita por Pfleeger (2004) para obtenção de requisitos e descobrir o que o usuário/cliente quer é observar os seguintes itens:• Analisar a situação atual.• Fazer com que o usuário aprenda a entender o contexto, os problemas e os

relacionamentos.• Entrevistar os usuários atuais e potenciais.• Produzir um modelo para mostrar como o novo sistema deverá operar;• Pesquisar a documentação existente.• Realizar um brainstorming com os usuários atuais e potenciais.• Observar as estruturas e os padrões.

Através dos requisitos são realizadas as descrições do fluxo de informações que entram e saem do sistema, a transformação dos dados pelo sistema, as restrições impostas pelo negócio para o qual o sistema está sendo construído, entre outros.

Pfleeger (2004) nos traz uma importante contribuição relacionando alguns tipos de itens de requisitos que tipicamente devem ser verificados e as perguntas que podem ser feitas para esclarecimento das dúvidas apresentadas:

• Ambiente físico • Onde o equipamento funcionará? • Esse funcionamento se dará em um ou em vários locais? • Existe alguma restrição ambiental, tal como temperatura, unidade ou

interferência magnética?• Interfaces • A entrada tem origem em outro ou outros sistemas? • A saída vai para outro ou outros sistemas?

48


• Existe uma maneira preestabelecida pela qual os dados devem ser formatados? • Existe alguma mídia definida, que os dados devem utilizar?• Os usuários e os fatores humanos • Quem utilizará o sistema? • Haverá diversos tipos de usuários? • Qual é o nível de habilidade de cada tipo de usuário? • Que tipo de treinamento será necessário para cada tipo de usuário? • Que facilidade o usuário terá para entender e utilizar o sistema? • Qual será a dificuldade para que o usuário utilize inadequadamente o

sistema?• Funcionalidade • O que o sistema realizará? • Quando o sistema o fará? • Existem diversos modos de operação? • Como e quando o sistema pode ser modificado ou aprimorado? • Existem limitações quanto à velocidade de execução, ao tempo de resposta, ou

à saída?• Documentação • Que documentação é necessária? • Essa documentação deve ser on-line, no formato de livro, ou ambos? • A que público se destina cada tipo de documentação?• Dados • Qual deverá ser o formato dos dados de entrada e saída? • Com que frequência eles serão enviados e recebidos? • Que precisão devem ter? • Com que grau de precisão os cálculos devem ser feitos? • Qual será o fluxo de dados do sistema? • Existem dados que devem ser mantidos por algum tempo?• Recursos • Que materiais, pessoal ou outros recursos são necessários para construir,

utilizar e manter o sistema? • Que habilidades os desenvolvedores devem ter? • Quanto espaço físico será ocupado pelo sistema? • Quais são os requisitos quanto à energia, ao aquecimento ou condicionamento

de ar? • Existe um cronograma definido para o desenvolvimento? • Existe um limite de custo para o desenvolvimento ou para a aquisição de

hardware ou de software?• Segurança • O acesso ao sistema ou às informações deve ser controlado? • Como os dados de um usuário serão isolados dos de outros usuários? • Como os programas dos usuários serão isolados de outros programas e do

sistema operacional? • Com que frequência é feito o backup (cópia de segurança) do sistema? • As cópias de segurança (backup) devem ser armazenadas em um local

diferente? • Devem ser tomadas precauções contra fogo, danos provocados pela água, ou

ocorrência de roubo?


49

• Garantia da qualidade • Quais são os requisitos quanto à confiabilidade, disponibilidade,

manutenibilidade, segurança e os outros atributos de qualidade? • Como as características do sistema devem ser demonstradas para os outros? • O sistema deve detectar e isolar defeitos? • Qual é o tempo médio entre falhas que foi determinado? • Existe um tempo máximo permitido para reiniciar o sistema, depois de uma

falha? • Como o sistema pode incorporar modificações no projeto? • A manutenção meramente corrigirá os erros ou também incluirá o

aprimoramento do sistema? • Que medidas de eficiência serão aplicadas à utilização dos recursos e ao

tempo de resposta? • Com que facilidade o sistema se deslocará de um local para outro, ou de um

tipo de computador para outro?

Para realização adequada do registro dos requisitos é recomendado que seja utilizado um padrão para facilitar o entendimento dos envolvidos sobre como interpretar o conteúdo da documentação. Sommerville (2003) sugere que a especificação de requisitos seja realizada utilizando uma ou mais das seguintes técnicas: linguagem natural estruturada, linguagem de descrição de projetos, notações gráficas e/ou especificações matemáticas.

QUADRO 2 – NOTAÇÕES PARA A ESPECIFICAÇÃO DE REQUISITOS

Notação Descrição

Linguagem natural estruturada

Essa abordagem depende da definição de formulários-padrão ou templates para expressar a especificação de requisitos.

Linguagem de descrição de projeto

Essa abordagem utiliza uma linguagem como uma linguagem de programação, mas com recursos mais abstratos para especificar os requisitos pela definição de um modelo operacional do sistema.

Notações gráficas

Uma linguagem gráfica, complementada com anotações de texto, é utilizada para definir os requisitos funcionais do sistema. Um exemplo anterior dessa linguagem gráfica foi SADT (Structured Analysis and Design Technique – Técnica de Análise e Design Estruturado). Mais recentemente, as descrições de casos de uso (use case) passaram a ser utilizadas.

Especificações matemáticas

São notações com base em conceitos matemáticos, como uma máquina de estados finitos e conjuntos. Essas especificações não ambíguas reduzem as discussões entre o cliente e fornecedor sobre a funcionalidade do sistema. Contudo a maioria dos clientes não compreende as especificações formais e reluta em aceita-las no momento de uma contratação de sistema.

FONTE: Sommerville (2003)

50


A abordagem recomendada é utilizar documentos padrões e nestes incluir elementos de notação gráfica no momento que for apropriado. A linguagem de descrição de projeto e especificações matemáticas possui utilização mais restrita e podem ser menos usuais na especificação de requisitos de negócios convencionais.

Sommerville (2003) sugere que o formulário padrão utilizado para especificação de requisitos funcionais inclua as seguintes informações:

• Descrição da função ou entidade que está sendo especificada.• Descrição de suas entradas e de onde elas se originam.• Descrição de suas saídas e para onde eles prosseguirão.• Indicação de que outras entidades são utilizadas (dependências ou interfaces).• Pré-condições para execução de uma função.• Pós-condições do que deve ser verdadeiro depois da execução da função.• Descrição dos efeitos colaterais da operação, se houver.

A documentação de requisitos tipicamente é realizada no documento de Especificação de Requisitos de Software (Software Requirements Specification). Este documento é a declaração oficial dos requisitos que devem ser implementados no novo software ou na manutenção evolutiva em curso.

Mas como podemos saber se os requisitos levantados têm a qualidade desejada para sustentar o desenvolvimento do software? Pfleeger (2004) sugere que seja verificado se os requisitos possuem as seguintes características:

• Os requisitos estão corretos?• Os requisitos são consistentes?• Os requisitos são completos?• Os requisitos são realistas?• Cada requisito descreve algo que é necessário para o cliente?• Os requisitos podem ser verificados?• Os requisitos podem ser rastreados?

Uma forma bastante simples e prática para fazer uso dessa técnica é aplicar este checklist aos requisitos especificados. À medida que o checklist for utilizado é muito provável que entre num ciclo de melhoria contínua, permitindo aperfeiçoar o processo de garantia da qualidade dos requisitos levantados.

Para guiar o trabalho de obtenção de requisitos pode-se adotar o processo de engenharia de requisitos ou requirements engineering. A engenharia de requisitos é o processo de descobrir, analisar, documentar e verificar as funções e restrições do software (SOMMERVILLE, 2003).

A engenharia de requisitos possui quatro atividades genéricas que envolvem o estudo de viabilidade do sistema, a obtenção e a análise de requisitos, a especificação de requisitos e sua documentação e validação dos requisitos obtidos.


51

Em relação aos requisitos de software Sommerville (2003) destaca alguns pontos-chave para os quais é importante darmos a devida atenção:

• Os requisitos para um sistema de software estabelecem o que o sistema deve fazer e definem restrições sobre sua operação e implementação.

• Os requisitos funcionais são declarações de funções que o sistema deve fornecer ou são descrições de como alguns cálculos devem ser realizados. Os requisitos de domínio são requisitos funcionais, provenientes de características do domínio de aplicação.

• Os requisitos não funcionais são os requisitos do produto, que restringem o sistema a ser desenvolvido, os requisitos de processo que se aplicam ao processo de desenvolvimento e os requisitos externos. Eles frequentemente se relacionam às propriedades emergentes do sistema e, portanto, se aplicam ao sistema como um todo.

• Os requisitos de usuário se destinam às pessoas envolvidas no uso e na aquisição do sistema. Eles devem ser escritos utilizando-se linguagem natural, tabelas e diagramas, de modo que sejam compreensíveis.

• Os requisitos de sistema se destinam a comunicar, de modo preciso, as funções que o sistema tem de fornecer. Para reduzir a ambiguidade, eles podem ser escritos em uma linguagem estruturada de algum tipo, que pode ser um formulário estruturado de linguagem natural, uma linguagem com base em uma linguagem de programação de alto nível ou uma linguagem especial para especificação de requisitos.

• O documento de requisitos de software é a declaração estabelecida dos requisitos do sistema. Ele deve ser organizado de modo que possa ser utilizado pelos clientes de sistema e pelos desenvolvedores de software.

A leitura complementar desta Unidade do Caderno de Estudos é um texto do livro “O mítico homem-mês”, de Frederick Phillips Brooks Jr. que explica de maneira bastante didática a relação entre quantidade de pessoas envolvidas no processo de desenvolvimento de software e a produtividade resultante. A primeira edição deste livro foi lançada no ano de 1975, mas parece que estamos vivendo atualmente exatamente o que o texto relata. Boa Leitura!

52


LEITURA COMPLEMENTAR

O MÍTICO HOMEM-MÊS

Cozinhar bem leva tempo. Se fazemos você esperar é para servi-lo melhor e deixá-lo satisfeito. Menu do Restaurante Antoine, Nova Orleans.

Em sua maioria, projetos de software falharam mais por falta de tempo no calendário do que em função da combinação de todas as outras causas. Porque isso é tão comum?

Em primeiro lugar, porque nossas técnicas para estimativa são muito pouco desenvolvidas. Na verdade, elas refletem uma premissa não verbalizada e completamente falsa que é a de que tudo correrá bem.

Em segundo lugar, porque nossas técnicas de estimativa falaciosamente confundem esforço com progresso, escondendo a premissa de que homens e meses são intercambiáveis.

Em terceiro lugar, porque não temos certeza de nossas estimativas. Aos gerentes de software costuma faltar a insistência cordial do chef do restaurante Antoine.

Em quarto lugar, porque o cronograma de progresso é monitorado de forma precária. Técnicas comprovadas, que são rotina em outras disciplinas de engenharia, são consideradas inovações radicais em engenharia de software.

Em quinto lugar, porque, quando se admite um atraso no cronograma, a resposta natural (e tradicional) é a adição de mais força de trabalho. Assim como combater um incêndio com gasolina, essa resposta torna a situação pior, muito pior. Mais fogo requer mais gasolina e, assim, inicia-se um ciclo de regenerativo que termina em um desastre.

O monitoramento do cronograma será assunto de ensaio à parte. Vamos considerar outros aspectos do problema com mais detalhes.

Otimismo

Todos os programadores são otimistas. Talvez essa feitiçaria moderna atraia, especialmente, aqueles que acreditam em finais felizes e fadas madrinhas. Talvez as centenas de pequenas frustrações afastem todos, menos aqueles que se focam, habitualmente, no objetivo final. Talvez esse otimismo seja meramente porque os computadores são jovens, os programadores mais jovens ainda e os jovens sempre são otimistas. Mas, independentemente da forma pela qual funciona o processo seletivo, o resultado é inegável: “Desta vez, com certeza vai funcionar”, ou “Acabo de encontrar o último erro”.


53

Assim a primeira falsa premissa inerente é confecção do cronograma de programação de um sistema é a de que tudo irá bem, isto é, que cada tarefa tomará apenas o tempo que “deve” tomar.

A disseminação do otimismo entre programadores merece mais do que uma rápida análise. Dorothy Sayers, em seu excelente livro The Mind of the Maker (A mente do criador), divide a atividade criativa em três estágios: a ideia, a implementação e a interação. Assim, um livro, um computador ou um programa passam a existir primeiro com um construto ideal, feito fora do tempo e do espaço, mas completo na mente do autor. Depois, se tornam reais no tempo e no espaço, com caneta, tinta e papel, ou com fios, silício e ferrite. A criação está concluída quando alguém lê o livro, usa o computador ou executa o programa, interagindo dessa forma com a mente do criador.

A descrição que a Senhoria Sayers utiliza para esclarecer não apenas a criatividade humana, mas doutrina cristã da Santíssima Trindade nos ajudará em nossa tarefa presente. Como criadores humanos de coisas, a incompletude e inconsistência de nossas ideias tornam-se claras apenas durante sua implementação. Assim, a escrita, a experiência e o exercício são disciplinas essenciais ao teórico.

Em muitas atividades criativas, o meio de execução é intratável. A madeira racha, a tinta escorre, os circuitos elétricos dão choque. Essas limitações físicas do meio cerceiam ideias que poderiam ser expressas e também criam dificuldades inesperadas em sua implementação.

A implementação, então, consome tempo e suor, tanto em função do meio físico como da inadequação das ideias que o utilizam. Temos a tendência de culpar o meio físico pela maioria das dificuldades de implementação, pois o meio não é “nosso” da mesma maneira que as ideias o são, e nosso orgulho colore nosso julgamento.

A programação de computadores, ao contrário, dá-se em um meio excepcionalmente tratável. O programador constrói a partir do pensamento puro, com conceitos e representações extremamente flexíveis. Como o meio é tratável, esperamos poucas dificuldades de implementação, daí esse otimismo dominante.

Mas, como nossas ideias têm falhas, nós temos problemas. Por isso, tanto otimismo não se justifica.

Em uma única tarefa, a premissa de que tudo correrá bem tem um efeito probabilístico no cronograma. Pode até acontecer que ela se dê conforme o planejado, já que existe a probabilidade de atrasos que serão solucionados, sendo que “nenhum atraso” tem, também, uma probabilidade finita. Um grande esforço de programação, porém, consiste em muitas tarefas, algumas encadeadas em dependência de outras. A probabilidade de que tudo vá bem se torna mínima.

54


O Homem-Mês

A segunda falácia se manifesta na própria unidade de esforço usada em estimativas e cronogramas: o homem-mês. O custo, de fato, varia como o produto de números de pessoas envolvidas e da quantidade de meses. O processo não. Dessa forma, o uso do homem-mês como unidade para medir o tamanho de um trabalho é um mito perigoso e enganoso. Ele implica o fato de que homens e meses são intercambiáveis.

Homens e meses são intercambiáveis apenas quando uma tarefa pode ser dividida entre muitos trabalhadores que não se comuniquem entre si (Figura 2.1). Isso é verdade quando se debulha trigo ou se colhe algodão, mas não é sequer aproximadamente real quando se trata de programação de sistemas.

FIGURA 2.1: Tempo versus número de trabalhadores em uma tarefa perfeitamente divisível.

Quando uma tarefa não pode ser dividida em função de limitações sequenciais, a aplicação de mais esforço não tem efeito algum no cronograma (Figura 2.2). Ter um filho leva nove meses, independentemente de quantas mulheres sejam responsáveis pela tarefa. Muitas tarefas de software têm essa característica em função da natureza sequencial de uma depuração (debugging).


55

FIGURA 2.2: Tempo versus número de trabalhadores em uma tarefa indivisível.

Em tarefas que podem ser divididas, mas que necessitam de comunicação entre as subtarefas, o esforço de comunicação deve ser adicionado á qualidade de trabalho a ser realizado. Assim, o melhor que pode ser feito é algo mais ineficaz do que a troca parelha entre meses e homens (Figura 2.3).

FIGURA 2.3: Tempo versus número de trabalhadores em uma tarefa divisível que requer comunicação.

56


O peso adicional da comunicação é composto de duas partes: treinamento e intercomunicação. Cada trabalhador deve ser treinado na tecnologia, nos objetivos do trabalho, na estratégia geral e no planejamento da execução. Esse treinamento não pode ser dividido, assim, parte do esforço adicional varia linearmente com o número de trabalhadores.

A intercomunicação é um fator mais grave. Se cada porção da tarefa deve ser separadamente coordenada com demais, o esforço aumenta em n(n-1)/2. Três trabalhadores requerem três vezes mais comunicação entre pares do que dois trabalhadores; quatro querem seis vezes mais do que dois. Se, além disso, há a necessidade de conferências entre três, quatro ou mais trabalhadores, para resolver questões em conjunto, a situação fica ainda pior. O esforço adicional de comunicação pode ir totalmente contra a divisão da tarefa original e levar à situação da Figura 2.4.

Como a construção de software é, por natureza, um trabalho sistemático – um exercício em inter-relações complexas – o esforço de comunicação é grande e rapidamente domina a diminuição do tempo de cada tarefa individual que foi estabelecido na sua divisão. A adição de mais homens, portanto, aumenta, e não diminui o tempo no cronograma.

FIGURA 2.4 - Tempo versus número de trabalhadores em uma tarefa com inter-relações complexas.

Testes de Sistema

Nenhuma outra parte do cronograma é tão profundamente afetada pelos limites sequenciais do que a depuração dos componentes e os testes do sistema. Além disso, o tempo requerido depende do número e da sutileza dos erros encontrados. Teoricamente, esse número deveria ser zero. Por causa do otimismo, o normal é esperarmos que o número de erros de programação (bugs) seja inferior ao que é na realidade. Por isso, a fase de testes costuma ser a de pior estimativa


57

em uma tarefa de programação.

Durante alguns anos, tive sucesso usando a seguinte regra geral para programar uma tarefa de software:

1/3 planejamento1/6 codificação 1/4 testes de componentes e testes iniciais do sistema1/4 testes do sistema, todos os componentes disponíveis.

Isso difere da programação convencional de um cronograma de várias formas importantes:

1. A fração dedicada ao planejamento é maior que a normal. Mesmo assim, ela é apenas marginalmente suficiente para produzir uma especificação detalhada e sólida e não o suficiente para incluir a pesquisa ou exploração de técnicas totalmente novas.

2. A metade do cronograma dedicada à depuração do código completo é muito maior que o normal.

3. Para a parte que é fácil de estimar, ou seja, a codificação dá-se apenas um sexto do cronograma.

Ao examinar projetos convencionalmente programados, descobri que poucos deixavam metade do cronograma para testes, mas que de fato usavam metade do cronograma real para esse propósito. Muitos deles estavam em dia, até entrar na fase de testes do sistema.

A falha em permitir tempo para testes do sistema, em particular, é peculiarmente desastrosa. Como o atraso acontece no final do cronograma, ninguém está a par do problema até quase a data de entrega do projeto. Notícias ruins, atrasadas e sem aviso prévio, são incômodas para clientes e gestores.

O mais grave é que, neste ponto, o atraso tem repercussões anormais e severas, tanto financeiras quanto psicológicas. O projeto está com a equipe completa, e o custo por dia está em seu máximo. Mais seriamente, o software deve dar suporte a outros esforços de negócio (remessa de computadores, operação de novas filiais etc.) e os custos secundários do atraso de tais esforços são muito altos, pois está próximo o momento de entrega do software. De fato, esses custos secundários podem ultrapassar bastante todos os demais. Por isso, é muito importante permitir tempo suficiente para os testes do sistema na programação original.

Estimativa desembasada

Observe que, tanto para o programador como para seu chefe, a urgência do cliente pode governar a data de finalização programada para uma tarefa, mas não pode governar sua finalização real. Uma omelete prometida para dois

58


minutos pode dar a impressão de que tudo está indo bem. Mas, se a omelete não fica pronta em dois minutos, o cliente tem duas opções: esperar ou comê-la cru. Os clientes de software têm tido as mesmas opções.

O cozinheiro tem uma alternativa: ele pode aumentar o fogo. O resultado não raro é algo que não pode ser salvo – queimado em uma parte, cru em outra.

Agora, eu não penso que gerentes de software têm coragem e firmeza inerentes que sejam menores do que as de um chef, nem que as de outros gerentes de outras áreas de engenharia. Mas o agendamento enganoso para atender ao desejo que o cliente tem por uma determinada data é muito mais comum na nossa disciplina do que em qualquer outra engenharia. É muito difícil fazer uma defesa vigorosa, plausível, com risco para o nosso trabalho, de uma estimativa que não é derivada de nenhum método quantitativo, suportada por poucos dados e garantida principalmente por palpites de gerentes.

E claro que são necessárias duas soluções. Precisamos desenvolver e publicar números de produtividade, números de incidência de erros, regras para estimativas e assim por diante. Toda a profissão pode apenas lucrar com o compartilhamento de tais dados.

Enquanto a estimativa basear-se em palpite, os gerentes individuais precisam calejar sua pele e defender tais estimativas com a garantia de que seus fracos chutes são melhores do que cronogramas derivados de desejos.

Desastre do Cronograma Regenerativo

O que fazer quando um projeto de software essencial está atrasado? Inclua mais pessoas, naturalmente. Como as Figuras 2.1 até 2.4 mostram, isso pode ajudar ou não.

Vamos considerar um exemplo. Suponha que uma tarefa é estimada em 12 homens-mês, entregue a três homens por quatro meses, e que existem pontos mensuráveis de verificação A, B, C, D, que estão programados para ocorrer ao final de cada mês (Figura 2.5).

Agora imagine que o primeiro ponto de checagem não é atingido até que se passem dois meses (Figura 2.6). Quais são as alternativas que se apresentam ao gerente?

1. Assuma que a tarefa deve ser concluída a tempo. Assuma que houve erro apenas na estimativa da primeira parte da tarefa, assim, a Figura 2.6 informa corretamente a situação. Dessa forma, nove homens-mês de esforços ainda restam, e dois meses, então 4 ½ homens serão necessários. Adicione dois homens aos três já designados.


59

2. Assuma que a tarefa deve ser concluída a tempo. Assuma que a estimativa está uniformemente baixa. Dessa forma, a Figura 2.7 realmente descreve a situação. Os 18 homens-mês de esforço ainda restam, e dois meses, assim, nove homens serão necessários. Adicione seis homens aos três previamente designados.

FIGURA 2.5

FIGURA 2.6

3. Reprograme. Aprecio muito o conselho de P. Fagg, experiente engenheiro de hardware: "Não aceite pequenos atrasos". Isso significa permitir tempo suficiente no cronograma para garantir que o trabalho possa ser feito de forma cuidadosa e atenta e que reprogramações não precisem ser feitas.

4. Redimensione a tarefa. Na prática, isso tende a acontecer de qualquer maneira quando a equipe detecta um atraso no cronograma. Quando os custos secundários do atraso são muito altos, essa é a única ação factível. As únicas alternativas do cliente são redimensionar a tarefa formal e, cuidadosamente, reprogramar o cronograma, do contrário ele terá de observar a tarefa sendo silenciosamente prejudicada por um projeto apressado ou por testes incompletos.

60


FIGURA 2.7

Nos primeiros dois casos, é um desastre insistir que a tarefa inalterada esteja concluída em quatro meses. Analise os efeitos regenerativos, por exemplo, da primeira alternativa (Figura 2.8). Os dois novos homens, mesmo competentes e rapidamente contratados, precisarão de treinamento na tarefa com a orientação de um dos programadores experientes. Se esse treinamento levar um mês, três homem-meses estarão devotados a trabalhar fora da estimativa original. Além disso, a tarefa originalmente dividida em três terá que ser redividida em cinco partes e, assim, algum trabalho já efetuado se perderá e mais tempo terá de ser dado aos testes do sistema. Logo, ao final do terceiro mês, substancialmente mais do que sete homens-meses de esforços ainda restarão, e cinco pessoas treinadas e um mês são o que está disponível. Como a Figura 2.8 apresenta, o produto estará tão atrasado quanto já estaria se ninguém fosse adicionado ao projeto (Figura 2.6).

Para manter a esperança de terminar o trabalho em quatro meses, considerado apenas o tempo de treinamento e não a redistribuição das tarefas e testes extras do sistema seria necessária a adesão de quatro homens, não dois, ao final de segundo mês. Para cobrir os efeitos da redistribuição e dos testes do sistema, seria necessário adicionar ainda outro homem. Agora se tem, entretanto, uma equipe de ao menos sete homens, não uma de três. Assim, aspectos organizacionais da equipe e da divisão de tarefas são diferentes com espécie, não apenas em grau.


61

FIGURA 2.8

Note que ao final do terceiro mês a situação parece tenebrosa. O ponto de checagem de 1o. de março não foi atingido, apesar de todo o esforço gerencial. A tentação de repetir o ciclo é muito forte, adicionando ainda mais homens. E aí que se chega à fronteira da loucura.

O que foi feito a seguir baseou-se na constante presença da premissa de que apenas o primeiro ponto de checagem foi mal estimado. Se, em 1º de março, fosse assumida a premissa conservadora de que todo o cronograma foi otimista, como mostra a Figura 2.7, seriam adicionados seis homens apenas para a tarefa original. O cálculo dos efeitos do treinamento, da revisão dos testes do sistema fica como um exercício para o leitor. Sem dúvida, o desastre regenerativo levará a um produto mais pobre com mais atraso do que levaria a reprogramação do cronograma com os três homens originais, sem novas adições.

Simplificando ao máximo, declaramos a lei de Brooks:

A adição de recursos humanos a um projeto de software atrasado ira atrasá-lo ainda mais.

Eis aqui, então, a desmitificação do homem-mês. O número de meses de um projeto depende de seus limites sequenciais. O número máximo de homens depende do número de subtarefas independentes. A partir dessas duas quantidades é possível deduzir cronogramas, usando menos homens e menos meses. (O único risco é a obsolescência do produto.) Não é possível, entretanto, ter cronogramas funcionais utilizando mais homens e menos meses. Projetos de software falharam, em sua maioria, mais por falta de tempo no calendário do que em função da combinação de todas as outras causas.

FONTE: BROOKS, Frederick Phillips. O mítico homem-mês: ensaios sobre engenharia de software. Rio de Janeiro: Elsevier, 2009, p. 14-24.

62

RESUMO DO TÓPICO 3


• Requisitos são características que o software deverá ter capacidade para realizar objetivando resolver algum problema, dar suporte a alguma oportunidade ou atender a necessidades de negócio.

• Os requisitos são a base sobre a qual se apoiará todo o restante do processo de software. Falhas nesta atividade poderão ter consequências catastróficas nas fases posteriores do processo.

• Os objetivos da fase de definição de sistema são: • Identificar as necessidades dos usuários. • Avaliar a concepção do sistema. • Executar uma análise econômica e técnica. • Atribuir funções aos elementos do sistema. • Estabelecer restrições de prazo e custo. • Criar uma definição de sistema para apoiar as demais fases de engenharia.

• Requisitos de usuário são funções e restrições que deverão ser suportadas pelo software, tipicamente declaradas de forma descritiva e/ou gráfica.

• O uso de técnicas de refinamento de requisitos como o método KISS (Keep it Simple, Stupid) para software pode trazer resultado significativos ao processo.

• A engenharia de requisitos organiza os processos de obtenção, análise, documentação e verificação das funções e restrições de software.

63


1 O que são requisitos de sistema?

2 A categorização de requisitos de acordo com sua importância e/ou relevância é uma técnica recomendada. Qual das categorias de requisitos descritos deve ser implementada primeiro?

3 Onde é registrada a especificação de requisitos utilizando a notação de linguagem natural estruturada?

4 Indique uma das características para indicar a qualidade necessária para sustentar o desenvolvimento do software.

AUTOATIVIDADE

65

UNIDADE 2

DESIGN E DESENVOLVIMENTO DE SOFTWARE


PLANO DE ESTUDOS

A partir desta unidade você será capaz de:

• compreender os fundamentos de design de software;

• entender aspectos relevantes sobre design de software;

• entender aspectos do desenvolvimento de software;

• conhecer boas práticas de gerenciamento de projetos de software.

Esta unidade está dividida em três tópicos, sendo que ao final de cada um deles, você encontrará atividades que lhe auxiliarão na apropriação dos co-nhecimentos.

TÓPICO 1 – DESIGN DE SOFTWARE

TÓPICO 2 – DESENVOLVIMENTO DE SOFTWARE

TÓPICO 3 – GERENCIAMENTO DE PROJETOS DE SOFTWARE

67

TÓPICO 1

DESIGN DE SOFTWARE

UNIDADE 2

1 INTRODUÇÃOAo decidir pela construção de algo, seja tangível ou intangível, há uma

série de etapas que são comuns. Ao optar por construir uma casa você decide qual será o processo construtivo a ser adotado. Este processo poderá ser linear, incremental ou iterativo.

Você também definirá quais são os requisitos da sua construção. No caso do exemplo da casa, é a definição da quantidade de cômodos, banheiros, tipo de acabamento, tamanho da garagem, estilo do telhado etc.

A etapa seguinte é transformar estes requisitos em uma planta para que uma equipe de obras civis possa realizar a construção. Esta planta incluirá uma série de aspectos que deverão ser seguidos para que os requisitos funcionais e não funcionais sejam atendidos.

Na Engenharia de Software a fase de desenho da planta da construção civil corresponde à fase de design de software.

O objetivo do design de software é prover uma descrição da estrutura de funcionamento que servirá de base para a construção do software. Também pode ser entendido como a descrição da forma que o sistema terá quando estiver pronto para utilização. O termo descrição pode ser entendido como uma representação, que poderá ser textual ou gráfica.

Pfleeger (2004, p. 159) nos ensina que o design de software é o “processo criativo de transformar o problema em uma solução”. O design de software é, portanto, a descrição da estrutura a ser construída para que o software realize as funções desejadas. É a definição de como os elementos estarão dispostos para atender aos requisitos.

Esta estrutura que permitirá atender aos requisitos funcionais e não funcionais é denominada arquitetura de software. A arquitetura de software “é uma descrição compacta e administrável de como um sistema é organizado e de como os componentes operam entre si”. (SOMMERVILLE, 2003, p. 182).

UNIDADE 2 | DESIGN E DESENVOLVIMENTO DE SOFTWARE

68

Componentes de software é um termo utilizado para designar um elemento de software que realiza determinadas funcionalidades. Este elemento pode representar uma unidade independente que em conjunto com outros componentes pode formar um software mais complexo ou um sistema. A utilização deste termo nesta unidade do Caderno de Estudos não possui relação com componentes visuais tipicamente disponíveis em algumas ferramentas de desenvolvimento.

UNI

Da mesma forma que a planta da casa é fundamental na sua construção, a arquitetura de software é a base que determinará os recursos que o software poderá oferecer. Um software monolítico terá características de recursos diferentes de um software orientado a serviços. No momento do design é necessário ter claro o que o software precisará para definir a arquitetura adequada.

2 TIPOS DE DESIGN

Em determinados momentos do processo de software há necessidade de utilização do design para comunicar como o software será construído para pelo menos dois públicos. O desenho do software pode ser utilizado para comunicação com o cliente/usuário ou com a equipe de desenvolvimento. São eles o design conceitual e o design técnico.

Caro acadêmico! Neste Caderno de Estudos o termo cliente/usuário é utilizado para designar os interessados em fazer uso do software.

UNI

O desenho que será utilizado na comunicação com o cliente/usuário é chamado de design conceitual e consiste num modelo mais superficial do software. O modelo conceitual tem a finalidade de esclarecer ao cliente/usuário como o software desempenhará as funções necessárias. Este desenho pode ser utilizado como uma poderosa ferramenta para validação do entendimento dos requisitos do software.

O design conceitual descreve os limites, as entidades, atributos e relacionamentos do sistema. Esta descrição poderá responder a questões como (PFLEEGER, 2004):

TÓPICO 1 | DESIGN DE SOFTWARE

69

• De onde virão os dados?• O que acontecerá com os dados no sistema?• Qual será a aparência do sistema para os clientes/usuários?• Que opções serão oferecidas para os clientes/usuários?• Qual é a sequência de eventos?• Como será a aparência dos relatórios e das telas?

Este modelo de design não deverá utilizar termos técnicos e não se concentra em detalhes técnicos. Não é objetivo deste design demonstrar como os dados serão manipulados pelos algoritmos ou de que forma serão armazenados. Pfleeger (2004) sugere que um bom design conceitual deve ter as seguintes características:

• Ser escrito na linguagem do cliente/usuário.• Não conter jargão técnico.• Descrever as funções do sistema.• Ser independente da implementação.• Estar vinculado aos documentos de requisitos.

Portanto, o design conceitual deverá possibilitar ao cliente/usuário o entendimento do que o sistema fará, o que oferecerá de resultados e também esclarece as características externas observáveis do sistema.

Já o desenho que será utilizado na comunicação com a equipe de desenvolvimento é chamado de design técnico. Este modelo tem a finalidade de explicitar os componentes de software necessários para atender às necessidades do cliente/usuário. O design técnico pode compreender inclusive componentes de hardware que precisam ser considerados na construção da solução proposta.

No design técnico devem ser considerados diversos requisitos necessários à solução do problema do cliente/usuário. Estes requisitos podem incluir alguns elementos como:

• Configurações de hardware.• Necessidades de software.• Interfaces de comunicação.• Entradas e saída do sistema.• Arquitetura de rede utilizada.

Um componente de software é um elemento de software que executa uma ou mais funções. Este tipicamente executa funções específicas completas que servem de apoio a outros componentes. Pode ser entendido como um conjunto coeso de funções que pode ser executado para realização de uma função ou serviço.

Em relação às interfaces de comunicação é importante observar que estas não têm a ver com interfaces com usuário que tipicamente são descritas na forma


70

de telas ou formulários. As interfaces de comunicação do design de software são o formato de comunicação utilizado entre componentes de software.

Este formato de comunicação poderá, por exemplo, se referir ao nome da chamada de um procedimento remoto e os parâmetros que deverão ser informados. Ou ainda, dependendo da tecnologia e arquitetura utilizada, pode se referir à requisição de um serviço fornecendo parâmetros em formato XML (Extensible Markup Language).

3 ARQUITETURA DE SOFTWARE

Softwares que possuem grande conjunto de requisitos tipicamente são divididos ou decompostos em diversos subsistemas que oferecem o conjunto de serviços necessários para o software cumprir sua função. O processo de definição de quais serão estes subsistemas, os controles necessários e a comunicação de tais subsistemas são conhecidos como o projeto de arquitetura do software.

A arquitetura de software é, portanto, a estrutura de organização e divisão dos módulos que o compõem. Ela é dita como o conjunto de controles necessários para o adequado funcionamento harmonioso das partes e também a forma como estas partes se comunicam para cumprir com as funções necessárias.

A arquitetura de um software é um dos elementos mais importantes que deve ser definido no momento de sua construção. Tão importante quanto à definição é documentar adequadamente essa arquitetura. Bass et al. (1998), citado por Sommerville (2003), indica três vantagens de projetar e documentar explicitamente uma arquitetura de software:

• Comunicação com stakeholders: a documentação da arquitetura pode ser utilizada como uma representação do software para eventuais discussões.

• Análise de sistema: a documentação da arquitetura permite realizar análises sobre a possibilidade de o software poder ou não cumprir requisitos importantes como desempenho, confiabilidade e facilidade de manutenção.

• Reutilização em larga escala: um padrão de arquitetura pode ser utilizado para servir a um conjunto de softwares relacionados.

Cada arquiteto ou projetista de software pode utilizar diferentes enfoques para o processo de design de arquitetura, pois é uma atividade que tem forte dependência dos conhecimentos e habilidades do profissional. Independente da abordagem utilizada no processo de design da arquitetura, Sommerville (2003) destaca que as seguintes atividades são tipicamente comuns:

• Estruturação do sistema: é o processo de definição dos subsistemas que comporão o software e a comunicação existente entre eles.

• Modelagem de controle: é a definição de como será realizado o controle do relacionamento entre as partes do software.


71

3 ARQUITETURA DE SOFTWARE

• Decomposição modular: é a definição da decomposição em módulos e as suas interconexões.

Tipicamente este conjunto de atividades é realizado de forma intercalada e pode ser realizado através de ciclos de refinamento. O nível de detalhamento dado dependerá da criticidade da necessidade de averiguar se o design de arquitetura permitirá ao software cumprir seus requisitos.

Em relação à arquitetura de software, a grande dúvida sobre o assunto está relacionada ao modelo ideal a ser adotado. Seria ótimo para os profissionais de software se houvesse um modelo arquitetural que solucionasse, por exemplo, a dificuldade de acompanhar a velocidade de evolução dos requisitos e os avanços das ferramentas de desenvolvimento.

Caso a arquitetura utilizada seja um modelo de software monolítico a rigidez poderá ser bastante alta. Já na utilização de uma arquitetura orientada a serviços (SOA – Service Oriented Architecture), a flexibilidade poderá ser bem maior. Porém isso poderá não ser verdade para todas as situações que um profissional de software possa enfrentar.

Há, sim, arquiteturas que facilitam o processo de integração de diferentes tecnologias e outras que são mais rígidas. Com o passar dos tempos é comum que diferentes modelos arquiteturais sejam utilizados e que de alguma forma estes coexistam, principalmente em softwares de grande porte.

Em relação aos impactos da arquitetura, Sommerville (2003) relata que ela afeta o desempenho, a robustez e a facilidade de distribuição e manutenção do software. Ele argumenta ainda que o modelo escolhido pode depender dos requisitos não funcionais do software, como:

• Desempenho: se o desempenho for um requisito importante, a arquitetura deverá considerar a necessidade de manter as operações mais importantes acopladas de maneira que ocorra o mínimo de comunicação possível entre subsistemas ou módulos.

• Proteção: um requisito de maior proteção exigirá que a arquitetura seja desenhada em camadas de forma a proteger as funções mais importantes em camadas inferiores.

• Segurança: os requisitos de segurança tipicamente exigem que as operações relacionadas à segurança sejam escritas em um subsistema ou no menor conjunto possível de subsistemas.

• Disponibilidade: requisitos de disponibilidade exigirão da arquitetura o desenho de componentes redundantes que permitam a substituição e atualização de componentes sem a necessidade de interrupção na execução do software (hot deploy);

• Facilidade de manutenção: para melhorar a facilidade de manutenção é necessário que a arquitetura seja desenhada de forma a conter componentes


72

encapsulados com menor granularidade para que possam ser rapidamente modificados. Uma boa prática é evitar o compartilhamento de estruturas de dados entre componentes.

Conforme você já estudou em outras partes desse Caderno de Estudos, não há modelo de solução universal e a “natureza força ao equilíbrio”. Independente da forma como isso seja dito, significa que quanto maior for a quantidade de requisitos do software, mais complexa poderá ser sua arquitetura.

Esta complexidade poderá ser exigida, por exemplo, pela existência de requisitos não funcionais conflitantes como desempenho e facilidade de manutenção. O requisito de desempenho pede que a arquitetura utilize componentes com maior granularidade, já a facilidade de manutenção pede a utilização de componentes com menor granularidade.

Uma forma simples para entender o conceito de granularidade é pensar num sistema monolítico. Um sistema monolítico possui a maior granularidade possível, ou seja, é composto de apenas um componente. Sistemas que possuem várias partes que se comunicam entre si são chamados de sistemas de menor granularidade.

A questão da granularidade é muito importante e deve ser devidamente considerada no momento do desenho da arquitetura. Softwares com granularidade baixa são mais flexíveis em termos de integração ou adição de módulos ou subsistemas, porém esta flexibilidade pode cobrar o preço de oferecer menor desempenho.

Esta redução no desempenho ocorre em parte pela sobrecarga (overhead) causada pela necessidade de comunicação entre diferentes componentes. Quanto maior for a quantidade de componentes que precisarem se comunicar para a realização de determinada função, maior será a sobrecarga e consequentemente menor será o desempenho.

É necessário observar que não podemos sacrificar a arquitetura exclusivamente em função do desempenho. O hardware disponível também poderá ser considerado na decisão e este está oferecendo cada vez mais poder de processamento e recursos acessíveis.

4 MODULARIDADE

No processo de definição do design mais adequado ao software, outra tarefa bastante árdua é a definição da modularidade. É uma tarefa árdua pelo fato de haver diversos fatores envolvidos na decisão da distribuição do software em módulos. Wassermann (1990), citado por Pfleeger (2004), indica que o design de um software seja criado com base em um dos seguintes modos:


73

4 MODULARIDADE

• Decomposição modular: utiliza como base a atribuição de funções aos componentes, descrevendo as funções que serão implementadas, como cada componente será organizado e como se relacionará com os demais componentes.

• Decomposição orientada a dados: nessa abordagem, as estruturas de dados externos são utilizadas para descrever como os dados estarão relacionados e quais dados serão envolvidos.

• Decomposição orientada a eventos: os eventos previstos, os possíveis estados de eventos, como eles modificam o estado do sistema e como as transformações de estados ocorrem são a base para esta abordagem.

• Design ‘outside-in’ (de fora para dentro): utilizam como base as entradas do usuário, o que é feito com estas entradas e as saídas que devem ser produzidas.

• Design orientado a objetos: utilizam as classes de objetos, descrição de cada tipo de objeto, atributos, métodos e o relacionamento entre as classes.

O design de software pode ser elaborado através de uma das abordagens descritas ou a partir da combinação de algumas dessas abordagens. A ideia central é utilizar uma hierarquia, aumentando o detalhamento a cada nível.

De acordo com Pfleeger (2004, p. 163), “dizemos que um sistema é modular quando cada atividade do sistema é realizada por exatamente um componente, e quando as entradas e saídas de cada componente são bem definidas”. Um componente bem definido é aquele em que todas as entradas são essenciais à sua função e todas as saídas são produzidas por uma de suas funções.

Esta abordagem permite ao profissional de software, neste caso, tipicamente denominado de arquiteto de software, utilizar o design para explicar características do software no nível de detalhes necessário. O arquiteto de software geralmente descreve o design de software de forma top-down ou botton-up.

Na forma top-down parte-se do todo para as partes, ou seja, é realizada uma decomposição do sistema em suas partes componentes. Já na forma botton-up ocorre o contrário, analisam-se as partes para compor o todo. Cada abordagem pode ser utilizada de acordo com o que há de informação disponível para a construção do novo software.

O nível de detalhamento do design dependerá de alguns fatores que podem incluir risco do projeto, necessidade de definições detalhadas para seleção da abordagem adequada, complexidade da aplicação, criticidade da aplicação, entre outros. Shaw e Garlan (1996) citados por Pfleeger (2004) distinguem os seguintes níveis de design:

• Arquitetura: descrição do software através dos componentes e suas interconexões.

• Design de código: detalhamento de design em nível de algoritmos e estruturas de dados.

• Design executável: trata do nível de alocação de memória e formato dos dados.


74

Conceitualmente pode-se entender que o design de software pode iniciar na arquitetura e descer para os demais níveis conforme necessário em cada projeto. Na prática, o que se observa é que os arquitetos de software e até mesmo projetistas navegam entre estes níveis, à medida que entendem mais sobre a solução e as suas implicações.

5 DESIGN DE INTERFACES COM O USUÁRIO

O design de interface com o usuário pode iniciar na fase de requisitos para os casos em que há necessidade de explicitar algumas interfaces críticas da aplicação. Porém o maior volume de trabalho ocorre na fase de design. É nesta fase que as interfaces com o usuário são desenhadas.

Embora possa parecer simples, se considerarmos a importância que as interfaces com o usuários representam para um software, chegaremos à conclusão de que é uma atividade com grau de complexidade relativamente alto. Para o usuário convencional o software é aquilo que ele vê, ou seja, a interface.

Assumindo a premissa de que o usuário considera que o software é representado principalmente pelas suas partes visíveis, o seu design pode ser crítico para determinados projetos. Considerando esta importância, Marcus (1993), citado por Pfleeger (2004), indica que uma interface com o usuário deve abordar:

• Metáforas: elementos que podem ser reconhecidos e aprendidos.• Modelo mental: organização e representação de elementos.• Regras de navegação para o modelo: como se mover entre os elementos.• Aspecto: aparência do sistema.• Impressão: experiência do usuário.

O objetivo de considerar tais elementos é permitir que o usuário obtenha acesso rápido ao conteúdo que necessita, sem que perca a compreensão enquanto navega pelas informações. Para tal, podem-se utilizar diversos recursos tecnológicos como avatares, som, hipertexto, agentes, entre outros.

Para que a interface com o usuário possa oferecer uma experiência confortável e efetiva aos usuários do software, duas questões fundamentais devem ser consideradas em seu design: cultura e preferência (PFLEEGER, 2004).

Quando o software é desenvolvido para uso por uma grande diversidade de usuários que podem abranger o país ou quem sabe o mundo, é necessário que se considere diversos aspectos relacionados a este possível público. Os aspectos que devem ser considerados são as crenças, valores, normas, tradições, hábitos e até mesmo os mitos daqueles que utilizarão o software.


75

5 DESIGN DE INTERFACES COM O USUÁRIO

No momento do design de interfaces com o usuário devem ser eliminadas quaisquer referências ou tendências culturais específicas, tornando a interface mais “imparcial” possível. Isso inclui a flexibilidade de tamanho das janelas de mensagens que podem variar de acordo com o idioma utilizado. A internacionalização do dicionário do software deve permitir armazenar separadamente o texto e imagens para que seja mais fácil modificá-las.

As cores também podem ter significados muito relevantes. “Na Inglaterra, a cor púrpura representa a realeza, e, no Japão, púrpura significa dignidade e nobreza. Mas na Grécia antiga, púrpura simboliza a morte e o demônio”. (FUKUDA, 1994 apud PFLEEGER, 2004, p. 175).

É importante observar que as questões culturais não são determinadas apenas pela nacionalidade, mas outros aspectos como área profissional, religião ou fatores da cultura da organização. Esta situação é uma representação clara de que é difícil para os desenvolvedores assumirem que entendem o que o cliente/usuário quer.

Quando o software em desenvolvimento será utilizado por um grupo de usuários internos à organização, o nível de complexidade dessa tarefa se torna bastante menor. Ao atender a demandas internas, há maior controle e entendimento sobre este e outros aspectos que poderão causar impactos para os clientes/usuários.

Em relação aos aspectos de preferência, o nível de complexidade pode ser ainda maior, pois lida com uma gama mais ampla de possibilidades dentro de um público reduzido. As preferências podem incluir o tipo e tamanho da fonte utilizada no texto, os nomes dados às funções/opções do software e a distribuição das informações na interface.

O design de interface com o usuário pode ser realizado de maneira que se privilegiem os principais aspectos de cultura e preferência. Porém, acredita-se que não há um modelo de interface universal que possa ser aplicado a todas as culturas e que atenda a todas preferencias.

O desenvolvimento de interfaces com o usuário específicas para diversos tipos de público pode inviabilizar o projeto. Diversos projetos de software que se propõem a oferecer recursos de internacionalização estão em uso há anos e ainda não possuem conteúdo em seus dicionários para mais de uma língua, além da nativa.

Além dos aspectos de cultura e preferêcias há outras ponderações que precisam ser feitas pelo arquiteto ou projetista que podem levar a escolhas conflitantes. Deve-se privilegiar o desempenho ou as funções disponíveis? É mais relevante a facilidade de uso ou a segurança da aplicação?


76

Do ponto de vista do usuário, “a interface é o software”, portanto, não podemos ignorar a relevância de seu design. Será que todos os projetistas e arquitetos de software tem dado a devida atenção a este assunto? Fica a questão para sua reflexão.

6 INDEPENDÊNCIA DOS COMPONENTES

É desejado que todo software desenvolvido seja estruturado de forma a facilitar o processo de manutenção. Um design de software para poder ser considerado bom deveria possuir as seguintes características (PFLEEGER, 2004):

• Facilidade de entendimento.• Facilidade de implementação.• Facilidade de realização de testes.• Facilidade de modificação.• Tradução correta dos requisitos em software.

A facilidade para realizar modificações é um aspecto altamente relevante, pois a manutenção é tipicamente de longo prazo. É relativamente comum encontrarmos casos de alterações em requisitos ou correção de defeitos exigirem que o design do software seja modificado para acomodar a mudança necessária.

Uma das formas de atender à boa parte das características do que é considerado um bom design é privilegiar a independência de componentes. Desenhar software de maneira que os componentes sejam altamente independentes facilita o entendimento de como cada componente funciona.

A independência facilita o processo de modificação dos componentes, pois não causará impacto nos demais componentes. A identificação e isolamento de falhas, também se tornam mais simples. E a correção de falhas identificadas se torna uma atividade mais leve para os desenvolvedores.

Para o reconhecimento e medição do grau de independência dos componentes de um software são utilizados os conceitos de acoplamento e coesão. Estes são conceitos que devem ser considerados na fase de design de qualquer software.

O conceito de acoplamento diz respeito ao grau de dependência entre componentes. Dois componentes possuem alto grau de acoplamento quando existe grande dependência entre eles. Quanto menor a dependência entre os componentes de um software, menor será seu grau de acoplamento.

A coesão está relacionada à parte interna da construção do componente, ou seja, na relação entre as partes de um componente. Um componente possui alto grau de coesão se todo seu código possui funcionalidades relacionadas à


77

6 INDEPENDÊNCIA DOS COMPONENTES

realização da mesma tarefa e forem essenciais a ela. Quanto mais porções de código destinadas à realização de diferentes funções escritas no mesmo componente, menor será seu grau de coesão.

O design de software considerado ideal é aquele que possui baixo acoplamento e alta coesão. Você pode se perguntar: isso é a última tendência em termos de design de software instituída recentemente? A resposta é, não, essa é uma característica de design de software defendida desde a década de 1970.

Então, você pode se perguntar: por que os projetistas e arquitetos de software não consideram estes aspectos no design de seus softwares?

Fica a questão para sua reflexão. Provavelmente as respostas serão as mais variadas, pois cada equipe possui motivos que os levaram a construir softwares conceitualmente distantes do ideal.

Como forma de encerrarmos este tópico, vejamos alguns pontos-chave destacados por Sommerville (2003) em relação à arquitetura de software:

• A arquitetura de software é o framework fundamental para a estruturação do sistema. Diferentes modelos de arquitetura como o modelo estrutural, um modelo de controle e um modelo de decomposição, podem ser desenvolvidos durante o projeto de arquitetura.

• Os grandes sistemas geralmente são compatíveis com um único modelo de arquitetura. Eles são heterogêneos e incorporam diferentes modelos em diferentes níveis de abstração.

• Os modelos de decomposição de sistemas incluem modelos de repositório, modelos cliente-servidor e modelos de máquina abstrata. Os modelos de repositório compartilham dados por meio de um repositório comum. Os modelos cliente-servidor geralmente distribuem dados. Os modelos de máquina abstrata são organizados em camadas, em que cada camada é implementada com o uso dos recursos fornecidos pela sua camada.

• Os modelos de controle incluem os modelos de controle e de evento centralizados. Nos modelos centralizados, as decisões de controle são feitas e dependem do estado do sistema e nos modelos de evento, os eventos externos controlam o sistema.

• Os modelos de decomposição em módulos incluem os modelos de fluxos de dados e de objeto. Os modelos de fluxo de dados são funcionais, enquanto os modelos de objeto têm como base, entidades fracamente associadas, que mantêm seu próprio estado e suas operações.

• Os modelos de arquitetura de domínio específico são abstrações em relação a um domínio de aplicação. Os modelos de domínio específico podem ser modelos genéricos construídos botton-up a partir de sistemas existentes ou podem ser modelos de referência, que são os modelos abstratos e idealizados do domínio.

78

RESUMO DO TÓPICO 1Caro(a) acadêmico(a)! Nesse tópico, você estudou que:

• O design conceitual é aquele desenvolvido para facilitar a comunicação com o cliente/usuário. Este design deve privilegiar os processos de negócio e requisitos funcionais, pois pode ser utilizado como uma importante ferramenta de validação do entendimento das necessidades do cliente/usuário.

• O design técnico é aquele desenvolvido para comunicar questões técnicas à equipe de desenvolvimento. Ele, tipicamente, privilegia requisitos não funcionais exigidos para atendimento dos requisitos funcionais definidos para o software.

- Projetar e documentar a arquitetura de software explicitamente facilita:- Comunicação com stakeholders.- Análise de sistemas.- Reutilização em larga escala.

• O modelo de arquitetura do software pode ser selecionado em função de requisitos não funcionais como:

- Desempenho.- Proteção.- Segurança.- Disponibilidade.- Facilidade de manutenção.

• O design de interfaces com o usuário deve abordar:- Metáforas.- Modelo mental.- Regras de navegação para o modelo.- Aspecto.- Impressão.

79

AUTOATIVIDADE


1 Liste três elementos que devem ser considerados no design técnico.

2 Descreva o que você entende por granularidade de software.

3 Quais são as questões fundamentais que devem ser consideradas no design de interface?

4 Liste três características de um bom design de software.

81

TÓPICO 2

DESENVOLVIMENTO DE SOFTWARE

UNIDADE 2

1 INTRODUÇÃO

A partir do momento que um conjunto de requisitos está descrito, documentado e validado com os clientes/usuários há elementos para iniciar o design do software. Tipicamente os artefatos gerados nessa fase são descrições textuais e desenhos que explicitem o que se pretende que o software ofereça de funcionalidades.

Estes artefatos são utilizados então para se definir como o software deverá ser construído. Entra em cena a fase de design. Nela são definidas as estruturas de dados, estruturas de programas, interfaces com o usuário e interfaces de comunicação com outros softwares e entre os componentes dele.

De posse de todas estas definições e artefatos inicia-se a fase de tradução dos requisitos e design em software funcional. É nessa fase que entra em cena a arte da programação de computadores. Para que o software seja escrito de forma a atender requisitos de desempenho, proteção, segurança, disponibilidade e principalmente facilidade de manutenção.

Para tal, é fundamental que o processo criativo da programação se restrinja às soluções dadas aos desafios de implementação. Este processo criativo, portanto, deve seguir padrões de codificação, depuração e testes para que o código fonte seja legível e manutenível por qualquer pessoa que conheça os padrões.

Uma das fases que tipicamente tem consumido a maior fatia de esforço em um projeto de software é a fase de desenvolvimento, também conhecida como fase de codificação. Esta é a fase que tipicamente representa maior quantidade e custo de recursos humanos no processo de software.

2 PADRÕES DE CODIFICAÇÃO

Na fase de desenvolvimento deve ser dada grande atenção aos padrões de codificação. Padrões de codificação ou estilos de codificação se referem às convenções utilizadas para escrita de código fonte. Estes padrões ou estilos geralmente estão ligados com certo grau de intimidade à linguagem de programação utilizada.


82

A definição do que é um bom padrão/estilo de codificação é relativamente dependente da equipe de desenvolvimento em que se está inserido. Para determinadas equipes trabalhar utilizando um prefixo nas propriedades ou variáveis que identifique o tipo delas é uma das melhores práticas e que trazem resultados impressionantes.

Para outras equipes é considerada a coisa mais ridícula e inadmissível

já criada pelo homem. Embora estes sejam aspectos relevantes, neste Caderno de Estudos o foco será nomenclaturas de identificadores, tipos de retornos de funções, formas de testar laços de repetição, inicialização de variáveis, tamanho máximo (em colunas) de uma linha de código, tamanho máximo (em linhas) de um procedimento, função ou método.

Utilizar padronizações de código é muito importante se olharmos do ponto de vista do processo que mais consome recursos no desenvolvimento de software, a manutenção. A padronização de código pode ter valor incalculável do ponto de vista da redução da probabilidade de inserção de bugs em processos de manutenção e da agilidade que pode permitir no momento da detecção da origem de um determinado problema, além da facilidade de definir uma solução para a situação.

A padronização de código também permite que pessoas que não desenvolveram aquele trecho de código façam a sua manutenção com um nível de facilidade aproximado ao nível de facilidade de quem o escreveu. A legibilidade do código é um dos fatores que mais impactam na questão da padronização.

A legibilidade de código se refere a quão simples/fácil um trecho de código é para leitura e qual é a quantidade de pessoas que conseguem ler o código escrito (as palavras-chave são facilidade de entendimento). Não há uma medida precisa para a legibilidade, ela pode ser medida apenas pela quantidade de pessoas que conseguem ler o código com facilidade.

Alguns elementos podem facilitar a legibilidade como indentação, cores utilizadas para diferenciar palavras reservadas, tipos das variáveis, tamanho do texto (linha), utilização de negrito, etc. Um item muito importante que deve ser observado na legibilidade são as fórmulas. Quanto mais legível for a escrita de fórmulas, melhor.

Todos os identificadores de um programa devem ter nomes significativos.

A questão de nomes de identificadores também é muito controversa, pois tem quem defenda a utilização da separação das palavras com o uso de uma letra maiúscula e outros que defendem o uso de underline ( _ ) para esta tarefa. Independente da forma, o importante é estabelecer um padrão e segui-lo.

As declarações de variáveis devem ser feitas sempre que possível no início de blocos de código (isso significa que as variáveis devem sempre ser declaradas o mais próximas possível do início de um bloco de código). A técnica de declarar variáveis no momento que serão utilizadas deve ser evitada.

TÓPICO 2 | DESENVOLVIMENTO DE SOFTWARE

83

Isto evita que se declarem variáveis muito longe de onde elas serão utilizadas pela primeira vez. A declaração de variáveis em qualquer ponto pode induzir o programador a algum tipo de erro de interpretação, pois as declarações de variáveis feitas dentro do corpo do código podem tornar o código confuso.

Uma excessão para esta regra pode ser a declaração de uma variável para utilização num laço de repetição for, pois algumas linguagens permitem a declaração da variável dentro do cabeçalho deste. Deve-se dar preferência para a forma de declaração de variáveis onde cada variável é declarada em uma linha, pois melhora em muito a legibilidade do código.

Outra prática que deve ser evitada é a declaração de variáveis simples com vetores na mesma linha, isto torna o código bastante confuso para a leitura. Deve-se evitar a declaração de variáveis ou propriedades locais a um método com nomes iguais a variáveis ou propriedades já declaradas globalmente na classe. Este tipo de declaração pode causar sérios problemas de interpretação no momento de depurar ou manter algum código fonte.

As variáveis devem ser inicializadas o mais próximo possível de sua declaração. Uma excessão pode ser permitida quando o valor inicial desta depender de algum processamento que deverá ser realizado antes. Mesmo assim, se houver algum valor padrão, este deve ser atribuído à variável para que na pior das hipóteses, o valor padrão seja utilizado.

Por mais simples que seja uma função e independente das facilidades providas pela linguagem em uso, o retorno de uma função ou método não deve ser o resultado de um cálculo, atribuído como sendo o retorno. Este é um dos momentos em que economizar memória passa para o limite do exagero e pode tornar o software sensível a falhas.

Deve-se declarar uma variável que receberá o resultado da operação que precisa ser realizada e depois se atribui esta variável ao retorno da função ou método. Em linguagens baseada na sintaxe do C pode parecer muito interessante poder comandar o retorno diretamente pelo comando return, mas essa não é uma técnica recomendada.

Os iniciantes na programação têm uma tendência de não se importarem adequadamente com a questão da indentação, pois não conseguem identificar a real necessidade de ficar estruturando o código de forma a demonstrar a subordinação dos blocos de instruções.

Depois que passam a desenvolver algoritmos mais complexos é que começa a ficar nítida a vantagem de uma indentação adequada. Mesmo programadores mais experientes que se deparam com um código não endentado, geralmente precisam endentá-lo primeiro para depois conseguirem entender o que está programado. Num primeiro momento pode parecer uma questão puramente estética, mas tem muito mais a ver com a clareza da subordinação dos blocos de código do que com qualquer outra questão.


84

Não escrever linhas de código com mais de 90 caracteres. Códigos grandes devem ter a quebra de linhas após a vírgula, ou antes de um operador. Deve-se preferencialmente alinhar as demais linhas com o início da primeira linha da sentença. Quando houver quebras de linhas em sentenças que possuam parênteses, deve-se fazer o possível para que os parênteses fiquem na mesma linha ou que fique claro para quem ler o código onde inicia e onde termina o isolamento pelos parênteses.

Outra questão relevante é o espaçamento entre operandos e operadores. A legibilidade é seriamente afetada quando não há espaçamento entre operandos e operadores. É uma questão muito simples e que reduz a probabilidade de enganos no momento de ler o código.

Além disso, aumenta a velocidade com que se consegue ler o que está escrito, principalmente quando a operação possuir operadores lógicos (E e OU), pois haverá pelo menos duas operações sendo realizadas e será necessário visualizar com a máxima clareza possível as operações envolvidas na expressão.

Linguagens que não requerem que se obedeça a um colunamento dos comandos, ou seja, de formato livre não consideram espaços, logo o estilo de indentação utilizado deve levar em consideração os impactos para os desenvolvedores.

Deve-se considerar também a importância do uso de parênteses para priorizar operações. Faça uso de parênteses sempre que houver a necessidade de priorização de operações, mesmo que a linguagem a garanta.

Cada tipo de laço de repetição deve ser utilizado para a situação mais apropriada. Em situações em que os limites inicial e final são conhecidos, deve-se utilizar o for. Onde se sabe que pelo menos uma vez o código será executado antes que qualquer teste de continuação precise ser executado pode-se utilizar a estrutura do-while.

Nas demais situações utiliza-se o while. Os anos de experiência no uso e ensino de lógica de programação, algoritmos e estruturas de dados mostraram de forma empírica que iniciantes na área de programação têm a tendência de utilizar mais o while para laços de repetição.

Quando erros ou falhas são identificados no software pode ser necessário realizar o processo de depuração de código. O termo vem do inglês debug ou debugging, que é um processo metódico realizado com o objetivo de encontrar e eliminar bugs em programas. Bugs podem ser entendidos como "comportamentos" indesejados pela pessoa que programou o código.

A dificuldade da atividade de depuração é praticamente inversamente

proporcional ao grau de acoplamento de módulos de software. A dificuldade não está apenas no fato de todos os módulos terem que estar com as fontes atualizadas e localizadas de forma a executarem em conjunto.


85

A dificuldade de depuração de código em softwares com baixo grau de acoplamento está no fato de que a origem de um bug pode gerar um "comportamento" indesejado em um dos módulos que nada tenha a ver com o problema em si. Isso dificulta o trabalho de localização da origem do problema. Os passos para realizar a depuração de um código são os seguintes:

• Reconhecer a existência do bug: bugs podem ser de duas naturezas. Os que causam o término abrupto do programa e os que interferem nos resultados esperados pelo processamento de determinados dados. Os erros que causam término abrupto do programa, em geral, são mais fáceis de serem detectados e consequentemente corrigidos. Já os erros em que só é visível a ocorrência a partir de um resultado incorreto em geral são os mais complexos, pois é necessário identificar que conjunto específico de dados que causa o resultado indesejado e consequentemente a sua correção. Uma das possíveis origens de bugs pode estar na qualidade dos dados que estão sendo processados. Dados corrompidos ou com conjunto de valores inesperados para o processamento a ser realizado podem causar certos tipos de bugs. Por este motivo é muito importante um tratamento rigoroso dos dados que são inseridos numa base de dados. Em geral programadores mais experientes conhecem as principais possíveis origens de bugs e tendem a criar códigos menos sensíveis. A origem do problema pode estar no código ou nos dados que estão sendo processados.

• Isolar a fonte do bug: um dos passos mais árduos é isolar a fonte do bug. Em geral programadores mais experientes tem maior habilidade para supor onde a origem do problema pode estar. Isso não se refere apenas à questão de experiência em programação, mas também conhecimento do código que está sendo depurado, pois um programador por mais experiente que possa ser, se for colocado diante de um volume considerável de código que ele não conhece para detectar um bug, provavelmente levará mais tempo que um programador menos experiente, mas que conheça profundamente o código em questão.

• Identificar a causa: após ter isolado o código que contém o bug, o próximo passo é identificar a causa do problema. A causa do problema podem ser os dados corrompidos ou erros na lógica (lógica inadequada) do programa. Quando a origem da causa são os dados corrompidos pode ser necessário tratar na lógica do programa. Este tipo de situação para que novos problemas não venham a ocorrer pelo mesmo motivo e em seguida é necessário verificar a real origem destes dados resultarem corrompidos no sistema, ou seja, em que rotina estes dados foram inseridos no universo do programa e que permitiram que estes dados fossem inseridos.

• Determinar a correção: depois de identificada a causa, o passo seguinte é a correção do problema. A correção do problema não deve causar outros problemas no software, conhecidos como efeitos colaterais. A correção deve ser feita de forma que novos erros não sejam inseridos no programa.

• Codificação da correção: a correção do problema deve ser codificada conforme a estratégia de solução definida no passo anterior.

• Testar a correção: uma vez efetuada a correção do problema é necessário que se façam os testes para verificar se o problema realmente foi corrigido e principalmente se não causou novos problemas.


86

No momento de depurar um programa, uma das principais premissas que não podem ser assumidas é a de que o problema não está no programa e que a origem deve vir de outro lugar. Isto é especialmente negativo, pois causa um bloqueio nas alternativas de origem e solução do problema, fazendo com que se abstraiam determinados detalhes que poderiam ser fundamentais na solução do problema.

Programas com zero erros são realmente muito raros. Todos podem ter alguma fragilidade que permitirá que algum bug ocorra, seja pela existência de dados corrompidos, seja por uma situação especialmente particular não prevista no código.

As entradas de dados devem ser tratadas de forma muito cuidadosa, pois uma das principais fontes de problemas pode ser os dados indevidos inseridos no universo do programa. Se a entrada de dados for muito bem tratada, a quantidade de verificações internas nas rotinas de processos pode ser reduzida, o que implicará maior performance no processamento.

Haverá um custo adicional nos processos de entrada de dados e isso deve ser medido cuidadosamente, pois existem situações em que a velocidade de inserção de um dado é crítica, há outras em que a pesquisa/recuperação destes dados é crítica. Na maioria dos programas comuns o registro de tempo de resposta é mais crítico em processamentos e recuperação de dados (consultas e relatórios).

Sempre identifique o autor do código inicial e as pessoas que efetuaram manutenções significativas com as respectivas datas no cabeçalho. A melhor e mais eficiente forma de documentação ainda é aquela feita dentro do código fonte, pois não se perde do código e com o devido cuidado ou método de trabalho tende a estarem devidamente sincronizados.

É aconselhável que antes de métodos ou procedimentos que realizam processamento não trivial, o processamento realizado no mesmo deve ser devidamente explicado de forma a facilitar futuras manutenções. O tamanho máximo em colunas de uma linha de código deveria ser a que pode ser visualizada no editor ou ambiente que se esteja utilizando, sem a necessidade de rolagem do código.

Geralmente códigos que necessitam de rolagem tornam-se difíceis para serem lidos e analisados, pelo fato de poder ser necessário rolar o texto muitas vezes, por várias vezes para um lado e para outro para poder ler todo o código e entendê-lo. Utilize sempre que possível espaçamento após uma chamada de método ou um indexador. Veja os exemplos a seguir.


87

Exemplo de uso menos adequado:metodo_a();metodo_b();metodo_c();

Exemplo de uso mais adequado:metodo_a(); metodo_b(); metodo_c();

Exemplo de uso mais adequado ainda:metodo_a();

metodo_b();

metodo_c();

Sempre que possível efetue os testes de condições pelas assertivas. Isso torna o código mais legível e em alguns casos menos susceptível a erros. Veja os exemplos a seguir:

Exemplo de código mais adequado:for (i = 0; i < 7; i++) {

if (metodo(i)) {

metodo_y();

}

}

Exemplo de código menos adequado (deve ser evitado):for (i = 0; i < 7; i++) {

if (!metodo(i))

continue;

metodo_y();

}

3 NOTAÇÕES

A notação húngara é uma convenção de nomenclatura utilizada na programação na qual o nome de um identificador indica seu tipo ou objetivo. O princípio foi descrito/desenvolvido independente de linguagem de programação. Na realidade a notação foi desenvolvida para indicar o tipo da informação armazenada (tipo funcional) e esse objetivo não foi bem entendido. Então os programadores passaram a usar para indicar o tipo de dado.


88

Nesta notação, o nome de uma variável inicia com uma ou mais letras em minúsculo identificando o tipo de dados da variável ou o objetivo desta. Também se pode utilizar mais de um caracter para indicar mais de uma informação (tipo de dado + objetivo). Estes indicativos podem estar em minúsculo ou combinações de maiúsculos e minúsculos.

Esta notação foi criada por Charles Simonyi na época em que trabalhava como programador na Xerox. Esta notação passou a ser conhecida como notação húngara pelo fato de parecer com a forma de escrita de linguagens diferentes do inglês e pelo fato de Simonyi ser originário da Hungria.

Independente da forma como é utilizada a notação ela é especialmente útil e deve representar através de um conjunto reduzido de letras mnemônicas do que esteja representando, seja o tipo de dado armazenado, a categoria ou o tipo de informação que está armazenada. Características do uso:

• Facilidade de localização de um identificador, pois a equipe envolvida saberá qual é o prefixo pelo qual inicia o identificador.

• Com o uso da notação os nomes de identificadores tendem a se tornarem mais sugestivos, o que facilita o entendimento da equipe do que está escrito no código.

• A tendência dos identificadores de se tornarem mais consistentes é grande, pois o padrão de nomenclatura induzirá para isto.

• A velocidade de um programador em decidir pelo nome do identificador tende a aumentar, pois o prefixo ele já tem, basta completar com algo que signifique o que aquele identificador estará representando.

O que importa é que, uma vez adotada, seja utilizada por toda a equipe de forma a prover os resultados desejados. O objetivo é facilitar o entendimento do que está sendo representado num determinado conjunto de código de programação. Também é bastante recomendado seu uso no caso de indicação de ponteiros.

A notação pode ser utilizada para qualquer linguagem ou ambiente de programação. Existem diversas argumentações para a utilização ou não desta notação ou qualquer variação da mesma. Os principais defensores argumentam que:

• O tipo da variável pode ser obtido a partir do seu nome.• Nomes de variáveis podem ser fáceis de lembrar conhecendo-se apenas seus

tipos.• Direciona ao uso de nomes de variáveis mais consistentes.• Pode-se detectar facilmente uma atribuição ou cast inadequado entre tipos.


89

Os principais críticos argumentam que:

• Há um encorajamento de práticas pobres de uso de variáveis, principalmente quando passa a ser utilizado para representar diversas coisas diferentes ao invés de apenas tipos de dados.

• Pode induzir a problemas de portabilidade, já que o nome da variável está amarrado ao tipo de dado utilizado.

• As IDEs modernas indicam automaticamente o uso inadequado de atribuições entre tipos incompatíveis, além de mostrarem o tipo de dado da variável ao passar o mouse sobre elas, o que torna a notação obsoleta.

É muito importante observar que padrões de codificação não são definidos para uso por linguagens ou ambientes de programação e sim pelas pessoas envolvidas na equipe de desenvolvimento. Tendo isso presente, os padrões estabelecidos devem ser definidos de forma que beneficiarão o trabalho das pessoas envolvidas.

A questão do que a notação está significando é irrelevante do ponto de vista do que a notação deveria ou não indicar. A notação deve indicar aquilo que seja relevante para a equipe envolvida e para a natureza do trabalho que está sendo desenvolvida por esta equipe de desenvolvimento.

4 ESTILOS DE IndentaçãoExistem diversos tipos de estilos de indentação de código fonte, dentre

estes, os mais conhecidos e utilizados são: o estilo K&R, BSD/Allman, BSD/KNF, Whitesiths, GNU e Banner.

ESTILO K&R

Este estilo de indentação é denominado assim pelo fato de ter sido utilizado por Kernighan (Brian) e Ritchie (Denis) em seu livro "The C Programming Language". Acredita-se que por este fato o estilo seja comum entre programadores que utilizam a linguagem C.

Neste estilo de indentação o símbolo de início de bloco está localizado na mesma linha da sentença de controle, endenta as sentenças subordinadas e o símbolo de final de bloco está localizado no mesmo nível de indentação da sentença de controle, em uma linha exclusiva para o símbolo. Veja os exemplos:


90

Exemplo com if:if (a < 0) {

printf("Valor negativo");

funcao1(a);

} else {

printf("Valor positivo");

funcao2(a);

}

Exemplo com while:while (a != b) {

funcao1();

funacao2();

}

funcao3();

Este estilo de indentação também é conhecido pelas siglas 1TBS ou OTBS que é a abreviatura de "True Brace Style". Uma das vantagens deste estilo é o fato do símbolo de início de bloco não necessitar de uma linha de código para ele, estando na mesma linha da sentença de controle.

Já, o símbolo de final de bloco está localizado numa linha exclusiva e alinhado com o início da sentença de controle, o que facilita a localização do final do bloco. Uma das críticas existentes a este estilo é o fato da localização do símbolo de início de bloco nem sempre ser fácil de localizar. O código fonte do kernel do UNIX e Linux foram escritos neste estilo de indentação.

ESTILO BSD/ALLMAN

Este estilo de indentação tem o nome atribuído a Eric Paul Allman. Nele o símbolo de início de bloco está na linha seguinte à sentença de controle. As sentenças que deverão ser executadas estão um nível à direita e o símbolo de final de bloco fica em uma linha abaixo da última sentença alinhado com o símbolo de início do bloco. Veja os exemplos:


91

Exemplo com if:if (a < 0)

{

printf("Valor negativo");

funcao1(a);

}

else

{

printf("Valor positivo");

funcao2(a);

}

Exemplo com while:while (a != b)

{

funcao1();

funcao2();

}

funcao3();

A principal característica deste estilo é a clareza obtida na identificação do início e término de um bloco de instruções.

ESTILO BSD/KNF

Este estilo de indentação possui este nome pelo fato de ser o estilo comum usado no desenvolvimento de código de sistemas operacionais das distribuições Berkeley. A sigla significa "Kernel Normal Form".

Apesar do estilo se encontrar principalmente em códigos de sistemas operacionais, este pode ser encontrado em várias aplicações das mais diversas áreas. A principal característica do estilo é a utilização de 8 espaços para determinados tipos de situações e 4 espaços para outras.

Neste estilo, as endentações de fluxos de código geralmente são feitas com tamanho de 8 espaços e havendo a necessidade de quebrar a linha de uma sentença/instrução esta é feita utilizando-se uma indentação de 4 espaços. Esta quantidade de espaços da indentação é que define o tipo de subordinação dos blocos de instruções.


92

Veja o exemplo:while (a != b) {

funcao1();

funcao2();

}

funcao3();

ESTILO WHITESMITHS

Este estilo de indentação usa os símbolos de início e término de bloco em linhas exclusivas para estes. A característica mais marcante deste estilo é o fato das sentenças/instruções subordinadas iniciarem no mesmo nível de indentação dos símbolos de início e término de bloco.

Veja o exemplo:while (a != b)

{

funcao1();

funcao2();

}

funcao3();

Este estilo é interessante do ponto de vista da clareza na identificação da subordinação dos blocos de código. Uma desvantagem pode ser o fato dos símbolos de início e final de bloco estar na mesma direção das instruções subordinadas, mas isso realmente volta àquela questão de que não seria interessante discutir preferências, pois um desempate geralmente é difícil de ser obtido.

ESTILO GNU

Neste estilo, os símbolos de início e final de bloco são colocados em linhas exclusivas. Os símbolos de início e término de bloco são endentados em 2 espaços e o bloco de instruções subordinadas são igualmente endentados em 2 espaços. Este estilo utiliza ainda um espaço entre o nome da função/procedimento e os parênteses dos parâmetros/argumentos.


93

Veja o exemplo:if (a < funcao1 (x, y))

arg1 = vetor1[2] + 3;

else

{

while (b)

{

arg1 += funcao2 (l, k);

j++;

}

return ++a + funcao3 ();

}

funcao4 ();

while (a != b)

{

funcao1 ();

funcao2 ();

}

funcao3 ();

Os símbolos de início e término de blocos ficam alinhados com o início da declaração da função.

void concat (char arg1, int arg2)

{

/* instruções */

}

Quando a declaração de uma função se torna muito longa, a quebra de linha deve se dar entre dois argumentos, sendo que os demais argumentos devem iniciar alinhados com o primeiro argumento definido.

int funcao1 (char arg1, int arg2, long arg3,

float arg4, double arg5)

{

/* instruções */

}


94

Outra característica é o uso de um espaço entre o identificador de uma função e os parênteses e também após as vírgulas na separação de argumentos/parâmetros. O uso de um espaço após as vírgulas é bastante recomendado. Veja o exemplo:

if (funcao1 (a, b, c)) {

/* instruções */

}

No caso de uma expressão ficar muito longa e houver a necessidade de uma quebra de linha, esta quebra deve ser feita sempre antes de um operador. Veja o exemplo:

if (funcao1 !! funcao2 < funcao3 (a, b, c) && funcao4 (k) > quantidade);

Deve-se procurar evitar a existência de dois operadores de diferentes precedências no mesmo nível de indentação. Veja o exemplo:

tipo = (vetor[j] == NULL || funcao1 (vet[j]) > funcao2 (vetor[j])

? vet[j] : vetor[j]);

Neste caso é aconselhável o uso de parênteses para isolar as precedências. Veja o exemplo:

tipo = ((vetor[j] == NULL || (funcao1 (vet[j]) > funcao2

(vetor[j])))

? vet[j] : vetor[j]);

Quando houver um cálculo cujo tamanho da linha for muito grande e necessitar ser quebrado, adicionar um parênteses extra mantém a mesma execução, mas melhora em muito a legibilidade. Veja o exemplo:

a = b*10 + c/100 + b*10 + c/100;

ou da seguinte forma: a = (b*10 + c/100 + b*10 + c/100);


95

Este estilo reúne as vantagens de BSD/Allman e Whitesmiths com o grande diferencial dos símbolos delimitadores de bloco estarem melhor destacados, tornando o estilo mais legível. Uma das desvantagens apontadas para este estilo é o fato de necessitar mais esforço em digitação pelo fato dos delimitadores de bloco e o bloco de instruções em si estarem endentados, mas em níveis diferentes.

Existe quem argumente que o estilo torna o trabalho de identificação

da subordinação de blocos de código um pouco mais trabalhosa. Este estilo de indentação é largamente utilizado na comunidade GNU.

Quando houver a inserção de parênteses para tornar mais clara a ordem de precedência das operações é necessário fazer a indentação das demais linhas de código. Esta indentação deve ser feita de forma adequada ao convencionado, neste caso iniciando na mesma coluna dos operandos e não dos parênteses. Veja os exemplos:

x = s*50 + m/50 + y*50 + c/50;Veja a forma adequada: x = (s*50 + m/50 + y*50 + c/50);

As sentenças do – while devem ser endentadas da seguinte maneira: do {

x = funcao1 (x);

}

while (x < 10);

ESTILO BANNER

Este estilo de indentação, de alguma forma torna a visualização mais fácil pelo fato do início da sentença ser o único conteúdo existente naquele nível de indentação. A principal argumentação é a de que o símbolo de finalização do bloco anterior interfere no início do bloco seguinte, conforme utilizado nos estilos K&R e BSD/Allman.

Neste estilo, o qual está para Whitesmiths assim como K&R está para BSD/Allman, o símbolo de final de bloco é endentado no mesmo nível da última sentença do bloco de instruções. Veja o exemplo:

funcao1 () {

funcao2 ();

funcao3 ();

}


96

Uma pequena variação deste estilo é a utilização do símbolo de finalização de bloco juntamente com a última instrução do bloco. Este estilo tem a vantagem de não possuir linhas de código contendo apenas símbolos de início ou término de bloco. Veja o exemplo:

for(a = 0; a < 5; a++) {

if(a % 2 == 0) {

funcao1(a); }

else {

funcao2(a); } }

A questão dos estilos de indentação não deve ser entendida como requisito, mas sim como uma forma de facilitar a comunicação entre as diversas pessoas que podem participar do processo de desenvolvimento de um software. Neste sentido, o ponto mais importante reside no fato de que, uma vez adotado um estilo, deve-se segui-lo para que não haja confusão ou perda da clareza do código em função do não seguimento de um padrão.

Se por um acaso, numa equipe de desenvolvimento com códigos legados antigos houver diferentes estilos utilizados, ao efetuar manutenção em um destes códigos, deve-se manter o estilo utilizado naquela fonte. Em grandes códigos fonte com grande quantidade de subordinação de blocos é comum perder de vista quem é subordinado a quem e principalmente onde um determinado bloco inicia ou termina.

Muitas vezes é necessário rolar o texto do código fonte para cima e para baixo várias vezes até que o início e o término de um determinado bloco de comandos sejam encontrados. Uma das técnicas utilizadas para encontrar o início e término do bloco é contar os símbolos de início e término, o que é prejudicado quando o estilo de indentação utilizado é o K&R, pois o símbolo de início de bloco não está necessariamente visível, pois se encontra no final da sentença que inicia o bloco.

Deve-se, portanto, ter clareza da importância de padrões de codificação e estilos de indentação na facilidade de leitura do código fonte de um programa.

97

RESUMO DO TÓPICO 2Caro(a) acadêmico(a)! Nesse tópico, você estudou que:

• Os padrões de codificação são convenções utilizadas para a escrita de software. Estes padrões de codificação poderão variar conforme a equipe ou linguagem de programação utilizada.

• Os padrões de codificação podem englobar nomenclatura de identificadores, tipos de retorno de funções ou métodos, indentação do código, espaçamento entre operandos e operadores, formas para testar laços de repetição, formas de depuração de código, entre outras.

• Os passos para depuração de códigos de programação são: • Reconhecer a existência da falha. • Isolar a fonte de falha. • Identificar a causa. • Determinar a correção. • Codificar a correção. • Testar a correção.

• A utilização de convenções de codificação como a notação húngara possuem as seguintes características:• Facilidade de localização de um identificador, pois a equipe envolvida saberá

qual é o prefixo pelo qual inicia o identificador.• Com o uso da notação, os nomes de identificadores tendem a se tornarem

mais sugestivos, o que facilita o entendimento da equipe do que está escrito no código.

• A tendência dos identificadores se tornarem mais consistentes é grande, pois o padrão de nomenclatura induzirá para isto.

• A velocidade de um programador em decidir pelo nome do identificador tende a aumentar, pois o prefixo ele já tem, basta completar com algo que signifique o que aquele identificador estará representando.

98

AUTOATIVIDADE


1 Por que a padronização de codificação é importante?

2 Onde devem ser feitas as declarações de variáveis?

3 Os padrões de codificação são úteis para facilitar o entendimento dos desenvolvedores ou para uso das linguagens de programação?

4 Qual é o principal valor dos estilos de indentação?

99

TÓPICO 3

GERENCIAMENTO DE PROJETOS DE SOFTWARE

UNIDADE 2

1 INTRODUÇÃO

Para o adequado gerenciamento de projetos de software os principais modelos utilizados atualmente são o PMBoK e o SCRUM. O PMBoK é um guia de melhores práticas em gerenciamento de projetos que pode ser utilizado para gestão de projetos de quaisquer áreas. Ele descreve um modelo mais formal de gestão de projetos.

Já o SCRUM é um modelo para a gestão de projetos de software ágil. Ambos os modelos têm foco em planejamento, execução, controle e encerramento. Como o processo de software é altamente dependente de recursos humanos, neste tópico será dada ênfase na questão deste elemento fundamental para o processo de software.

Os esforços em desenvolvimento de software empreendidos nos negócios e nas organizações, provavelmente estão relacionados a alguma frente de projeto. Tais atividades, porém, não se referem a procedimentos contínuos como suporte ou outras atividades do dia a dia. Tais atividades relacionam-se ao desenvolvimento de novos produtos ou funcionalidades.

Na carreira de um profissional de software, certamente ele estará envolvido em projetos de diversas naturezas e estarão lidando com as questões de recursos humanos nestes. Isso significa que profissionais de software devem adquirir e desenvolver um conjunto de habilidades em gerenciamento de projetos.

O desenvolvimento de habilidades interpessoais é necessário para quem irá gerenciar um ou mais projetos e para quem estiver envolvido em algum projeto. O objetivo é melhorar o entendimento e compreensão das atividades de planejamento, orçamento, cronograma, apresentação de resultados de projeto e também trabalhando ou contribuindo para as atividades e conclusão de projetos (TITTEL, 2008).

É relativamente comum encontrar profissionais de software que executem apenas uma parte das atividades necessárias para o gerenciamento adequado de projetos de software. Pois a maioria, tipicamente foi promovida para posições gerenciais como recompensa pelas excelentes habilidades técnicas no desenvolvimento de software.

100


Em geral, isso implica uma lacuna de habilidades e competências necessárias à adequada gestão de projetos como gestão de pessoas, contratos, comunicação etc. (MANDL-STRIEGNITZ, 2001). Para a gestão de projetos pode-se aprender uma séria de ferramentas e técnicas, porém nem sempre é suficiente utilizar apenas ferramentas e técnicas quando se está lidando com projetos com alto grau de dependência de pessoas.

A gestão de pessoas é uma atividade muito importante no gerenciamento de projetos. Em função disso, o relacionamento interpessoal é fundamental para obtenção de melhores resultados. Para a gestão de projetos é necessário habilidade para realizar explanações, fazer perguntas, trabalhar com pessoas para resolver problemas e apresentar novas ideias e soluções, capacitar a equipe (coach), fornecer feedback de desempenho, definir metas para a equipe, entre muitas outras atividades (CHAN, 2002).

Portanto, a atividade de gerenciamento de projetos não pode ser vista como uma atividade simples. Muito pelo contrário. O gerenciamento de projetos é uma das atividades mais árduas desempenhada pelo profissional de software, pois o grau de contribuição das pessoas no resultado do projeto é muito significativo em desenvolvimento de software.

A indústria de software está constantemente enfrentando desafios em relação à qualidade, produtividade e prazo de liberação para o mercado, o que torna o gerenciamento de projetos uma das mais difíceis e desafiadoras atividades em qualquer organização de software (PFAHL et al. 2000).

2 ABRANGÊNCIA DO GERENCIAMENTO DE PROJETOS

Softwares são muito utilizados como suporte aos negócios há poucas décadas. Neste período houve diversos ciclos, tanto em termos tecnológicos quanto em termos de recursos disponibilizados aos usuários. Uma questão importante que deve ser levada em consideração é o fato de que o software deixou de ser diferencial para as organizações, pois praticamente todas fazem uso dele.

O uso de recursos de softwares é uma necessidade do dia a dia das organizações. Cada organização tem um grau de dependência de softwares para execução de suas atividades e a margem de oportunidades para utilização como diferencial estratégico tem diminuído.

Na mesma proporção que o software deixa de ter participação como diferencial estratégico para as organizações ele passa a se tornar crítico em termos de dependência. Uma organização não pode deixar de faturar porque o software de faturamento não está disponível por problemas de software.

Os softwares precisam estar disponíveis 24 horas por dia, 7 dias por semana, caso contrário poderá representar um gargalo para o crescimento dos negócios.

TÓPICO 3 | GERENCIAMENTO DE PROJETOS DE SOFTWARE

101

2 ABRANGÊNCIA DO GERENCIAMENTO DE PROJETOS

Esta questão requer não apenas disponibilidade, mas um corpo de recursos humanos providos de qualificação e motivação para atender às demandas existentes.

À medida que avaliamos a participação do software na organização podemos caracterizá-la de diferentes formas. Obviamente que ainda há uma grande gama de possibilidades de utilização de software como diferencial estratégico em uma parcela significativa de organizações de diversas áreas. Diante deste quadro há uma forte tendência de gestão de projetos com base nas seguintes diretrizes (SAAD, 2006):

• Redução de custos: com a comoditização dos serviços é possível otimizar os custos, porém é recomendável realizar uma análise de retorno sobre os investimentos e optar pela simplificação e considerar possibilidades de parcerias.

• Investimento em tecnologias com aplicabilidade comprovada: utilizar soluções e tecnologias inovadoras pode oportunizar diferencial estratégico, porém o risco de fracasso também é alto.

• Investimento na redução de vulnerabilidades: com o aumento da dependência dos recursos de software, o impacto da indisponibilidade aumenta, logo, é necessário investimentos em prevenção.

Um fator que tem preocupado as organizações em relação às atividades de desenvolvimento de software é a falta de gente para atender às demandas existentes nas organizações. Mas afinal o problema está na falta de gente ou no excesso de demanda? O que ocorre provavelmente é o reflexo do produto de ambos, pois as organizações têm demandas cada vez maiores por recursos de software e por outro lado a carência de pessoal é crescente.

Acredita-se que atualmente o software tem papel importante nas atividades das organizações. O software tornou-se um requisito básico para a sobrevivência e crescimento das organizações. Como o crescimento das organizações se dá tipicamente através de projetos, é fundamental que estes sejam geridos com sucesso. Porém, o que é um projeto de sucesso?

A pergunta não é simples de responder, pois dependerá do ponto de vista da avaliação. Se avaliarmos do ponto de vista da tríplice restrição de escopo, tempo e custo, podemos ter resultados que apontam o sucesso de projetos como sendo algo raro. Essa abordagem de medição do sucesso de projetos pode ser considerada frágil se considerarmos que sucesso de um projeto poderia ser medido através de outros indicadores como, por exemplo, os benefícios obtidos com o mesmo.

102


O julgamento do que é um projeto de sucesso pode gerar discordâncias de opiniões. Um projeto pode ter custado mais do que o previsto e ter demorado mais tempo para ser entregue e mesmo assim ser considerado um projeto de sucesso. Newton (2011) indica três categorias de critérios que podem ser consideradas para qualificar um projeto de sucesso ou não:

• Fornecer as entregas/resultados: as entregas de um projeto não se limitam àquelas definidas no escopo do projeto, mas podem conter uma grande quantidade de outros itens implícitos e que fazem parte do processo de construção do projeto que poderão ter grande importância após a conclusão deste.

• Realizar os benefícios associados: realizar as entregas do projeto pura e simplesmente também não é garantida de sucesso, é necessário que estas entregas levem à obtenção dos benefícios esperados com o projeto.

• Satisfazer o cliente: os resultados e benefícios obtidos com o projeto devem ser percebidos e entendidos pelos clientes e estes devem estar satisfeitos com os resultados, caso contrário de nada adiantou fornecer entregas e realizar os benefícios associados se o cliente não ficou satisfeito com estas entregas.

No final da década de 1980, Pinto e Slevin (1987) utilizaram o pressuposto de que a implementação de um projeto é considerada de sucesso caso atenda a quatro critérios: tempo, custo, eficácia e satisfação do cliente. A partir desse pressuposto estabeleceram um modelo que relaciona dez fatores críticos de sucesso para um projeto:

1. Missão do projeto.2. Suporte gerencial.3. Plano.4. Cliente consultor.5. Pessoal.6. Tarefas técnicas.7. Aceite do cliente.8. Monitoramento.9. Comunicação.10. Conciliação.

Um projeto considerado bem estruturado deve levar em conta estes fatores. As perguntas podem ser avaliadas e um grau de atendimento pode ser associado. Este grau de atendimento pode ter uma escala simples, indicando se o fator é atendido em grau baixo, médio ou alto.

Destes fatores críticos de sucesso será dado destaque à questão de pessoal que se refere ao recrutamento, seleção e treinamento de pessoal para atuação em projetos de software. No fator crítico que se refere à pessoal há cinco perguntas que podem ser feitas para medir o grau de participação deste fator:


103

• Os membros da equipe compreendem seus papéis na equipe?• Existe potencial humano suficiente para terminar o projeto?• Os membros da equipe compreendem como serão avaliados?• A descrição do trabalho tem sido feita, distribuída e compreendida pelos

membros da equipe?• O treinamento técnico/gerencial tem sido disponibilizado para os membros da

equipe?

Estas perguntas podem ser realizadas em qualquer projeto e atenção deve ser dada aos aspectos cujo grau de atendimento da resposta for pontuado como baixo. As perguntas pontuadas com grau de atendimento baixo deveriam ter ações planejadas para serem enquadradas na devida importância.

3 DEFINIÇÃO DE PAPÉIS E RESPONSABILIDADES

A definição clara de papéis e responsabilidades dentro de um projeto de software é um elemento importante para que os componentes da equipe do projeto canalizem suas energias em realizar o escopo do projeto e não percam tempo com outras preocupações.

No organograma deverão constar todos os níveis da estrutura hierárquica relevante do projeto. O registro dos papéis e responsabilidades pode ser feito, por exemplo, em uma ata de reunião. É importante que esteja destacado na relação de papéis e responsabilidades quem será a pessoa da equipe do projeto responsável pelas atividades.

Em projetos maiores é aconselhável que as preocupações de realizar o trabalho operacional sejam delegadas para um membro da equipe e que o responsável pelo projeto possa realizar o acompanhamento efetivo do progresso do projeto tomando decisões de forma ágil e imediata à necessidade.

Uma ferramenta muito importante no gerenciamento de projetos maiores é a matriz RACI (Responsible, Accountable, Consult and Inform), pois possibilita uma visão clara das responsabilidades de cada envolvido no projeto. Essa visão, por ser uma visão gráfica, pode ser rapidamente consultada em caso de dúvidas. A matriz RACI de determinadas atividades que sejam consideradas críticas ou fundamentais no projeto, poderá ser impressa e afixada em locais úteis ao projeto.

4 FUNÇÕES E RESPONSABILIDADES

O processo de desenvolvimento do projeto é planejado em torno da exigência de que todo projeto seja administrado com uso de uma equipe integrada, que inclua a representação adequada das áreas funcionais e de negócios envolvidas. Os membros da equipe devem ter o poder de tomar decisões em nome da função ou área que representam.

104


Tipicamente o ciclo de vida de um projeto começa no momento da decisão de realização dele e converge no encerramento do projeto. Para garantir que os requisitos dos grupos de pessoas envolvidos no projeto estejam refletidos no planejamento, execução e operação de um projeto, a equipe do projeto deve ser multidisciplinar e representar todas as áreas de conhecimento necessárias.

Esta representação pode variar de acordo com o tamanho do projeto e quantidade de pessoas envolvidas na construção dele. O “projeto perfeito” (isto é, seguindo o custo, prazo, qualidade e escopo pré-estabelecidos) não pode ser garantido a menos que sejam incorporadas informações procedentes de todos os grupos envolvidos que devem, planejar, executar e operar o projeto de maneira lucrativa.

A equipe do projeto é identificada pelo responsável pelo projeto no início da fase de definição do escopo. Todos os representantes são formalmente designados para a equipe, e a participação é considerada uma parte essencial do trabalho. Os principais membros da equipe de projetos devem ser designados para essa finalidade em tempo integral.

É recomendável que a equipe do projeto tenha uma estrutura vertical ou

uma estrutura mista vertical e matricial. Seja qual for a estrutura empregada, todos os membros da equipe se reportam diretamente ao responsável pelo projeto. Se a equipe for estruturada verticalmente, os membros da equipe se reportam diretamente ao responsável pelo projeto, sem relação com qualquer outra função.

Se for usada uma estrutura mista, o responsável pelo projeto e os membros

da equipe que representam competências principais devem estar alocados com exclusividade ao projeto. Outros membros da equipe são designados para projetos quando necessário e se reportam diretamente ao responsável pelo projeto, embora mantendo uma relação com seus gerentes funcionais.

As funções e responsabilidades de cada membro da equipe devem ser definidas e claramente comunicadas a todos na equipe. Os objetivos da organização e do projeto devem ser definidos e compreendidos por todos os membros da equipe, que aceitaram participar do projeto. Uma equipe integrada de projeto exibe também características de trabalho em equipe, inclusive cooperação, comunicação aberta e alto nível de confiança entre os vários representantes que participam da equipe.

A rotatividade de membros-chave da equipe do projeto pode ter um efeito significativo sobre os resultados do projeto. Para evitar a rotatividade de pessoal, o processo de desenvolvimento do projeto deve incluir dispositivos para manutenção da continuidade da equipe. Para manter a continuidade de conceitos, filosofias e decisões, os membros da equipe não devem ser substituídos por pessoas diferentes.


105

A substituição de membros da equipe pode ser perturbadora e dispendiosa. Se for necessária a substituição, deve ser planejado um período de transição a fim de manter a eficiência e evitar perturbação no fluxo de trabalho. A mudança deve ocorrer com tranquilidade para a equipe e para os demais participantes do projeto.

Observar atentamente a agenda de disponibilidade de recurso pode ser vital no momento do planejamento de recursos humanos para o projeto, pois pode coincidir de um profissional importante ao projeto não estar disponível para atuar nele. Dessa forma, evita-se a necessidade de contratação de outro profissional cuja capacidade, histórico e perfil sejam desconhecidos.

5 GESTÃO DE PESSOAS

No mundo do trabalho, as habilidades das pessoas podem ser divididas em habilidades técnicas também conhecidas por "hard skills" e habilidades pessoais, também conhecidas como "soft skills" (COATES, 2006). Cada vez mais se pode perceber que as habilidades pessoais têm influência no sucesso profissional.

Uma pessoa que cultive apenas as habilidades técnicas poderá tornar-se muito boa naquele assunto. O limite do crescimento profissional dela tipicamente está relacionado ao somatório das habilidades técnicas com as habilidades pessoais.

Isto é realmente polêmico, mas o que normalmente se percebe na área de software é esta relação, pois mesmo que o profissional seja muito bom tecnicamente haverá momentos em que ele precisará interagir com pessoas. Se as habilidades pessoais forem muito limitadas, isso poderá influenciar negativamente no crescimento profissional dela.

As habilidades técnicas se referem à capacidade de desempenhar determinada atividade que exija que sejam seguidos métodos ou procedimentos. Exemplos incluem a operação de máquinas, utilização de padrões de segurança, a realização de procedimentos financeiros, a administração de vendas, entre outras.

Tais habilidades geralmente são fáceis para observar, quantificar e medir. Além disso, são habilidades consideradas fáceis de treinar, pois a maioria das vezes o conjunto de habilidades são aprendidos e dificilmente esquecidos (COATES, 2006).

Já, as habilidades pessoais são tipicamente difíceis de serem observadas, quantificadas e medidas. Tais habilidades são necessárias no cotidiano pessoal, assim como no cotidiano profissional. Elas se referem a como as pessoas se relacionam com as outras se comunicando, ouvindo, estabelecendo diálogos,

106


fornecendo feedback, cooperando como membro de uma equipe, resolvendo problemas, contribuindo em reuniões, resolvendo conflitos, entre outras (COATES, 2006).

No início de carreira, as habilidades técnicas são importantes para obtenção de oportunidades de crescimento. Por outro lado, à medida que se cresce na profissão são as habilidades pessoais que passam a se tornar mais importantes. Esta questão é ainda mais importante em organizações maiores, onde há mais pessoas com habilidades técnicas similares competindo por uma promoção (IYER, 2009).

Habilidades pessoais têm grande importância para as oportunidades e desenvolvimento da carreira, bem como conhecimentos técnicos aprofundados. Habilidades pessoais se referem às características que melhoram a empregabilidade, abre portas para oportunidades que muitas vezes não estão diretamente relacionadas ao seu trabalho. Habilidades pessoais se referem às habilidades de se relacionar com outras pessoas, seja através da organização de atividades, comunicação, obtenção de informações, entre outros (TITTEL, 2008).

Habilidades pessoais podem ser consideradas as coisas que você precisa saber como fazer, para fazer o melhor em seu trabalho, não importando o quão específico o trabalho seja (TITTEL, 2008). Líderes de todos os níveis precisam ter habilidades pessoais, por exemplo, para construção de equipes, facilitar reuniões, encorajar inovações, resolver problemas, tomar decisões, planejar, delegar, observar, instruir, encorajar, motivar, entre outras (COATES, 2006).

Profissionais com formação na área de computação e informática possuem grande enfoque no desenvolvimento de habilidades técnicas, fundamentos científicos e raciocínio analítico. Em consequência de tal formação, boa parte dos profissionais possui:

• Falta de ênfase em pessoas e processos.• Falta de cobertura de aspectos relacionados a negócios e gerenciamento.• Falta de foco em soft skills, ou seja, trabalho em equipe, gerenciamento,

comunicação, entre outros.

É frequente encontrar líderes de projetos de software provenientes de formação técnica. Alguns destes profissionais possuem um perfil mais reservado, não tendo habilidades naturais para estabelecimento de relações interpessoais. Nestes casos, há necessidade de maior esforço por parte do profissional para aquisição das habilidades e competências requeridas.

Além disso, consideram que escrever de forma clara e correta, não é importante ou relevante e de que, quem vai ler tem que ter capacidade para entender o que foi escrito. Ortografia e concordância, também são relegadas,


107

pois se um computador tem capacidade de entender uma série de instruções de programação, como uma pessoa não terá a capacidade para entender o que foi escrito de uma maneira muito mais amigável.

Uma das consequências é que, ao se depararem com questões complexas relacionadas ao gerenciamento de projetos, tais profissionais preferem tratar de questões técnicas a tentar resolver os problemas. Muitos dedicam no máximo 35% do seu tempo de trabalho em atividades gerenciais (MANDL-STRIEGNITZ, 2001). Este quadro demonstra a importância de entender o perfil do profissional com o qual se está lidando para que os resultados sejam os mais efetivos possíveis.

Entender o perfil do profissional que atuará em seu projeto é fundamental para que as tratativas sejam efetivas. O trabalho em equipe é entendido como uma ação conjunta de pessoas que agem com espírito de cooperação, atuando com base em limites de coordenação. Ameaças ao trabalho em equipe incluem (KERZNER, 2002):

• Excesso de mudanças no escopo do trabalho.• Falta de comunicação por parte do Gerente de Projetos sobre o progresso do

projeto para que os indivíduos se sintam parte da equipe.

O trabalho em equipe nas empresas de excelência em gestão de projetos apresenta as seguintes características (KERZNER, 2002):

• Gerentes e membros da equipe do projeto trocam ideias e estabelecem altos índices de inovação e criatividade nos grupos de trabalho.

• Gerentes e membros da equipe do projeto possuem lealdade e confiança mútuas e também em relação à empresa.

• Gerentes e membros da equipe do projeto são dedicados ao trabalho e aos compromissos assumidos.

• Gerentes e membros da equipe do projeto têm por hábito trocar informações por iniciativa própria.

• Gerentes e membros da equipe do projeto possuem alto grau de franquesa em suas relações.

“Muitas empresas acreditam que uma boa metodologia de gestão de projetos é garantia antecipada de comunicações eficientes, o que permitirá uma gestão mais informal do que formal”. (KERZNER, 2002, p. 301).

“Quanto maior a empresa, maior a tendência à utilização da gestão formal de projetos”. (KERZNER, 2002, p. 298). Numa filosofia de trabalho menos formal, os elementos básicos são (KERZNER, 2002):

• Confiança: É fundamental que se tenha confiança em todos os participantes do projeto. Em diversas situações em nossas vidas, confiamos no trabalho de pessoas que jamais conhecemos, através dos produtos que utilizamos em nosso dia a dia. Da mesma forma, temos que poder confiar nas pessoas que

108


fazem parte do projeto em que estamos trabalhando, pois a confiança é a chave para o sucesso na gestão informal de projetos. Caso isso não seja possível, será necessário documentar tudo que ocorre para que se tenha certeza de que cada um está fazendo o trabalho que lhe foi atribuído.

• Comunicação: É de suma importância que a comunicação que circula pela empresa seja apenas a necessária para a gestão e tomada de decisão. Os extremos são igualmente prejudiciais, ou seja, falta ou excesso de informação. A falta de comunicação impede que a gestão ocorra ou que decisões possam ser tomadas. Já o excesso de informações tende a reduzir a qualidade e consistência, em função das diversas procedências e do volume excessivo para a gestão e tomada de decisão.

• Cooperação: A cooperação é algo que depende exclusivamente do indivíduo, não tendo qualquer relação com uma eventual intervenção de um sujeito com autoridade. Ela depende da disposição das pessoas em trabalharem em conjunto em função do sucesso do projeto. Numa equipe de projeto em que há cooperação, cada indivíduo sabe exatamente o que deve ser feito e o faz.

• Trabalho em equipe: O trabalho em equipe se dá através da coordenação da cooperação entre os indivíduos. O trabalho em equipe está muito relacionado à atitude dos indivíduos em relação ao trabalho. Isso significa que tão importante quando cada indivíduo realizar um bom trabalho é a atitude dos indivíduos em relação ao trabalho.

De acordo com o PMBoK (2008), o gerenciamento da equipe do projeto é o processo de acompanhamento do desempenho dos membros da equipe, resolução de problemas, fornecimento de feedback e realização de mudanças de forma a melhorar o desempenho do projeto.

Os membros da equipe do projeto se reportam ao gerente do projeto e têm, assim, interfaces contínuas com o mesmo. Dependendo da estrutura da equipe ser vertical ou mista, os membros da equipe podem ter uma relação com as funções que representam. Além disso, os membros da equipe precisam fazer interface frequente uns com os outros para manter um fluxo constante de informações necessárias.

Como em quaisquer relações onde há a colaboração de duas ou mais entidades esta é uma meta difícil de ser obtida, porém não impossível. As relações tipicamente se deterioram quando o egoismo passa a falar mais alto. Manter um espírito de equipe em uma equipe de projeto é um grande desafio para a gestão de pessoas.

Organizar uma equipe de projetos pode ser uma tarefa bastante árdua, dependendo da quantidade de recursos disponíveis para atuação no projeto. Quanto maior a equipe maior a probabilidade de ocorrência de problemas na gestão desta, em função de uma série de fatores, principalmente das falhas relacionadas à comunicação.


109

As falhas em relação à comunicação da equipe se dão em virtude da quantidade de canais de comunicação existentes e a probabilidade de ruídos nestes canais. Com o aumento dos canais de comunicação a tendência é a de que se tenham mais problemas a serem gerenciados.

A comunicação é um dos aspectos bastante relevante e que deve ser seriamente considerado em todo e qualquer projeto. Alguns obstáculos para uma comunicação eficiente pode incluir (CHAN, 2002):

• Falta de tempo e planejamento: a sobrecarga de atividades faz com que, uma pessoa ao receber um e-mail, leia-o no menor tempo possível para não atrasar ainda mais a entrega das suas atividades. A leitura excessivamente rápida de um e-mail pode ocasionar uma interpretação equivocada da mensagem, fazendo com que não se dê a devida importância a determinados assuntos. No dia a dia é frequente as pessoas enviarem e-mails sem pensar adequadamente sobre o que estão escrevendo, especialmente quando estão sobrecarregadas de atividades. Eventualmente as mensagens de tais e-mails podem ser claras, mas frequentemente elas não são. Se uma pessoa espera que o destinatário de um e-mail entenda a mensagem enviada, então primeiro é necessário estar certo que se sabe exatamente o que se pretende dizer.

• Competição de mensagens: a maioria dos profissionais recebe um grande número de mensagens diariamente. As mensagens chegam de todas as direções, competindo por sua atenção. O telefone toca e um e-mail chega à caixa de mensagens, enquanto o profissional está tentando realizar uma explanação para um membro da equipe de trabalho. Manchetes dos jornais chamam a atenção, o rádio distrai a atenção enquanto se está tentando ajudar um colega a resolver um problema. Eliminar as mensagens desnecessárias é bastante difícil, mas é necessário colocá-las em segundo plano, caso contrário será difícil prestar atenção às mensagens importantes e relevantes.

• Diferenças de conhecimento, perspectivas, necessidades, expectativas, prioridades, posição social ou profissional, cultura e gênero: da mesma forma, pode ser difícil estabelecer uma comunicação clara com alguém cujo nível de conhecimento seja muito diferente ou com pontos de vista muito diferentes sobre determinado assunto. A comunicação seria bem mais fácil se os envolvidos possuíssem o mesmo nível de conhecimento, experiência, senso do que é importante e perspectiva de mundo. A realidade é que as pessoas possuem muitas diferenças. Tais diferenças representam grandes vantagens, mas também significam que é necessário muito esforço para sermos entendidos e para entendermos os outros.

• Pressupostos: partir do princípio de que o receptor de uma mensagem entendeu o que realmente se desejava comunicar pode resultar em falhas na comunicação (CHAN, 2002). É importante certificar-se de que o receptor entendeu exatamente o que se pretendia comunicar. Uma forma simples de reduzir o risco da existência de diferentes entendimentos é solicitar ao receptor que resuma a informação recebida como forma de sincronizar os entendimentos.

110


• Medos: em muitos momentos, ao invés de dizer o que realmente se pretende, utiliza-se de meias palavras como forma de comunicar indiretamente, ou pretender que o receptor entenda a mensagem dentro da mensagem. Com isso pode-se omitir elementos chave da informação, dizendo sim quando se pretendia dizer não. O medo também leva as pessoas a não fazer perguntas quando não estão entendendo o que outra pessoa está dizendo. Este é um comportamento a que invariavelmente se está sujeito. Nem sempre as pessoas dizem o que pretendem em função do medo das consequências em fazê-lo. Obviamente que não se deve ser excessivamente direto a ponto de ferir sentimentos, desapontando as pessoas ou deixando-as ofendidas. A ideia não é tornar a comunicação indelicada, mas, sim, mais clara. A comunicação indireta, incompleta ou vaga pode dificultar ou tornar impossível a obtenção de uma boa comunicação.

Quando se fala em comunicação, a primeira palavra que vem a mente é falar. Na realidade, a fala é apenas parte do processo de comunicação, mesmo assim há uma parte ainda mais importante no processo de comunicação: ouvir.

Se ninguém estiver ouvindo, não importa quantas palavras são faladas ou o quão claro as palavras são ditas. Quando ninguém está ouvindo, é impossível haver comunicação. Ouvir de verdade, não é fácil, requer esforço e atenção. Para que sua mensagem possa ser bem ouvida, deve-se (CHAN, 2002):

• Conhecer a audiência: pessoas diferentes podem ouvir e reagir de formas diferentes em relação à mesma mensagem. Isto ocorre em função do fato das pessoas terem diferentes personalidades, preocupações, interesses, históricos, pontos de vista e diferentes níveis de conhecimento sobre o assunto abordado. Para que a mensagem seja recebida de forma clara, pense sobre sua audiência antes de falar. Quantas pessoas já sabem algo sobre a situação ou assunto? O que é provável que eles respondam sobre a mensagem? Quais são as preocupações e interesses na situação? Se o assunto é técnico, qual é o nível de entendimento técnico? Quanto mais se souber sobre a audiência, mais efetivamente será possível transmitir a mensagem.

• Saber o que se pretende dizer e porque quer dizer: fazendo o papel de ouvinte, você pode fazer perguntas esclarecedoras de modo a garantir que você entendeu a mensagem transmitida por alguém. Mas as pessoas nem sempre fazem perguntas quando uma mensagem não está clara. Às vezes, as pessoas assumem que entenderam a mensagem, quando na verdade não a entenderam e, às vezes, não se sentem confortáveis fazendo perguntas para esclarecer dúvidas ou obter informações adicionais. Como emissor de uma mensagem é sua responsabilidade ajudar a audiência entender a mensagem. Mas primeiro é necessário saber o que se pretende dizer e as razões para dizê-lo.

• Manter a mensagem simples e específica: utilize a linguagem adequada para o tipo de público para o qual está falando. Evite utilizar termos desconhecidos para o público, isto é um risco para que ocorra um bloqueio na comunicação.


111

• Fazer contato visual com os ouvintes, falar devagar e claro o suficiente para ser entendido: estabeleça contato visual com os ouvintes, fale pausadamente e claro o suficiente para ser entendido.

• Procurar escolher o momento e local apropriados: a dificuldade em ouvir quando se está distraído é bem maior. Uma das melhores formas de garantir que a pessoa poderá lhe ouvir com a atenção que o assunto requer é perguntá-la se é uma boa hora para conversar ou se ela pode conversar naquele momento.

Ouvir é fundamental para uma boa comunicação. Ouvir atentamente, tanto mensagens verbais quanto não verbais é fundamental para garantir que alguém receba e entenda sua mensagem. Para garantir que sua mensagem foi recebida e entendida (CHAN, 2002):

• Preste atenção para respostas verbais e não verbais.• Faça perguntas conforme necessário para verificar sua percepção em relação ao

entendimento dos ouvintes.• Solicite ao ouvinte que resuma o que você falou e resgate a mensagem se

necessário.

Um dos pontos de atenção que se deve ter no processo de gerenciamento da equipe do projeto é o retrabalho. O retrabalho é indesejado em qualquer atividade, pois significa diretamente aumento de custos e tempo, pois algo que já havia sido feito está sendo feito novamente e está consumindo novos recursos.

Em certos aspectos, o retrabalho pode ser considerado como um fator resultante do baixo grau de gerenciamento da equipe do projeto, pois permitiu que falhas fossem cometidas ou que ações que levassem à redução dessas falhas não tivessem sido realizadas. Estas ações podem caracterizar a falta de acompanhamento da equipe durante a execução da atividade ou a falta de capacitação.

“Os gerentes de projetos em empresas de excelência consideram que chegam a utilizar até 90% de seu tempo em comunicação interpessoal interna com os integrantes das suas equipes”. (KERZNER, 2002, p. 301).

Outro ponto de atenção de muita importância é a motivação das pessoas envolvidas na realização do projeto. O gerente de projeto deve monitorar constantemente a motivação das pessoas. Esse monitoramento deve ser diário. Ao ouvir o bom dia do profissional já se pode perceber que algo pode não estar em conformidade com o desejado.

Este algo pode não ter qualquer relação com o projeto, mas independente disso, estamos lidando com pessoas, logo, compreender o que está causando desconforto no profissional pode ser de grande valia. A importância de compreender os desconfortos do profissional pode significar muito para a pessoa, pois invariavelmente há como oferecer ajuda para melhorar a situação.

112


A adequada atenção e gestão de pessoas em projetos de desenvolvimento de software são fundamentais para a obtenção de uma equipe satisfeita e sucesso nos resultados.


O POÇO DE ALCATRÃO1

Een schip op het strand is een baken in zee.[Um navio na praia é um farol para o mar].

Provérbio Holandês

Nenhuma cena pré-histórica é tão vívida quanto à das batalhas mortais que as grandes feras travavam nos poços de alcatrão. Com os olhos da imaginação é possível ver dinossauros, mamutes e tigres de dentes de sabre lutando para se desvencilhar do piche. Quanto mais feroz a luta, mais envolvente era o alcatrão. E como nenhum animal era tão forte ou habilidoso, todos terminavam afundando no poço.

Nas últimas décadas, os trabalhos de programação de grandes sistemas assemelham-se à luta num poço de alcatrão onde muitas bestas grandes e poderosas caíram violentamente. Muitos emergiram com sistemas funcionando – poucos atingiram seus objetivos, agendas e orçamentos. Grandes e pequenas, extensas ou concisas, uma equipe após a outra se viu presa no alcatrão. Não é apenas um aspecto que parece ser a causa dessa dificuldade – cada pata, individualmente, pode ser puxada para fora. Mas a acumulação de fatores simultâneos e interativos diminui o movimento cada vez mais. Todos parecem ter sido pegos de surpresa por esse problema grudento, cuja natureza é difícil de determinar. Mas nós temos de tentar entendê-lo se pretendemos solucioná-lo.

Com essa finalidade, vamos começar pela identificação da arte de programação de sistemas e as alegrias e tristezas inerentes a ela.

O Produto da Programação de Sistemas

Ao ler um jornal a esmo, alguém poderá se dar conta de que dois programadores em uma garagem remodelada construíram um importante programa que supera os melhores esforços de grandes equipes. E todo programador está preparado para acreditar em tais histórias, porque ele sabe que poderia construir qualquer programa muito mais rápido do que aqueles que são feitos com as mil declarações por ano relatadas por equipe do setor.

Por que então não substituir todas as equipes de programação por dedicadas duplas de garagem? É necessário examinar o que está sendo produzido.


113

No canto superior esquerdo da Figura 1.1 está um programa. Ele está completo, pronto para ser executado pelo autor no sistema para o qual foi desenvolvido. É isso que costuma ser produzido em garagens e este é o objeto que o programador individual utiliza ao estimar produtividade.

Figura 1.1 Evolução do produto da programação de sistemas

Há duas formas de um programador ser convertido em um objeto mais útil, mas mais caro. Estas duas formas estão representadas pelos limites do diagrama.

Indo para baixo, atravessando o limite horizontal, um programa torna-se um programa produto. Este é um programa que pode ser executado, testado, reparado e estendido por qualquer um. É utilizável em muitos ambientes operacionais, para muitos conjuntos de dados. Para tornar-se um programa produto utilizável genericamente, o programa deve ser escrito de uma maneira generalizada. Mais especificamente, o alcance e o formato de entradas devem ser generalizados tanto quanto o algoritmo básico razoavelmente permitir. Depois o programa deve ser efetivamente testado de modo que se possa confiar nele. Isso significa que uma base substancial de casos de testes, explorando a extensão das entradas e testando seus limites, deve ser preparada, executada e registrada. Finalmente, a promoção de um programa para um programa produto requer uma cuidadosa documentação, de forma que qualquer um possa utilizá-lo, corrigi-lo e estende-lo. Como regra geral, eu estimo que um programa produto custe ao menos três vezes mais do que um programa, já depurado, que tenha a mesma função.

114


Movendo-se pelo limite vertical, um programa torna-se componente de um sistema de programas. Tal sistema consiste em uma coleção de programas que interagem de forma coordenada em sua função e disciplinada em seu formato, de maneira que o conjunto constitua um ambiente completo para a execução de grandes tarefas. Para tornar-se componente de um sistema de programas, um programa deve ser escrito de forma que todas as entradas e saídas estejam em conformidade com a sintaxe e semântica do sistema, com interfaces precisamente definidas. O programa também deve ser projetado para usar apenas uma quantidade de terminada de recursos – espaço em memória, dispositivos de entrada e saída, tempo de processamento. Finalmente, o programa deve ser testado em conjunto com outros componentes do sistema em todas as combinações previstas. O teste deve ser extensivo, já que o número de casos cresce de forma combinatória. Tudo isso consome tempo, pois problemas sutis surgem a partir de interações inesperadas com componentes já depuradas. O componente de um sistema de programas custa ao menos três vezes mais do que o programa isolado que realiza a mesma função. O custo pode ser maior se o sistema tiver muitos componentes.

No canto inferior direito da Figura 1.1 está o produto da programação de sistemas. Este se diferencia do simples programa de todas as formas descritas anteriormente. Ele custa nove vezes mais. Mas ele é o objeto verdadeiramente útil, o produto pretendido da maioria dos esforços de programação de sistemas.

As Alegrias da Arte

Por que é divertido programar? Que alegrias o praticante dessa arte pode ter como recompensa?

A primeira é a satisfação de construir algo. Da mesma maneira que uma criança delicia-se com seu bolinho de lama, os adultos divertem-se construindo coisas, sobretudo aquelas que eles mesmos projetam. Penso que essa alegria vem da imagem da alegria de Deus em criar, uma alegria que se revela nas diferenças e singularidades de cada folha de árvore, de cada floco de neve.

A segunda é a felicidade de se construir coisas que são úteis para os outros. Bem no fundo, queremos que outros experimentem nosso trabalho e o considerem útil. Assim, a programação de um sistema não é em si diferente do primeiro porta-lápis de argila que uma criança faz “para o escritório do papai”.

A terceira é o fascínio da montagem de objetos complexos, à semelhança de um quebra-cabeça com peças móveis que se interconectam, e da observação de como tudo trabalha em ciclos sutis, gerando consequências de princípios estabelecidos desde o início. O computador programado tem todo o fascínio de uma máquina de fliperama ou do mecanismo de um jukebox, levado ao extremo.

A quarta é a aprendizagem constante, que vem da natureza não repetitiva da tarefa. De uma forma ou de outra, o problema é sempre novo, e quem o soluciona aprende algo: algumas vezes a prática, outras a teoria, ou ambas.


115

Finalmente, há a delícia de trabalhar em um meio tão maleável. O programador, como o poeta, trabalha apenas levemente deslocado de um ambiente de pensamento puro. Ele constrói seus castelos no ar, de ar, criando a partir da sua imaginação. Poucos meios de criação são tão flexíveis, tão fáceis de polir e retrabalhar, tão prontamente capazes de produzir grandes estruturas conceituais.

Entretanto, o construto de um programa, ao contrário das palavras de um poeta, é real no sentido de que se move e trabalha, produzindo saídas visíveis e separadas do construto em si. Ele imprime resultados, desenha gráficos, produz sons, move braços. A mágica de mitos e lendas tornou-se realidade em nosso tempo. Basta alguém digitar o encantamento correto em um teclado e logo uma tela de visualização ganha vida, mostrando coisas que não existiam nem poderiam existir.

Por isso, a programação é divertida, porque satisfaz anseios criativos acalentados profundamente dentro de nós e deleita sensibilidade que temos em comum com todos os seres humanos.

As tristezas da Arte

Nem tudo, porém, é deleite. Conhecer as dificuldades inerentes ao trabalho torna mais fácil suportá-las quando elas surgem.

Antes de tudo, a execução deve ser perfeita. Nesse aspecto, o computador se assemelha à mágica das lendas. Se uma letra ou uma pausa do encanto não estão rigorosamente no formato apropriado, a mágica não dá certo. Seres humanos não estão acostumados a serem perfeitos, e poucas áreas da atividade humana exigem isso. O ajuste ao requisito da perfeição é, penso eu, a parte mais difícil de aprender a programar.

Além disso, são as outras pessoas que definem os objetivos, fornecem os recursos e trazem a informação. É raro o programador controlar as circunstâncias de seu trabalho ou mesmo seu objetivo. Em termos gerenciais, a autoridade não é suficiente para a própria responsabilidade. Parece que em todos os campos, porém, os trabalhos nos quais as coisas são feitas nunca tem uma autoridade formal proporcional à responsabilidade. Na prática, a autoridade real (em oposição à autoridade formal) é adquirida no exato momento da realização.

A dependência de outros constitui um caso especial e particularmente doloroso para o programador de sistema. Ele depende dos programas desenvolvidos por outras pessoas. Estes costumam ser mal projetados, fracamente implementados, entregues de forma incompleta (sem o código fonte ou casos de teste) e com documentação insuficiente. Assim, o programador precisa gastar horas estudando e corrigindo coisas que, em um mundo real, deveriam estar prontas, disponíveis e utilizáveis.

116


Outra dificuldade considerável é que o projeto de grandes conceitos pode ser uma diversão, mas a tarefa de encontrar problemas pequenos e cansativos é apenas trabalho. Ao lado da atividade criativa, há também melancólicas horas de trabalho monótono e cansativo. Programar não é excessão.

Logo se descobre que a depuração de problemas tem também uma convergência linear; pior ainda é quando essa depuração de alguma forma assume um comportamento quadrático em direção ao final do trabalho. Assim os testes se arrastam mais e mais, sendo que os problemas ao final do processo levam mais tempo para serem descobertos do que os que estavam no começo.

A última dificuldade, algumas vezes o último estertor, é que o produto no qual se trabalhou por tanto tempo parece obsoleto quando fica pronto (ou mesmo antes disso). Os colegas e concorrentes já estão em busca de novas e melhores ideias. A realização do fruto do pensamento já não se dá apenas em sua concepção, mas em sua agenda.

Esse quadro sempre parece pior do que realmente é. O produto novo e melhor, normalmente não está disponível quando o programador completa o seu, apenas comenta-se sobre ele. Esse novo produto também requer meses de desenvolvimento. O tigre real nunca é páreo para o de papel, a não ser que sua utilidade verdadeira seja desejada. Dessa forma, as virtudes da realidade satisfazem-se em si.

É claro que a base tecnológica na qual um programador trabalha está sempre evoluindo. Tão logo um projeto é congelado, ele se torna conceitualmente obsoleto. Mas a implementação de produtos reais demanda sua divisão em fases e também sua quantificação. A obsolescência de uma implementação deve ser medida em relação a outras implementações já existentes e não contra conceitos não implementados. O desafio e a missão são os de encontrar soluções para problemas existentes, com cronogramas realistas dentro dos recursos disponíveis.

Eis, então, o que é programar: um poço de alcatrão, no qual muitos esforços sucumbiram, e uma atividade criativa que traz em si alegrias e tristezas. Para muitos, as alegrias superam as tristezas. Para estes, os textos adiante, neste livro, tentarão mostrar algumas calçadas que atravessam o alcatrão.

1 Os poços de alcatrão (piche) de La Brea, na Califórnia, compõem um sítio arqueológico onde muitos animais pré-históricos foram descobertos. Os animais caíam nos poços que afloravam à superfície e não conseguiam mais sair, afundando enquanto se debatiam.

FONTE: BROOKS, Frederick Phillips. O mítico homem-mês: ensaios sobre engenharia de software. Rio de Janeiro: Elsevier, 2009, p. 4 – 9.

117

RESUMO DO TÓPICO 3


• É importante que os profissionais de software desenvolvam habilidades e competências no relacionamento com recursos humanos para o adequado gerenciamento de projetos de software.

• O gerenciamento de projetos compreende diversos processos e áreas de conhecimento que devem ser observadas no momento da gestão de um projeto. Porém a gestão de recursos humanos em projetos de software é uma atividade crítica em função da alta dependência humana no processo de software.

• Uma das formas de avaliar um projeto de sucesso é através do fornecimento ou não de entregas e resultados, realização de benefícios associados e satisfação do cliente.

• A matriz RACI é uma ferramenta bastante útil na gestão de projetos de maior porte. Ela fornece uma visão clara e objetiva das responsabilidades dos envolvidos no projeto.

118


1 Liste três habilidades que o profissional de software deve ter para uma boa gestão de recursos humanos em projetos.

2 Liste três fatores críticos de sucesso para um projeto de software.

3 Qual é o conceito de projeto perfeito?

4 O que são soft-skills?

AUTOATIVIDADE

119

UNIDADE 3

QUALIDADE DE SOFTWARE


PLANO DE ESTUDOS

A partir deste capítulo, você será capaz de:

• compreender os fundamentos de qualidade de software;

• conhecer sobre melhoria de processos de software;

• entender aspectos de medição de software;

• conhecer o processo de medição de software.

Esta unidade está dividida em dois tópicos, sendo que ao final de cada um deles, você encontrará atividades que lhe auxiliarão na apropriação dos co-nhecimentos.

TÓPICO 1 – INTRODUÇÃO À QUALIDADE DE SOFTWARE

TÓPICO 2 – MEDIÇÃO DE SOFTWARE

121

TÓPICO 1

INTRODUÇÃO À QUALIDADE DE SOFTWARE

UNIDADE 3

1 INTRODUÇÃOO entendimento popular sobre o conceito de qualidade tem evoluído

à medida que a experiência humana acompanha a evolução tecnológica. As gerações que viveram períodos em que as experiências se davam de forma exclusivamente tangível ainda tem em sua programação genética a ideia de que qualidade é sinônimo de durabilidade.

Já as gerações cujas experiências são mais intangíveis possuem outros parâmetros para opinarem sobre qualidade. As gerações da era da intangibilidade utilizam outros critérios para indicarem se um produto ou serviço possui ou não os requisitos desejados de qualidade. Estas pessoas consideram a qualidade de forma mais sistêmica, considerando inclusive aspectos subjetivos.

Esta evolução foi praticamente proporcional nos padrões de qualidade reconhecidos internacionalmente. Há algumas décadas os padrões de qualidade consideravam critérios puramente tangíveis relacionados ao resultado final. O controle da qualidade se dava quase que exclusivamente no final do processo através de um processo de inspeção do resultado.

Houve um período intermediário em que se entendeu que a qualidade deveria ser inspecionada também nas demais fases de construção. Até que finalmente passou-se a defender a ideia de que a qualidade é resultante de um processo bem definido e que possa ser repetido e melhorado. Então os modelos de qualidade focaram os processos como forma de garantia da qualidade.

Houve também a onda da qualidade total. Todos queriam qualidade total para seus produtos e processos. Até que gradualmente os conceitos em torno da qualidade total amadureceram e desse amadurecimento resultou o entendimento de que a qualidade total é um horizonte que deve ser seguido, mas que podemos não chegar a ele.

Atualmente vivemos o período do entendimento que a qualidade deve ser continuamente melhorada. A filosofia da melhoria contínua nos dá possibilidade de admitirmos que nossos processos precisam melhorar, realizar mudanças e medir novamente para sabermos se melhoramos ou não.

UNIDADE 3 | QUALIDADE DE SOFTWARE

122

Esta perspectiva da qualidade não considera a área de atuação. Porém, para a área de Engenharia de Software é perfeitamente aderente. Na Engenharia de Software já vivemos o tempo em que software de qualidade era aquele que não apresentava falhas graves que impedissem a execução das funcionalidades para as quais o software foi construído.

Evoluímos em relação à qualidade de software, porém ainda há um longo caminho a ser percorrido para atingirmos um patamar aceitável. É necessário dar atenção à qualidade no início do processo de software e não apenas na fase de qualidade, revisão, testes ou qualquer outro nome que se dê para a atividade.

2 FUNDAMENTOS DE QUALIDADE DE SOFTWARE

A palavra qualidade é utilizada na Engenharia de Software e em outras áreas com frequência, porém há muitas dúvidas sobre seu real significado. Então, afinal, o que é qualidade?

Para responder a essa importante pergunta, vamos analisar como algumas autoridades na área da qualidade definem o termo. As autoridades da qualidade selecionadas para análise foram Crosby, Deming, Feigenbaum, Ishikawa, Juran e Shewhart. Iniciaremos entendendo o conceito de maneira independente de área.

Para Crosby (1979) o primeiro pressuposto incorreto sobre qualidade é o de que ela signifique durabilidade, luxo ou beleza. A palavra qualidade é frequentemente utilizada para significar o valor relativo de algo em frases como boa qualidade, má qualidade e qualidade de vida, o que possui significados diferentes para cada pessoa.

Qualidade pode ser definida como conformidade aos requisitos que estão sendo gerenciados. Consequentemente, as não conformidades identificadas significam ausência de qualidade, problemas de não conformidade se tornam problemas de qualidade e então se pode passar a definir o que é qualidade (CROSBY, 1979).

Ao analisar as palavras de Crosby pode-se concluir claramente que para ele qualidade significa conformidade com as especificações. Ele defende também a importância de compreender as expectativas que se tem em relação às questões relacionadas à qualidade de produção, bem como outras perspectivas externas.

Para Crosby (1979) o conceito de qualidade deve estar claro para que seja possível realizar medições e gerenciamento dela. A perspectiva de qualidade de Crosby pode ser sumarizada em quatorze passos que estão apoiados em quatro fundamentos absolutos de gestão da qualidade:

1. Qualidade é definida como conformidade com os requisitos, não como durabilidade ou beleza.

TÓPICO 1 | INTRODUÇÃO À QUALIDADE DE SOFTWARE

123

2 FUNDAMENTOS DE QUALIDADE DE SOFTWARE

2. A forma para obter qualidade é a prevenção, não inspeção. Isto é, a forma de qualidade para os fornecedores atenderem os requisitos dos clientes é fazer certo da primeira vez. Crosby é um forte defensor da prevenção ao invés da inspeção. Numa organização com cultura orientada às ideias de Crosby todos são responsáveis pelo resultado de seu trabalho. Não há ninguém para encontrar erros.

3. O padrão de desempenho deve ser zero defeitos, não sendo aceito o “está bom o suficiente”. Crosby (1979) defende que a noção de que zero defeitos pode e deve ser o objetivo.

4. A medida da qualidade é o custo da qualidade. Uma imperfeição tem um efeito imediato na redução do desempenho, podendo refletir na relação com o cliente. Neste caso, investimentos precisam ser feitos com treinamentos e outras atividades que permitam eliminar os erros e recuperar o custo das perdas.

Deming (1988) argumenta que a dificuldade em definir qualidade reside na tradução de futuras necessidades dos usuários em características mensuráveis. Assim um produto pode ser projetado e produzido de forma a satisfazer as necessidades a um custo aceitável pelos usuários.

A grande dificuldade está no fato de que quanto mais se consegue aproximar do produto ideal, descobre-se que novos esforços precisam ser empreendidos. No tempo que as melhorias foram realizadas as necessidades dos usuários mudaram, os produtos concorrentes evoluíram mais rápido, entre outros fatores (DEMING, 1988).

O ponto chave do conceito de Deming é que a qualidade deve ser definida em termos de satisfação dos usuários. Este conceito muito mais amplo que a definição de qualidade como conformidade com as especificações. Deming (1988) defende que a qualidade deve ser definida apenas do ponto de vista de quem julga a qualidade.

Para facilitar o entendimento de sua perspectiva sobre qualidade, Deming (1988) introduziu catorze pontos de gerenciamento para ajudar as pessoas a entenderem e implementar a transformação necessária:

1. Criar constância de propósito para melhoria de produtos e serviços.2. Adotar a nova filosofia.3. Cessar a dependência de inspeção em massa.4. Deixar de basear os negócios em preços.5. Melhorar constantemente e continuamente o sistema de produção e serviços.6. Instituir treinamentos.7. Instituir liderança.8. Eliminar o medo.9. Quebrar barreiras entre departamentos.10. Eliminar slogans, exortações e metas numéricas.11. Eliminar cotas numéricas e padrões de trabalho.


124

12. Remover barreiras para poder orgulhar-se das habilidades.13. Instituir um vigoroso programa de educação.14. Agir para conquistar a transformação.

A qualidade não pode ser determinada pelos profissionais de software, nem pelo marketing, nem pela administração. Ela é determinada pelo cliente através de sua experiência com o produto ou serviços disponibilizado.

Os requisitos utilizados para determinação da qualidade podem ou não estar declarados, realizados ou não em consenso, tecnicamente operacionais ou completamente subjetivos. É importante que as metas apresentem sempre movimento no sentido de atender um mercado competitivo.

Para Feigenbaum (1983) a qualidade de produto ou serviço pode ser definida como: a composição total das características de marketing, engenharia, manufatura e manutenção de produtos e serviços através dos quais o uso atenderá as expectativas dos clientes.

Esta definição de qualidade pode ser resumida como atendimento das necessidades dos clientes. Embora Feigenbaum vá além, defendendo o atendimento atual e futuro das necessidades dos clientes. Isto significa que para ele o conceito de qualidade não é estático, mas que deve ser atualizado conforme mudarem as necessidades.

A forma de interpretar o termo qualidade é importante, pois se for interpretada de forma restrita significará qualidade de produtos, mas se for interpretada de forma abrangente, o termo significará qualidade de produtos, serviços, informações, processos, pessoas, sistemas etc. (ISHIKAWA, 1985).

No processo de controle de qualidade o objetivo é obter produtos cuja qualidade possa satisfazer os requisitos dos clientes. O simples fato de atender a padrões ou especificações nacionais não é o suficiente. Os padrões internacionais definidos pela ISO (International Organization for Standardization) ou pela IEC (International Eletrotechnical Commission) não são perfeitos.

Os padrões possuem muitas falhas. Os clientes podem não estar satisfeitos com um produto que atenda estes padrões. É necessário ter em mente que os requisitos dos clientes mudam de um ano para outro e mesmo padrões atualizados frequentemente dificilmente acompanham a velocidade de mudança dos requisitos dos clientes.

A perspectiva de qualidade de Ishikawa está direcionada para a definição de que qualidade é atender às necessidades dos clientes e acompanhar as mudanças de expectativas. Isto significa que qualidade é um conceito dinâmico, pois as necessidades, os requisitos e expectativas dos clientes mudam continuamente.


125

Desta forma, qualidade deve ser definida de forma compreensiva e dinâmica. Além disso, Ishikawa (1985) defende que o preço também é um atributo de qualidade. Ele argumenta que um produto com preço alto pode não satisfazer o cliente e consequentemente do ponto de vista dele não ter alta qualidade.

Qualidade é um requisito básico e implícito em qualquer atividade, porém é importante lembrar que vivemos em um mondo finito e, portanto, a qualidade também possui seus limites. Existem situações em que a melhoria na qualidade pode inviabilizar os custos do produto ou atividade, logo, procura-se trabalhar sempre dentro do equilíbrio entre estas forças.

UNI

Qualidade pode ter múltiplos significados no entendimento de Juran (1988). Destes múltiplos significados, dois são os mais importantes. O primeiro significado é o de que qualidade consiste das características do produto que atende às necessidades dos clientes, provendo um produto que atenda a suas necessidades.

O segundo significado diz que qualidade consiste na inexistência de deficiências. Analisando por outra ótica, Juran (1988) defende que o termo qualidade pode ser definido como adequado para uso (fitness for use).

A definição de qualidade de Juran (1988) destaca que não se pode definir qualidade apenas em termos de satisfação das expectativas ou especificações dos clientes por ser muito difícil atingi-la. Ao invés disso, ele define qualidade como adequado ao uso, indicando referências a requisitos e características do produto.

Desta forma, a definição de Juran (1988) pode ser interpretada como uma definição mais voltada para conformidade com as especificações do que uma definição de atendimento das necessidades dos clientes. Juran (1988) propôs três processos para o gerenciamento da qualidade:

• Planejamento da qualidade.• Controle da qualidade.• Melhoria da qualidade.

Através destes três processos entende-se que seja possível realizar as atividades necessárias à obtenção de níveis desejáveis de qualidade. Os processos de planejamento, controle e melhoria ocorrem em ciclos contínuos, de maneira muito similar ao ciclo PDCA (Plan, Do, Check, Act).


126

Um olhar que pode ser considerado ainda mais sistêmico é o de Shewhart (1931). Ele entende que há dois aspectos comuns na qualidade. O primeiro aspecto diz respeito à consideração da qualidade como um objetivo independente da existência do homem. O segundo, como se pensa, sente e percebe a realidade, ou seja, o lado subjetivo da qualidade.

Embora o conceito de qualidade de Shewhart seja de 1920 pode ser considerado um dos mais completos, pois define os lados objetivo e subjetivo da qualidade. O conceito se enquadra nas definições de conformidade com as especificações e atendimento das necessidades dos clientes.

Focando especificamente na área Engenharia de Software, também podemos encontrar algumas definições derivadas das clássicas e que são bastante interessantes. Do ponto de vista de Hoyer e Hoyer (2001), a qualidade de software possui duas principais definições:

• Conformidade com as especificações: aplicável quando a qualidade de um produto ou serviço é definida em termos de características mensuráveis em relação a uma especificação previamente definida.

• Atendimento das necessidades dos usuários: aplicável quando a qualidade de um produto ou serviço é definida em termos de satisfação das expectativas dos usuários, ou seja, independente de características mensuráveis em relação a uma especificação previamente definida.

Da mesma forma como os conceitos clássicos da qualidade, em software podemos utilizar abordagens qualitativas e quantitativas. As estruturas genéricas da qualidade são relativamente mais qualitativas. Para uma abordagem mais quantitativa podem-se utilizar modelos de qualidade dentre os quais se podem citar os modelos de McCall, Boehm, FURPS, Dromey, ISO, IEEE, CMM e Seis Sigma.

Do ponto de vista de Engenharia de Software, um dos modelos mais notáveis é o modelo de qualidade de McCall, também conhecido como o modelo da General Eletric de 1977. Este modelo, assim como outros contemporâneos, é originário das Forças Armadas dos EUA (desenvolvido para a Força Aérea dos EUA, promovido no âmbito do DoD) e é voltado principalmente para os desenvolvedores de sistemas e para os processos de desenvolvimento de sistemas.

Este modelo de qualidade tenta preencher a lacuna entre os usuários e desenvolvedores em torno de uma série de fatores de qualidade de software que refletem tanto as prioridades do ponto de vista dos usuários quanto dos desenvolvedores.

O modelo de qualidade de McCall tem três grandes perspectivas para a definição e identificação dos critérios de qualidade de um produto de software. O primeiro é a revisão do produto (capacidade de sofrer alterações), o segundo é a transição do produto (adaptabilidade a novos ambientes) e o terceiro a operação de produto (suas características de operação).


127

Uma das melhores referências que pode ser utilizada para o assunto é o SWEBOK (Software Engineering Body of Knowledge). Na realidade, ele trata de diversos aspectos relacionados a software e a qualidade é um deles.

O SWEBOK está organizado em diversos capítulos que tratam de requisitos, design, construção, testes, manutenção, gerenciamento de configuração, gerenciamento da engenharia, processos de engenharia, métodos e ferramentas de engenharia, qualidade e disciplinas relacionadas (IEEE, 2004).

UNI

No SWEBOK são citados alguns autores com maior aderência à área de software. Dentre os autores citados está Crosby (1979) definindo qualidade como conformidade aos requisitos do usuário, Humphrey como obtenção de excelentes níveis de adequação ao uso e IBM como qualidade orientada ao mercado, na qual a ideia é obtenção da satisfação total do cliente (IEEE, 2004).

Uma série de recomendações para a melhoria da qualidade de software pode ser encontrada no SWEBOK. Estas formas são divididas nas categorias estática e dinâmica. As formas estáticas não requerem a execução do software avaliado e as dinâmicas são baseadas na execução do software (IEEE, 2004).

Se analisarmos o capítulo que trata de qualidade de software, podemos observar que ele está estruturado da seguinte forma (IEEE, 2004):

• Fundamentos de qualidade de software.• Processos de gerenciamento da qualidade de software.• Considerações práticas.

FIGURA 17 – ESTRUTURA DA QUALIDADE DE SOFTWARE

FONTE: Adaptado de IEEE (2004)


128

Na seção que trata dos fundamentos de qualidade de software o conceito importante que deve ser compreendido é que os requisitos de software definem as características da qualidade de software e influenciam os métodos de medição e critérios de aceitação (IEEE, 2004).

A seção que trata dos processos de gerenciamento da qualidade de software foca no quanto o produto de software satisfaz os requisitos dos usuários, agrega valor aos envolvidos e possui níveis de qualidade necessários para atender aos requisitos de software.

O processo de gerenciamento da qualidade de software consiste de uma série de atividades. Algumas visam encontrar defeitos e indicar onde seria recomendável realizar uma análise mais criteriosa. No planejamento da qualidade são definidos os requisitos de qualidade do produto e os processos para obtenção de tal produto.

Já a seção das considerações práticas relacionam recomendações sobre os requisitos da qualidade de software, caracterização de defeitos, técnicas de gerenciamento da qualidade de software e medição da qualidade de software. Em relação à medição da qualidade de software os indicadores são destacados como forma de explicitar a aderência aos padrões estabelecidos.

Seguindo a linha das definições e entendimentos de pesquisadores sobre qualidade de software Bartiè (2002) traz a seguinte contribuição. Para ele qualidade de software é um processo sistemático que focaliza todas as etapas e artefatos produzidos com o objetivo de garantir a conformidade de processos e produtos, prevenindo e eliminando defeitos.

Já Pressman (1995) entende que um software de qualidade é aquele que foi construído com base em padrões de desenvolvimento devidamente documentados, que esteja em conformidade com os requisitos funcionais e que atenda aos requisitos não funcionais declarados de maneira explícita. Complementando seu conceito, Pressman (1995) indica que há três pontos importantes que devem ser observados:

• Os requisitos são a base para a qualidade.• Os padrões de engenharia especificados devem ser seguidos.• Os requisitos implícitos devem ser considerados e seguidos.

Uma das formas mais simples de medir a qualidade de software é contra os requisitos. Se os requisitos não forem especificados de maneira correta, a qualidade será comprometida. Qualquer software que seja construído sem que haja uma definição clara de seus requisitos terá alta probabilidade de problemas de qualidade durante seu ciclo de vida.


129

Quando somos levados a utilizar normas e padrões logo acreditamos que para segui-las precisaremos atender a uma extensa lista de atividades. Na realidade as normas e padrões que serão seguidos são definidos pela equipe. Os padrões de engenharia de software utilizados por uma equipe de desenvolvimento são definidos pela própria equipe.

Ao realizar a definição de processos de engenharia de software é importante ter foco em simplicidade e eficiência. Se o processo começar a ficar complexo, pode ser que a solução que está sendo desenhada não seja aplicável. Se essa premissa for seguida, os padrões definidos serão mais eficientes.

3 MELHORIA DA QUALIDADE

A melhoria da qualidade é uma questão cada vez mais latente na área de Engenharia de Software. À medida que aumenta a dependência das organizações por aplicações de software para realização de suas atividades, aumenta também a criticidade da falta deles. É muito crítico deixar uma unidade de negócios sem operar por falhas de software.

Esta questão está em discussão na Engenharia de Software e também em diversas áreas de negócios. A aceitação do conceito de que o processo de produção tem um grau de relevância representativo no resultado final, tem aumentado (GHEZZI, 2003).

Na Engenharia de Software os processos são um importante pilar. A Engenharia de Software está apoiada no tripé: pessoas, processos e tecnologias. Os processos são importantes para facilitar uniformidade de desempenho no desenvolvimento de diversos projetos, permitindo redução de custos e do tempo de entrega.

Processos também tem alto grau de influência sobre a qualidade dos resultados do desenvolvimento de software. Esta influência está relacionada ao controle realizado nos processos. Os controles deve permitir obter maior domínio sobre a qualidade necessária para os softwares (GHEZZI, 2003).

Para tanto, pesquisadores e profissionais de software têm empreendido esforços no desenvolvimento de modelos que tragam os resultados desejados. Estes esforços evidenciam a influência dos processos na qualidade do produto final (MICHLMAYR, 2008).

Muitos dos resultados obtidos estão traduzidos em normas e modelos atualmente conhecidos e adotados de forma ampla. Exemplos são as normas da família ISO 9000 (ISO/IEC, 2006), bem como o modelo CMMI – Capability Maturity Model Integration (CMMI Product Development Team, 2006), norma ISO/IEC 15504 (ISO/IEC, 2006) e MPS.BR (SOFTEX, 2007), entre outros.


130

A finalidade destas normas e modelos é permitir a avaliação da qualidade do processo de software e realizar melhorias. A partir daí, as organizações poderão tornar-se mais competitivas disponibilizando produtos e serviços com patamares de qualidade reconhecidos nacional e internacionalmente.

No Brasil pode ser observado crescimento considerável no número de empresas que realizaram avaliações oficiais do CMMI nos últimos anos. Uma das principais evidências é o relatório publicado em agosto de 2006 pelo Ministério da Ciência e Tecnologia.

A curva de evolução das organizações com qualificação CMMI no Brasil até agosto de 2006 pode ser observada na figura a seguir. A figura demonstra que apenas no ano de 2003 houve a primeira avaliação CMMI oficial por uma empresa brasileira.

FIGURA 18 – QUANTIDADE DE ORGANIZAÇÕES COM QUALIFICAÇÃO CMMI NO BRASIL

FONTE: MCT, 2006

Pode-se observar também que em 2005 havia 17 empresas avaliadas e em 2006 já eram 21. Apesar deste crescimento, o número de empresas brasileiras avaliadas formalmente ainda é baixo em comparação com outros países. Uma das possíveis explicações pode estar na existência do modelo MPS.BR que é focado na realidade brasileira.

O que pode ser observado também é que a maioria das empresas está concentrada em avaliações em níveis mais baixos de maturidade. A pesquisa do MCT (2006) demonstra que existem 52% de avaliações no nível 2 do CMMI, 19% no nível 3 e apenas 21% nos demais níveis.


131

FIGURA 18 – QUANTIDADE DE ORGANIZAÇÕES COM QUALIFICAÇÃO CMMI NO BRASIL

Porém se observarmos as tendências mundiais, estas estão em linha com a realidade apresentada nas empresas brasileiras. Dados do SEI (2007) demonstram que 40% das empresas foram avaliadas no nível 2 de maturidade, 37% no nível 3 de maturidade e os demais 23% distribuídos nos demais níveis.

Na pesquisa do SEI (2007) pode-se observar também que a concentração nos níveis de maturidade mais baixos é ainda mais acentuada nas micro e pequenas empresas. Esta concentração pode ser considerada natural, pois micro e pequenas empresas tipicamente ainda estão em níveis de maturidade inferiores. E a maturidade será conquistada com o tempo e experiência.

Os atuais modelos de melhoria de processos de software propõem que empresas com níveis de maturidade baixa iniciem o processo de melhoria de seus processos em áreas chave. As principais áreas de processos que devem ser priorizadas são gerência de projetos e medição.

Com a melhoria de processos da gerência de projetos e medição, acredita-se que as empresas de software possam melhorar suas práticas de planejamento, monitoração e controle de seus projetos. Acredita-se também que adquiram capacidade para realizar as medições necessárias para os processos.

As medições são uma premissa para o acompanhamento e melhoria dos processos de software. Definir e utilizar indicadores adequados tem importância crítica para a qualidade de software. “não se pode controlar o que não se pode medir”. (DEMARCO, 1991, p. 3).

Qualidade e produtividade, muitas vezes, são vistos como duas forças opostas. Há quem defenda que para obter qualidade é necessário sacrificar a produtividade. No mesmo sentido, há quem defenda que para obter produtividade, tipicamente a qualidade acaba sendo colocada em segundo plano.

Há também quem defenda que quanto mais maduros forem os processos, melhores serão os níveis de qualidade e produtividade. O entendimento é o de que a maturidade em processos de software influencia a qualidade e em consequência de melhores níveis de qualidade o retrabalho é reduzido, aumentando a produtividade.

O SEI (Software Engineering Institute) realizou uma pesquisa evidenciando que empresas com nível de maturidade baixo podem dedicar cerca de 55% de seus esforços na correção de defeitos produzidos em um projeto de software (BARTIÈ, 2002).

Na mesma proporção que o nível de maturidade da empresa aumenta, os índices de esforço para correção de defeitos é reduzido. Todo esforço dedicado à correção de falhas ou defeitos significa necessidade de retrabalho. E retrabalho compromete a produtividade. A figura a seguir representa graficamente estes dados.


132

FIGURA 19 – ESFORÇO DEDICADO À CORREÇÃO DE DEFEITOS NO DESENVOLVIMENTO DE SOFTWARE

FONTE: Adaptado de Bartiè (2002, p. 14)

O processo de desenvolvimento de software é fortemente dependente do fator humano. O trabalho das pessoas é que gera os artefatos necessários. Dentre estes artefatos estão as especificações de requisitos, modelagens de processos, modelagens de bases de dados, programação, testes, homologação, entre outras importantes atividades.

Retrabalho é equivalente a tempo jogado fora. Como o processo de software é fortemente dependente do fator humano, tempo é igual a dinheiro. Logo, se um processo de software no qual são produzidos muitos defeitos demanda mais tempo para obtenção do mesmo resultado, também demandará mais dinheiro para tal.

UNI


133

A principal causa de retrabalho é a produção de defeitos. Koscianski e Soares (2007, p. 31) definem defeito como uma “imperfeição de um produto”. No caso de um software, refere-se a falhas produzidas na sua implementação. Esta falha pode estar em um ou mais artefatos, pois pode ter origem em requisitos, design, codificação, testes etc.

Para Koscianski e Soares (2007, p. 32) a “falha é o resultado errado provocado por um defeito ou condição inesperada”. Porém um defeito pode ou não levar a uma falha de software. Um software com defeito poderá funcionar perfeitamente por um longo período de tempo até que uma situação específica faça com que uma falha ocorra.

Como a origem de defeitos pode estar em qualquer fase do processo de software é importante que saibamos qual que tipicamente concentra os maiores índices. Bartiè (2002) demonstra que a maior incidência de defeitos está na fase de requisitos.

E por mais estranho que possa parecer, a fase de implementação (codificação) representa um dos menores percentuais. Estes dados são representados graficamente na Figura a seguir.

FIGURA 20 – INCIDÊNCIA DE DEFEITOS NAS FASES DO PROCESSO DE SOFTWARE

FONTE: Adaptado de BARTIÈ (2002, p. 26)


134

Uma das importantes observações que podemos fazer a partir dos resultados apresentados por Bartiè (2002) é que a qualidade de software não se dá apenas na fase de testes. Todas as fases do processo de software devem considerar os fatores de qualidade, caso contrário, os resultados não serão os desejados.

O ideal é atingido apenas quando cada artefato for produzido certo, no tempo certo e no custo certo. Na entrega de cada artefato deve-se ter certeza de que a entrega está correta e não haverá retrabalho. Pressman (1995) descreve que a garantia da qualidade de software está associada a sete importantes atividades:

• Aplicação de métodos técnicos.• Realização de revisões técnicas formais.• Atividades de testes de software.• Aplicação de padrões.• Controle de mudanças.• Medição.• Manutenção de registros e reporte.

Para Pressman (1995) a aplicação de atividades relacionadas à qualidade de software não são complexas, nem burocráticas e muito menos trabalhosas. Ele defende que se pode obter resultados desejados com pouco esforço. Isso pode ser visto como um grande incentivo para quem pretende melhorar a qualidade e produtividade.

Caso os esforços na melhoria da qualidade e produtividade forem devidamente conduzidos, permitirão melhores níveis de garantia da qualidade de software. A qualidade de um software pode ser afetada por diversos fatores. Pressman (1995) relaciona os seguintes:

• Conformidade (satisfaz a especificação).• Confiabilidade (se executa a função e com precisão).• Eficiência (quantidade de código necessário para executar sua função).• Integridade (controle de acessos indevidos).• Usabilidade (esforço necessário para aprender a operar).• Manutenibilidade (esforço de manutenção).• Flexibilidade (esforço para alterar um programa operacional).• Testabilidade (esforço para testar).• Portabilidade (esforço para transferir de plataforma operacional).• Reusabilidade (quanto pode ser reusado).• Interoperabilidade (esforço para acoplar a outro sistema).

Para que a garantia de qualidade de software SQA (Software Quality Assurance) possa ser obtida, é necessário que seja aplicada em todo o processo de Engenharia de Software. Diante disso, é necessário que sejam adotados procedimentos adequados nas fases de requisitos, design, codificação, testes e implantação.


135

Os padrões de desenvolvimento e revisões devem ser realizados em cada fase do processo de software. DeMarco (1991, p. 3) nos ensina que “não se pode controlar o que não se pode medir”, logo, também devemos utilizar mecanismos de medição e divulgação de indicadores.

Os modelos de processos CMMI e MPS.BR são focados na melhoria de qualidade e produtividade no processo de software. Ambos são baseados nas normas ISO 12207 e ISO 15504. O CMMI é um padrão reconhecido mundialmente e o MPS.BR é um modelo focado na realidade brasileira. O CMMI possui os seguintes níveis de maturidade:

1 – Inicial.2 – Gerenciado.3 – Definido. 4 – Gerenciado quantitativamente.5 – Otimização

FIGURA 21 – REPRESENTAÇÃO DOS NÍVEIS DO CMMI

FONTE: O autor

O modelo apresentado é o CMMI para Desenvolvimento (CMMI-DEV), que "fornece uma solução integrada e abrangente para as atividades de desenvolvimento e manutenção aplicadas a produtos e serviços". (SEI, 2007, p. 11).

O MPS.BR (Melhoria de Processo do Software Brasileiro) é um programa apoiado pelo Ministério da Ciência e Tecnologia (MCT), pela Financiadora de Estudos e Projetos (FINEP) e pelo Banco Interamericano de Desenvolvimento (BID). "O MPS.BR é um programa para Melhoria de Processo do Software Brasileiro coordenado pela Associação para Promoção da Excelência do Software Brasileiro (SOFTEX)” (SOFTEX, 2007). Ele possui os seguintes níveis de maturidade:


136

A - Em otimização.B - Gerenciado quantitativamente.C - Definido.D - Largamente definido.E - Parcialmente definido.F - Gerenciado.G - Parcialmente gerenciado.

FIGURA 22 – REPRESENTAÇÃO DOS NÍVEIS DO MPS.BR

FONTE: O autor

É fundamental que os processos de software estejam bem definidos e sejam seguidos. E isso deve ser uma constante no ciclo de desenvolvimento. Após definir um modelo de maturidade a ser seguido, este deve ser compreendido no nível de detalhamento necessário para maximização dos benefícios oferecidos.

É importante reforçar que maturidade tipicamente não é conquistada de maneira rápida, requer tempo para solidificar os processos e resultados. Portanto, se a meta for conquistar maturidade, não podemos ficar parados.

137

Caro acadêmico! Nesse capítulo, você estudou que:

Segundo Hoyer e Hoyer (2001), as principais definições de qualidade de software são:

• Conformidade com as especificações: aplicável quando a qualidade de um produto ou serviço é definida em termos de características mensuráveis em relação a uma especificação previamente definida.

• Atendimento das necessidades dos usuários: aplicável quando a qualidade de um produto ou serviço é definida em termos de satisfação das expectativas dos usuários, ou seja, independente de características mensuráveis em relação a uma especificação previamente definida.

• Para a qualidade de software, Pressman (1995) indica que se deve observar: • Os requisitos são a base para a qualidade. • Os padrões de engenharia especificados devem ser seguidos. • Os requisitos implícitos devem ser considerados e seguidos.

• Juran (1988) define que o gerenciamento da qualidade compreende os seguintes processos:

• Planejamento da qualidade. • Controle da qualidade. • Melhoria da qualidade.

• Melhores níveis de garantia de qualidade de software SQA (Software Quality Assurance) só poderão ser obtidos se processos de qualidade forem aplicados em todo o processo de Engenharia de Software.

RESUMO DO TÓPICO 1

138

Caro acadêmico! Como forma de fixar o conteúdo estudado realize a autoatividade proposta a seguir:

1 De que forma Juran define qualidade?

2 Quais são os aspectos comuns na qualidade para Shewhart?

3 Quais são as perspectivas para definição e identificação dos critérios de qualidade de um software no modelo de McCall?

4 Qual é a finalidade dos modelos CMMI e MPS.BR?

AUTOATIVIDADE

139

TÓPICO 2

MEDIÇÃO DE SOFTWARE

UNIDADE 3

1 INTRODUÇÃOMedição é “o processo pelo qual números ou símbolos são atribuídos a

atributos de entidades do mundo real, de maneira a descrevê-las de acordo com regras claramente definidas”. (FENTON; PFLEEGER, 1997, p. 5). Por entidade pode-se entender um evento ou objeto que será medido e um atributo como uma característica específica que pode ser utilizada como parâmetro.

A medição permite aos profissionais de software medir e prever os processos de software e recursos necessários para o desenvolvimento de um projeto (PETERS; PEDRYCS, 2001). A norma ISO/IEC 15939 define como objetivos da medição de software podem apoiar a gerência e a melhoria de processos e de produtos de software (ISO/IEC, 2002).

A medição de software é reconhecida como uma forma utilizada para o entendimento, monitoramento, controle, predição e melhoria de projetos de desenvolvimento e manutenção de software (BRIAND; DIFFERDING; ROMBACH, 1997).

De forma simplificada pode-se dizer que o objetivo da medição é fornecer informação para melhorar a tomada de decisões a tempo para afetar o resultado do negócio (KOCHANSKI, 2009).

As medições permitem aumentar o conhecimento sobre o processo através do qual o produto é desenvolvido, permitindo que se possa administrar de forma mais efetiva através da quantificação (PRESSMAN, 1995).

A medição permite aos profissionais de software medir e prever os processos de software e recursos necessários para o desenvolvimento de um projeto (PETERS; PEDRYCS, 2001). A medição também é uma fonte de informações, fundamental para fornecer respostas sobre questões relevantes relacionadas aos processos adotados e os resultados obtidos com a utilização dos mesmos (KOCHANSKI, 2009).

Algumas das respostas que podem ser obtidas permitem identificar se os processos técnicos e gerenciais estão adequados e ainda permitem obter subsídios para a melhoria daqueles que não estiverem satisfatórios. (DEMARCO, 1991).

140


Pelo fato da medição dar o suporte necessário para ações de melhoria da qualidade, esta tem se tornado cada vez mais importante no contexto da Engenharia de Software (ROCKENBACH, 2003).

Na norma ISO/IEC 15939 a medição é definida como um conjunto de operações cujo objetivo é a determinação do valor de medidas (ISO/IEC, 2002). Medição é o processo pelo qual números ou símbolos são atribuídos a atributos de entidades no mundo real, descrevendo-os de acordo com regras claramente definidas (FENTON; PFLEEGER, 1997).

Uma medida é uma indicação quantitativa da extensão, quantidade, dimensão, capacidade ou tamanho de um produto ou processo (ISO/IEC, 2002). Já uma métrica é qualquer tipo de medição que se refira a um software, processo ou documentação relacionada (SOMMERVILLE, 2003).

Kettelerij (2006) argumenta que dentre as abordagens existentes para a medição de software as que têm se destacado pela utilização na prática são GQM - Goal/Question/Metric (BASILI; WEISS, 1984) e PSM – Practical Software and Systems Measurement (PSM, 2003).

Dada à importância da correta definição de indicadores, analisaremos os modelos GQM e PSM. A finalidade é entender o processo de definição de objetivos de medição e a partir destes obter indicadores adequados.

2 MODELO GQM

Em organizações cuja gestão esteja fortemente apoiada em sistemas de gerenciamento organizacional, o sucesso pode ser comprometido se a estratégia de negócio não puder ser traduzida em um conjunto de objetivos operacionais no software. É necessário, portanto, que os objetivos organizacionais sejam traduzidos em objetivos de medição para que os dados obtidos contribuam nas decisões de alto nível da organização (BASILI et al., 2007).

A abordagem GQM tem se mostrado bastante útil em diversos contextos organizacionais no apoio ao estabelecimento do gerenciamento quantitativo de projetos de software (BASILI et al., 2007). O GQM – Goal/Question/Metric (BASILI; WEISS, 1984) é uma abordagem de medição cuja orientação está voltada aos objetivos de medição de processos e produtos de software.

Originalmente o método GQM foi desenvolvido por Victor Basili e David Weiss na Universidade de Maryland de forma cooperada com o Software Engineering Laboratory do NASA Goddard Space Flight Center (KOCHANSKI, 2009).

O GQM é uma abordagem que permite sistematizar a adaptação e integração de objetivos com base nas necessidades específicas de cada projeto e de uma organização, aos modelos dos processos de software, produtos e perspectivas de interesse de qualidade (BASILI; CALDIERA; ROMBACH, 1994).

TÓPICO 2 | MEDIÇÃO DE SOFTWARE

141

2 MODELO GQM

O método GQM, desenvolvido por Victor R. Basili e David M. Weiss, foi estendido com outros conceitos por Dieter H. Rombach. O método GQM é resultado de diversos anos de experiência prática e pesquisas acadêmicas (SOLINGEN; BERGHOUT, 1999). A ideia básica do GQM é derivar métricas de software a partir de perguntas e objetivos.

A adoção sistemática de medições é tipicamente realizada através de um programa de medição. Programas de medição podem apresentar diversos tipos de benefícios. O mais desejável é o atendimento dos objetivos de melhoria explícitos os quais podem estar relacionados a produtos ou processos (KOCHANSKI, 2009).

Um programa de medição pode proporcionar também a melhoria na comunicação com a equipe do projeto, definição dos processos e execução dos processos. A questão dos benefícios financeiros diretos é de difícil medição, pois existem muitos fatores indiretos envolvidos (SOLINGEN; BERGHOUT, 1999).

FIGURA 23 – FASES DO MÉTODO GQM

FONTE: Solingen e Berghout (1999)

A abordagem GQM está fundamentada em dois princípios. O primeiro princípio diz que um programa de medição deve ter como base um conjunto de objetivos e não estar baseado em medidas. O segundo princípio diz que cada organização deve realizar a definição de objetivos e medidas específicos para sua realidade (SOLINGEN; BERGHOUT, 1999).

No roteiro de um programa de medição estabelecido com base na abordagem GQM as atividades devem iniciar pela definição dos objetivos de medição. Uma vez definidos os objetivos de medição, deve-se realizar o

142


refinamento de cada objetivo em questões a partir das quais são definidas medidas que permitam prover as informações necessárias para responder as questões elaboradas (KOCHANSKI, 2009).

São os dados obtidos pela medição que permitem responder as questões que por sua vez são analisadas para identificar se os objetivos de medição estabelecidos foram ou não atingidos. Este roteiro demonstra que a abordagem suporta a definição de um programa de medição de forma top-down e a análise e interpretação dos dados de medição de forma bottom-up. A figura a seguir demonstra graficamente estas duas visões.

FIGURA 24 – O PARADIGMA GQM

FONTE: Adaptado de Wangenheim (2000)

As vantagens desta abordagem são o suporte à identificação de métricas úteis e relevantes, bem como o suporte à análise e interpretação dos dados coletados. Ela permite ainda um assessoramento da validade das conclusões chegadas, além de reduzir a resistência quanto a programas de medição (WANGENHEIM, 2000).

O método GQM faz a descrição do planejamento e execução de um programa de medição baseado no paradigma GQM (WANGENHEIM, 2000). O método GQM proposto por Basili e Weiss (1984) é composto pelas fases de planejamento, definição, coleta de dados e interpretação.

Utilizando como base experiências de aplicações em várias empresas do paradigma GQM, Gresse, Hoisl e Wüst (1995) modelaram um processo GQM detalhado, incluindo um exemplo completo de um programa de medição.


143

As fases do processo GQM modelado são orientadas ao paradigma de melhoria de qualidade (QIP – Quality Improvement Paradigm) proposto por Basili, Caldiera e Rombach (1994). Uma visão deste processo é apresentada pela figura a seguir.

FIGURA 25 – O PROCESSO DE MEDIÇÃO GQM


Um programa de medição deve iniciar com um estudo prévio com o objetivo de identificar modelos de experiências relevantes com base nos objetivos e características da organização e dos projetos (GRESSE; HOISL; WÜST, 1995).

Um projeto piloto para iniciar o programa de medição deve ser selecionado e caracterizado. Utilizando as informações do passo anterior do processo, deve-se especificar um objetivo a ser atingido pelo programa de medição (KOCHANSKI, 2009).

Com base neste objetivo especificado deve-se derivar um conjunto de medidas relevantes a partir de perguntas e modelos resultando em um plano GQM o qual consiste em um objetivo, perguntas, modelos e medidas.

No passo seguinte deve-se definir um plano de medição através da integração das medidas definidas no plano GQM com o plano de projeto de software. No plano de medição deve ser especificado quando, como e por quem os dados necessários serão coletados (KOCHANSKI, 2009).

144


Na fase de execução do programa de medição os dados devem ser coletados em conformidade com o que foi especificado no plano de medição. Os dados coletados devem ser analisados e interpretados contra os objetivos do GQM de acordo com o plano GQM em sessões de feedback (KOCHANSKI, 2009).

Estudo Prévio

O objetivo do passo de estudo prévio é a coleta de informações pertinentes com o objetivo de obter subsídios para a introdução de um programa de medição em uma organização. As informações coletadas neste passo são utilizadas como apoio na seleção de um projeto que possa servir de piloto e para a definição de objetivos de medição (KOCHANSKI, 2009).

Inicialmente devem ser identificadas pré-condições e restrições relacionadas à introdução do programa de medição. Este trabalho pode ser realizado com base em documentação já existente na organização como, por exemplo, um manual de processo de software. Havendo programas de medição anteriores, este trabalho também pode ser realizado com base nas experiências existentes (KOCHANSKI, 2009).

Também é realizada a caracterização da organização considerando o domínio de aplicação, setor de negócios etc. São identificados os objetivos de negócio e os objetivos de melhorias organizacionais. São caracterizados projetos potenciais para a aplicação de medição, considerando duração, representatividade em relação aos demais projetos da organização etc. Um projeto piloto para introdução de um programa de medição baseado no paradigma GQM é selecionado com base nas informações obtidas (KOCHANSKI, 2009).

Identificação de Objetivos GQM

Utilizando as informações obtidas no passo anterior do processo, ou seja, nas informações coletadas no estudo prévio, os objetivos do GQM são derivados dos objetivos de negócio, objetivos estratégicos da organização e dos objetivos organizacionais de melhoria com respeito aos problemas conhecidos (KOCHANSKI, 2009).

Aspecto Definição Exemplo

Objetivo O que será analisado?Processo de desenvolvimento, teste, documento de projeto, sistema de software.

Propósito Porque o objetivo será analisado?

Caracterizar, avaliar, predizer, monitorar, controlar, modificar.

QUADRO 3 – ASPECTOS DOS OBJETIVOS DE MEDIÇÃO


145

Enfoque deQualidade

Quais propriedades/ atributos de objeto serão analisados?

Confiabilidade, custos, correção, remoção, remoção de defeitos, modificações, manutenibilidade.

Ponto de Vista Quem usará os dados coletados?

Gerente do projeto, desenvolvedor, equipe de garantia de qualidade, usuário, gerente.

Contexto Em qual ambiente? Projeto X, Departamento A.

FONTE: Adaptado de Briand, Differding e Rombach (1997).

Na definição de objetivos GQM é necessário que seja especificado o objetivo, o propósito, o enfoque de qualidade, um ponto de vista e o contexto. O quadro anterior apresenta os aspectos dos objetivos de medição.

Desenvolvimento do plano GQM

Cada objetivo definido no passo anterior do processo deve ter um plano GQM associado. O que define um plano GQM é a existência de um objetivo GQM e um conjunto de perguntas, modelos e medidas (BRIAND; DIFFERDING; ROMBACH, 1997).

A finalidade das perguntas é identificar a informação necessária para atingir o objetivo e a finalidade das medidas é definir de forma operacional os dados que devem ser coletados para que seja possível responder as perguntas.

O plano permite a identificação clara dos motivos pelos quais as medidas são definidas, bem como as mesmas serão utilizadas. O modelo utiliza os dados que foram coletados como forma de gerar respostas às perguntas efetuadas.

A forma de determinar perguntas, que sejam relevantes aos objetivos definidos, são realizadas entrevistas com o objetivo de obter informações relativas ao conhecimento implícito das pessoas envolvidas no processo. As entrevistas são realizadas com as pessoas definidas do ponto de vista do objetivo GQM.

Essas pessoas podem ser desenvolvedores, gerentes de projeto, analistas de testes etc. O conhecimento que é adquirido a partir das informações coletadas durante as entrevistas é utilizado como base para a realização da derivação de perguntas, modelos e medidas que sejam relevantes ao objetivo.

Os resultados obtidos através destas entrevistas são registrados em abstraction sheets. O abstraction sheet é um documento de uma página com cabeçalho, no qual é declarado o objetivo GQM, bem como os quadrantes relativos aos fatores de qualidade, hipótese de linha-base, fatores de variação e impacto da hipótese na linha-base. No quadro a seguir é apresentado um exemplo de abstraction sheet.

146


QUADRO 4 – EXEMPLO DE ABSTRACTION SHEET

Objeto Propósito Enfoque de Qualidade Ponto de Vista Contexto

Processo de software Caracterizar Confiabilidade Desenvolvedor Empresa X

Projeto A

Fatores de Qualidade Fatores de Variação

- Número total de defeitos.- Número de defeitos por criticidade (não crítico, crítico).- Número de defeitos por fase de introdução (REQ, HLD etc.).

- Tipo de inspeção de código.

Hipótese de Linha-Base Impacto na Hipótese de Linha-Base

- Número total de defeitos: 120.- 75% não crítico e 25% crítico.- REQ 10, HLD 10 etc.

- Com inspeção de código ad-hoc menos defeitos são detectados do que com outros tipos de inspeção.


Utilizando as informações contidas no abstraction sheet é desenvolvido um plano GQM, o qual deve conter perguntas, modelos e medidas. Um exemplo simplificado de plano GQM é apresentado no quadro que segue.

QUADRO 5 – EXEMPLO SIMPLIFICADO DE UM PLANO GQM

Q1. Qual é o número total de defeitos antes da entrega?Modelo: Número total de defeitos pode ser calculado com base no número total de relatórios de defeitos.M1.1: Contator de relatórios de defeitos informados entes da entrega [racional: inteiro].

Q2. Qual é a distribuição de defeitos informados antes da entrega por criticidade?Modelo: Distribuição = (# de defeitos não críticos / total # de defeitos, # de defeitos críticos / total # de defeitos). Não crítico: impossível de executar uma ou mais funções F1-F6; crítico: breakdown completo do sistema.M2.1: Classificação dos relatórios de defeitos encontrados entra da entrega por criticidade (ordinal: não crítico, crítico, outros].M2.2: Número total de defeitos detectados antes da entrega [ordinal: inteiro].

Q3. Qual é a distribuição de defeitos detectados antes da entrega por fase do ciclo de vida da introdução?Modelo: Distribuição = (# de defeitos em REQ / total # de defeitos, # de defeitos em HLD / total # de defeitos, ...).M3.1: Contador de defeitos por fase do ciclo de vida onde o defeito foi introduzido [nominal: REQ, HLD, ...].

FONTE: Adaptado de Wangenheim (2000).


147

O principal objetivo da realização de um plano GQM é a obtenção da definição quantitativa do objetivo GQM estabelecido em um conjunto de medidas através de perguntas e modelos. Este objetivo utiliza como base os fatores de qualidade e fatores de variação que foram identificados durante as entrevistas (KOCHANSKI, 2009).

Desenvolvimento do plano de medição

O plano de medição tem por objetivo a integração de medidas no plano do projeto piloto a ser desenvolvido. Desta forma, é determinado quando, como e quem deverá coletar os dados para cada medida identificada nos planos GQM. Nos procedimentos de coleta e armazenamento de dados, é importante que seja considerada a confiabilidade dos dados coletados e a intrusividade da coleta dos dados (BRIAND; DIFFERDING; ROMBACH, 1997).

É importante considerar a necessidade de minimizar ao máximo os custos relacionados à coleta de dados. Um programa de medição baseado no método GQM possui as fases de planejamento, definição, coleta de dados e interpretação dos dados. A seguir cada uma destas fases é explicada em detalhes (KOCHANSKI, 2009).

Fase de Planejamento

O processo de estabelecimento de um programa de medição que esteja baseado no método GQM inicia pela fase de planejamento. Esta fase tem como finalidade a coleta das informações necessárias para o estabelecimento de um programa de medição adequado às necessidades da organização. A atividade de planejamento implica inicialmente na caracterização do ambiente no qual será implantado o programa de medição, bem como a identificação de objetivos (KETTELERIJ, 2006).

Além da coleta destas informações, a fase de planejamento visa ainda

à preparação e motivação das pessoas envolvidas no programa de medição (SOLINGEN; BERGHOUT, 1999). A comunicação adequada também é uma boa prática em um processo desta natureza.

Um resultado importante da fase de planejamento é o plano do projeto, pois documenta procedimentos, cronogramas e objetivos do programa de medição, além de servir como base para a promoção de melhorias. Entre outras informações, o plano do projeto pode conter o planejamento para capacitação dos envolvidos (SOLINGEN; BERGHOUT, 1999).

A fase de planejamento consiste em estabelecer a equipe GQM, selecionar a área de melhoria, selecionar o projeto e estabelecer a equipe do projeto, criar o plano do projeto e realizar capacitação. A equipe GQM deve (SOLINGEN; BERGHOUT, 1999):

148


• ser independente da equipe do projeto e não ter interesse nos resultados de medição;

• possuir conhecimento prévio suficiente sobre os objetos de medição;• ter em mente que a equipe do projeto é proprietária do programa de melhoria,

pois uma equipe de projeto é mais gerenciável em um projeto;• ser orientada à melhoria, incluindo a disposição para melhoria;• ser entusiasta, de forma a motivar a equipe do projeto.

É importante que tanto a equipe de medição quanto a equipe do projeto estejam dispostos a obter os resultados mais precisos e fidedignos possíveis. O comprometimento dos envolvidos deve ser alto, de modo que as medições realizadas, sejam positivas ou negativas, sejam utilizadas para identificação das causas dos valores obtidos. As principais atividades da equipe GQM são (SOLINGEN; BERGHOUT, 1999):

• planejar programas de medição em projetos de desenvolvimento;• prezar pelas atividades de definição de medidas e desenvolver os resultados

do GQM;• verificar a coleta de dados com a equipe do projeto e dados de processos

disponíveis;• preparar a interpretação dos dados de medição através de sessões de feedback;• participar como moderador nas sessões de feedback;• apresentar o progresso à equipe do projeto e de gerenciamento, disseminar e

organizar os resultados.

Em parte, o nível de sucesso de um programa de medição está diretamente relacionado com as habilidades pessoais dos membros da equipe de medição. A principal habilidade pessoal que a equipe de medição deve possuir é a capacidade de motivar as demais pessoas envolvidas (SOLINGEN; BERGHOUT, 1999).

Além disso, é desejável que os membros da equipe de medição tenham boa reputação, permitindo que haja confiança no trabalho realizado, bem como nos resultados obtidos. Uma vez montada a equipe de medição, o próximo passo no processo é a identificação e seleção de produtos ou áreas de processo para melhoria. Exemplos incluem (SOLINGEN; BERGHOUT, 1999):

• problemas com os quais a organização esteja lidando;• áreas de processos identificadas como carentes de avaliação;• áreas de melhorias de produtos com base em objetivos estratégicos de negócio.

As melhorias realizadas, em geral, são refinamentos operacionais de objetivos de melhoria estratégicos da organização. Tais objetivos de melhoria em boa parte das vezes são traduzidos no nível de refinamento operacional em quatro aspectos básicos como custo, tempo, risco e qualidade (SOLINGEN; BERGHOUT, 1999).


149

A atividade de definição das atividades operacionais que atenderão aos objetivos estratégicos do negócio não é uma atividade trivial. Para auxiliar os profissionais que precisam realizar a definição de medições relacionadas a software, foi disponibilizado pelo SEI (Software Engineering Institute) um manual denominado "Goal-Driven Software Measurement – A Guidebook" (PARK; GOETHERT; FLORAC, 1996).

O propósito deste manual é mostrar como identificar e definir medições de software de forma a atender aos objetivos estratégicos da organização. O processo apresentado permite produzir medições de forma a elucidar as questões de gerenciamento mais importantes para o negócio, possuindo rastreabilidade com os objetivos de negócio (PARK; GOETHERT; FLORAC, 1996).

Além do uso do manual disponibilizado pelo SEI, a identificação de áreas que necessitam de melhoria, pode ser realizada através de avaliações ou revisões da organização de desenvolvimento de software de forma a obter evidências das práticas utilizadas e identificar os principais problemas existentes. Uma vez identificadas as área que necessitam de implementações de melhorias, os seguintes detalhes devem ser descritos (SOLINGEN; BERGHOUT, 1999):• área com problema ou necessidade de melhoria;• processos ou produtos relacionados/envolvidos;• influências organizacionais, tecnológicas, de ambiente e legais;• pessoas envolvidas;• experiência das pessoas envolvidas com medição e GQM.

Esta caracterização pode ser realizada através de questionários ou formulários preparados especificamente para obtenção deste conjunto de dados. Tal caracterização é utilizada como base para as fases seguintes do método GQM (KOCHANSKI, 2009).

É recomendado que os questionários sejam realizados em duas sessões. A primeira sessão deve conter questões genéricas que possam ser respondidas por todos os envolvidos. A segunda sessão deve conter apenas questões específicas ao contexto de cada respondente (KETTELERIJ, 2006).

Após definida a equipe de medição e selecionada a área na qual serão implementadas as melhorias é necessário selecionar um projeto e definir a equipe do projeto. A definição da equipe do projeto deve levar em consideração o fato de que os seus membros realizarão as atividades de medição, além de adotarem o processo definido (KOCHANSKI, 2009).

Tais pessoas devem estar comprometidas e motivadas com as atividades que desempenharão. O alinhamento dos objetivos de medição com as ideias da equipe do projeto também permitem facilitar a implantação do programa de medição. A ideia é que a equipe do projeto seja a proprietária do programa de medição e responsável pelos resultados obtidos (SOLINGEN; BERGHOUT, 1999).

150


O plano do projeto deve ser desenvolvido após terem sido efetuadas as definições descritas anteriormente. Este plano deve estar de acordo com a abordagem definida e possuir (SOLINGEN; BERGHOUT, 1999):

• resumo do programa de medição;• escopo do programa de medição;• relacionamento entre os objetivos de melhoria e os objetivos do projeto de

desenvolvimento de software;• descrição dos resultados esperados;• cronograma de atividades;• lista de resultados;• alocação de recursos;• análise custo/benefício;• descrição da organização da equipe de medição e do projeto;• descrição do processo de gerenciamento;• plano de treinamento da equipe;• forma como os resultados serão divulgados.

Dentre os itens relacionados anteriormente existem dois que contribuirão de maneira relevante para a aceitação do projeto pela organização. O primeiro deles é a análise custo/benefício, pois possui o esforço necessário pelas equipes envolvidas e os benefícios que serão obtidos a partir da sua realização (KOCHANSKI, 2009).

O segundo é um planejamento realístico do programa de medição, contemplando todas as fases e atividades necessárias no cronograma. Uma forma apontada por Solingen e Berghout (1999) para manter a equipe de medição e do projeto motivada e comprometida é através da organização regular de treinamentos e sessões de promoção nas quais são apresentadas:

• a definição clara dos objetivos de melhoria propostos;• os benefícios de um programa de medição;• os impactos das medições nas atividades de desenvolvimento diárias;• a discussão das experiências de outras organizações e projetos.

Além da importância da participação de todos os membros das equipes do projeto e da equipe de medição, também é importante a participação dos responsáveis pelo gerenciamento das equipes envolvidas e de representantes da alta administração (KOCHANSKI, 2009).

A equipe de medição deve receber sessões de treinamento que envolva o

princípio de medição, explanação do método GQM e detalhamento do método GQM. As sessões de treinamento realizadas para a equipe de medição não devem ficar focadas apenas em questões teóricas, mas também prover respostas para perguntas como (SOLINGEN; BERGHOUT, 1999):


151

• quais atividades de medição devem ser realizadas?• por que tais atividades devem ser realizadas?• como e quando tais tarefas devem ser realizadas?• quanto esforço é necessário para realizar as atividades?• as atividades de medição influenciarão as demais atividades diárias?• quais serão os benefícios das atividades de medição?• o que será aprendido com as atividades de medição?

Não há necessidade de responder a todas as perguntas numa única sessão, pois se pode responder uma parte delas, além de outras perguntas em diversas sessões, de forma que a motivação da equipe possa ser gerenciada. O que deve ser feito antes de iniciar as atividades do projeto é a realização do treinamento mínimo necessário para que cada envolvido possa realizar suas atividades (KOCHANSKI, 2009).

Definição Na fase de definição de um programa de medição baseado em GQM deve

ser desenvolvido o plano GQM, o plano de medição e o plano de análise. Estes três planos possuem todas as informações pertinentes ao programa de medição (KOCHANSKI, 2009).

Solingen e Berghout (1999) definiram um processo com onze passos para a realização completa da fase de definição de um programa de medição baseado em GQM. Os onze passos são:

• definir os objetivos de medição;• rever ou produzir um modelo de processo de software;• conduzir entrevistas GQM;• definir perguntas e hipóteses;• revisar perguntas e hipóteses;• definir métricas;• verificar a consistência e completude das métricas;• produzir o plano GQM;• produzir o plano de medição;• produzir o plano de análise• revisar os planos.

Na definição de objetivos de medição é realizada a definição formal dos objetivos de medição os quais são derivados dos objetivos de melhoria identificados na fase de planejamento e foram descritos no plano do projeto.

Na definição dos objetivos de medição devem participar todas as pessoas envolvidas no programa de medição. Os objetivos de medição devem ser definidos de forma compreensível e claramente estruturada.

152


Um modelo para tal definição foi proposto por Basili, Caldiera e Rombach (1994) o qual especifica o objeto, propósito, enfoque, ponto de vista e contexto. A utilização e relevância de tal modelo ficam mais claras quando exemplificado: Analisar <objeto> com o propósito de <propósito> com relação ao seu (à sua) <enfoque da qualidade> do ponto de vista de <ponto de vista> e no contexto <contexto>.

Um exemplo preenchido do modelo seria (STAA, 2008): Analisar <procedimentos> com o objetivo de <determinar> o <efeito da complexidade sobre o número de falhas encontradas> do ponto de vista da <equipe de desenvolvimento> e no contexto de <programas desenvolvidos em linguagem C>. Através da utilização deste modelo, a definição de objetivos de medição é facilitada (KOCHANSKI, 2009).

FIGURA 26 – MODELO VISUAL DA DEFINIÇÃO DE OBJETIVOS

FONTE: Basili, Caldiera e Rombach (1994)

Conforme mencionado anteriormente, a definição de objetivos de medição deve estar alinhada com os objetivos estratégicos da organização (BASILI et al., 2007). A Figura X demonstra tal alinhamento num modelo visual.

Em determinadas situações pode não ser trivial a identificação dos objetivos de medição segundo os objetivos estratégicos da organização. Para facilitar a atividade de definição de objetivos de medição em tal situação, Solingen e Berghout (1999) propõem a utilização das seguintes sete perguntas:

• quais são os objetivos estratégicos em sua organização?• que forças têm impacto em seus objetivos estratégicos?• como você poderia melhorar o desempenho?• quais são seus principais problemas?


153

• quais são seus objetivos de melhoria?• como você pode alcançar seus objetivos de melhoria?• quais são possíveis objetivos de medição e qual é a prioridade dos mesmos?

A partir do momento em que há a definição dos objetivos de medição é necessário revisar ou produzir um modelo de processo de software. O conhecimento do modelo de processo de software é necessário para que possam ser definidos os pontos do processo em que serão realizadas as medições (KETTELERIJ, 2006).

Caso o modelo de processo de software em uso não esteja formalmente descrito é importante que o processo seja descrito tal qual é executado. Uma forma de obtenção de informações relevantes é a condução de entrevistas GQM (KOCHANSKI, 2009).

O objetivo de realizar estas entrevistas é explicitar o conhecimento implícito. O registro das informações obtidas em tais entrevistas pode ser registrado na forma de planilha, conhecida como abstraction sheet. A Figura a seguir apresenta um modelo de abstraction sheet preenchido.

FIGURA 27 – MODELO DE ABSTRACTION SHEET

Abstraction Sheet

Objetivo Projeto Monitorar Esforço, custo e cronograma Gerente de Projeto Principal projeto

da empresa

Enfoque da qualidade Fatores de variação

Q1. Fases em atrasoQ2. Variação no esforço por atividade (planejado x atual)Q3. Variação na produtividade (planejado x atual)Q4. Variação de cronograma (SPI)Q5. Variação de custo (CPI)Q6. Produtividade (planejado x atual)

V1. Quantidade de pedidos de mudança

Hipótese de baseline Impacto na hipótese de baseline

Apresentação Critério de decisão Q1 Q2 Q3 Q4 Q5 Q6

HQ1 Gráfico de Gant +/- 4 dias V1 X

HQ2 Gráfico de barras +/- 10%

HQ3 Gráfico de execução +/- 10%



HQ6 Valor +/- 10%

FONTE: O autor

154


Conforme pode ser observado no exemplo, as quatro seções de uma abstraction sheet são (SOLINGEN; BERGHOUT, 1999):

• Enfoque da qualidade: quais são as possíveis métricas para medir o objeto de um objetivo, de acordo com os membros do projeto?

• Hipótese de baseline: qual é o conhecimento atual dos membros em relação a estas métricas? As expectativas estão documentadas como hipóteses de baseline da métrica?

• Fatores de variação: que fatores se acredita que influenciarão na métrica?• Impacto na hipótese de baseline: como estes fatores de variação podem

influenciar as medições atuais? Que tipo de dependências entre as métricas e os fatores de influência é assumido?

A abstraction sheet é um ferramenta poderosa que pode ser utilizada durante o estabelecimento de um programa de medição de maneira que as informações obtidas nas entrevistas possam ser organizadas de forma estruturada e posteriormente copiadas da abstraction sheet para o plano GQM.

Além disso, a abstraction sheet pode ser utilizada para estruturar a apresentação e interpretação de dados de medição durante as sessões de feedback. A abstraction sheet também é conhecida como sendo um resumo do plano GQM (SOLINGEN; BERGHOUT, 1999).

A definição dos objetivos é realizada em nível abstrato, já as perguntas são refinamentos dos objetivos em um nível mais operacional, mais adequado para interpretações. Através das respostas às perguntas pode-se concluir se um objetivo está sendo atingido (KETTELERIJ, 2006).

Para que as respostas possam dar sustentação aos objetivos é necessário

que sejam realizadas verificações para garantir que as perguntas definidas possam fornecer as conclusões aos objetivos de forma satisfatória (SOLINGEN; BERGHOUT, 1999). A Figura a seguir representa graficamente a estrutura GQM.

FIGURA 28 – ESTRUTURA GQM

FONTE: Basili, Caldiera e Rombach (1994)


155

Na estrutura do GQM os objetivos estão no nível mais abstrato, as perguntas estão localizadas no nível intermediário e as métricas representam o nível concreto. Na estrutura GQM os objetivos estão no nível conhecido como conceitual, as perguntas no nível conhecido como operacional e as métricas no nível conhecido como quantitativo.

No nível conceitual é realizada a identificação de objetivos a serem atingidos em relação a produtos, processos ou recursos. No nível operacional são definidas as perguntas que ajudam a entender como atingir os objetivos.

Estas perguntas endereçam o contexto de qualidade de determinado ponto de vista. Já no nível quantitativo são definidas as métricas que identificam as medições necessárias para responder as perguntas (STAA, 2008). A figura a seguir demonstra graficamente tal hierarquia.

FIGURA 29 – EXEMPLO DE ESTRUTURA GQM

FONTE: Staa (2008)

A partir do momento que os objetivos estão refinados em uma lista de perguntas, podem ser definidas as métricas de modo a fornecer informação quantitativa para responder as perguntas de forma satisfatória (KETTELERIJ, 2006).

Uma vez definidas as métricas, a estrutura deve ser verificada para garantir que os objetivos, perguntas e métricas estejam consistentes e completas com relação ao objeto sob medição. As definições que fazem parte do programa

156


de medição são documentadas no plano GQM. O plano GQM serve como guia para a interpretação de dados e serve de base para o desenvolvimento do plano de medição e o plano de análise.

O último passo da fase de definição é a revisão dos planos estabelecidos com o objetivo de obter a concordância dos membros da equipe do projeto em relação aos objetivos, perguntas e métricas definidas, identificação de definições não estabelecidas ou desnecessárias e obter a concordância dos membros da equipe do projeto com as definições do material de feedback propostas (SOLINGEN; BERGHOUT, 1999).

Coleta de Dados

Na fase de coleta de dados são definidos os procedimentos de coleta de dados e correspondentes ferramentas para realizar o registro dos dados coletados. Os procedimentos de coleta de dados definem os aspectos que requerem atenção na atividade de coleta de dados. As atividades de coleta de dados estão descritas no plano de medição e dizem respeito aos seguintes aspectos relacionados à coleta de dados (SOLINGEN; BERGHOUT, 1999):

• para certa métrica, qual pessoa deve coletar o dado?• quando o dado deve ser coletado?• como o dado pode ser coletado de maneira mais eficiente e efetiva?• para quem os dados coletados devem ser entregues?

QUADRO 6 – EXEMPLO DE PROCEDIMENTO DE COLETA DE DADOS

Procedimento de Coleta de Dados

Ident. do procedimento de coleta de

dados

Referência da medida Coletar dados Armazenar os dados coletados

Ident. da medida

baseMedida base Quando? Como? Quem? Quando? Como? Quem?

PCD MB1.1

Projeto: atividades

realizadas até determinada

data

Final da atividade

MSProject / campo % trabalho

concluído

Executor SemanalRelatório

do MSProject

Gerente do Projeto

MB1.2

Projeto / Atividade:

esforço planejado

Final do (re-) planejamento

do projeto

MSProject campo

duração

Gerente do

Projeto

Final do (re-) planejamento

do projeto

Relatório do

MSProject

Gerente do Projeto

FONTE: O autor


157

Os demais elementos que fornecem suporte para o processo de coleta de dados devem ser desenvolvidos em grande parte com base nas respostas das perguntas anteriormente elencadas. A coleta de dados pode ser realizada com base em formulários impressos, formulários eletrônicos ou utilizar ferramentas automatizadas.

É importante não limitar as possibilidades de coleta de dados apenas pelo fato de realizar a coleta de dados de forma automatizada. Em diversos casos é mais eficiente utilizar a coleta de dados manual, mas ter o conjunto de dados necessários para tomada de decisão de melhoria de processo do que automatizar a coleta, mas ficar limitado em termos de tipos de dados coletados.

A ideia básica que rege tal questão é a de que os dados valiosos são obtidos através das pessoas e não de ferramentas automatizadas (SOLINGEN; BERGHOUT, 1999). O quadro a seguir apresenta um exemplo de definição de procedimento de coleta de dados.

Antes de iniciar a coleta de dados realizada por pessoas é necessário treiná-las para a atividade. Este treinamento pode ser realizado através de pequenos pilotos ou simulações para que as pessoas possam entender os procedimentos e realizar as atividades de forma correta.

Após o treinamento e iniciado o processo de coleta de dados reais do projeto é aconselhável que se estabeleça um período experimental, de modo que as pessoas envolvidas possam compreender os procedimentos de forma definitiva.

Os dados coletados devem ser armazenados de forma que possam ser recuperados sempre que necessário. É recomendado que o procedimento de coleta de dados seja mantido o mais simples possível (KETTELERIJ, 2006).

QUADRO 7 – EXEMPLO DE DADOS COLETADOS

Definição do escopo do Projeto

Membro da equipe Data de início Data de término Esforço (h/h)

Roger Gilmour 13/08/2010 28/08/2010 96

FONTE: O autor

Após a coleta dos dados é necessário verificar se os dados coletados refletem a realidade, ou seja, é necessário verificar se é possível confiar nos dados coletados para posterior interpretação e tomada de decisão com base nos mesmos. Esta atividade é denominada de análise dos dados.

158


A figura a seguir apresenta um exemplo de conjunto de dados coletados em formato adequado para análise. A análise dos dados é uma espécie de verificação para garantir que os dados foram corretamente coletados. A partir do momento que os dados foram coletados, analisados e armazenados, pode-se proceder a interpretação para obtenção de informações relevantes ao programa de medição.

Interpretação

A fase de interpretação é considerada uma fase muito importante pelo fato de que é nesta fase que se espera encontrar respostas para as perguntas sobre as quais foi definido o programa de medição.

O principal objetivo desta fase é obter conclusões em relação ao programa de medição. É certo que tais conclusões são particulares para cada programa de medição, pois são baseadas nas necessidades de medição relativa à situação de cada organização (SOLINGEN; BERGHOUT, 1999).

FIGURA 30 – EXEMPLO DE APRESENTAÇÃO DE RESULTADO DE MEDIÇÃO

FONTE: O autor

Antes que os dados sejam interpretados pelos envolvidos na atividade é necessário organizar de forma prévia o que será apresentado na reunião de feedback. Esta preparação diz respeito a processar os dados coletados e colocá-los num formato de apresentação de fácil interpretação. O formato de apresentação deve ser o mais simples possível (KETTELERIJ, 2006). A figura a seguir apresenta um exemplo de representação de resultado de medição denominado curva S.


159

FIGURA 30 – EXEMPLO DE APRESENTAÇÃO DE RESULTADO DE MEDIÇÃO

A ideia da reunião de feedback é reunir todos os membros da equipe de medição e equipe do projeto e discutir os resultados obtidos. Na reunião de feedback, além de analisar os resultados do último período deve-se avaliar os resultados das ações realizadas desde a última reunião, interpretação dos dados de medição em relação às perguntas e objetivos definidos no plano GQM e traduzir a interpretação em conclusões e planos de ação (KOCHANSKI, 2009).

Uma vez realizada a reunião de feedback, a equipe GQM realiza o registro da reunião em ata contendo as observações relevantes, interpretações, conclusões e planos de ação definidos. Tal ata deve ser publicada para toda a equipe envolvida. Uma vez completo o primeiro ciclo, os ciclos seguintes são baseados na retroalimentação do ciclo anterior, promovendo assim um ciclo de melhoria contínua (KOCHANSKI, 2009).

3 MODELO PSM

O PSM – Practical Software and Systems Measurement é uma abordagem que descreve um processo de medição orientado por informações que tratam dos objetivos técnicos e de negócios de uma organização (PSM, 2003).

O desenvolvimento do PSM é patrocinado pelo Departamento de Defesa dos EUA (DoD) e US Army. O desenvolvimento do PSM tem sido baseado em experiências práticas de medição realizadas pelo DoD, governo americano e indústria (PSM, 2003).

O PSM foi utilizado como modelo de referência para o padrão ISO 15939, o qual foi utilizado como base para a definição da área de processos (PA – Process Area) do CMMI (KETTELERIJ, 2006).

A documentação do PSM possui a descrição de como realizar a definição e execução de um programa de medição de forma a atender as necessidades de informação das organizações que adquirem e fornecem softwares e sistemas (PSM, 2003).

O principal foco do PSM está voltado para o nível de projetos, apresentando uma abordagem para a definição e implementação eficaz de um processo de medição para projetos de software e de sistemas. O PSM tem como objetivo prover aos gerentes de projeto e gerentes técnicos informações quantitativas necessárias para a tomada de decisões que possam afetar o cronograma e custo do projeto, bem como os objetivos de desempenho técnico (KOCHANSKI, 2009).

Embora a abordagem PSM esteja com o foco em nível de projeto, o processo de medição baseado em informações pode ser estendido para o tratamento de requisitos de medição em nível de organização (PSM, 2003).

160


Um detalhe relevante a ser destacado é que a abordagem GQM é orientada a objetivos e a abordagem do PSM está orientada ao fornecimento de informações. A implementação de um programa de medição que inclua o PSM envolve a definição da necessidade de informações da organização e dos projetos e então selecionar as medições que forneçam as informações que atendam a tais necessidades (KETTELERIJ, 2006).

A medição no PSM é descrita como um processo sistemático, mas flexível, podendo ser adaptado para satisfazer necessidades de informação e características específicas de cada projeto. As medições podem ser selecionadas das seguintes categorias (KETTELERIJ, 2006): cronograma e progresso, recursos e custos, estabilidade e tamanho do produto, qualidade do produto, desempenho do processo, efetividade tecnológica e satisfação do usuário.

A abordagem PSM possui um processo para seleção das medições apropriadas com base em questões e objetivos relevantes a um projeto de desenvolvimento de software (BASILI et al., 2007).

FIGURA 31 – O PROCESSO DE MEDIÇÃO PSM

FONTE: PSM (2003)


161

A Figura anterior demonstra que a abordagem PSM define as atividades de medição de adaptação de medidas, aplicação de medidas, implementação do processo e avaliação da medição. As atividades de adaptação de medidas e aplicação de medidas formam o centro do processo de medição que fornecem informações diretamente aos responsáveis pela tomada de decisões (KOCHANSKI, 2009).

A atividade de implementação do processo envolve as atividades que estabelecem o processo de medição dentro de uma organização. Na atividade de avaliação da medição são identificadas as tarefas de avaliação e melhoria que servirão para todo o programa de medição (PSM, 2003).

O processo de medição deve estar integrado aos demais processos que fazem parte do ciclo de vida dos projetos de software e de sistemas. Em situações em que os processos do ciclo de vida são dinâmicos o processo de medição deve acompanhar o dinamismo das mudanças e adaptações ao projeto.

Estas atividades de adaptação e aplicação de medidas são iterativas durante todo o ciclo de vida do projeto. As questões, medidas e técnicas de análise podem mudar com o passar do tempo com objetivo de atender as necessidades do projeto sendo executado (KOCHANSKI, 2009).

No momento de estabelecer um programa de medição é fundamental que estes modelos sejam considerados, pois o processo de definição de indicadores é crítico para obtenção de sucesso na gestão da qualidade de software. A definição correta de indicadores é um importante passo.

162



FATORES HUMANOS DE QUALIDADE

Práticas de organizações maduras

Uma empresa não precisa sempre recorrer á inventividade para resolver problemas: a maioria das dificuldades que ela enfrenta é recorrente. É possível buscar soluções na experiência já desenvolvida para outras organizações. As seções a seguir comentam algumas práticas positivas, que atendem às situações mais comuns.

Interação com o cliente

Um dos maiores fatores de fracasso em projetos de desenvolvimento de sistemas é constante alteração dos requisitos e do escopo.

O fato é que tais alterações são inevitáveis: dificilmente é possível especificar todos os requerimentos de um projeto e mantê-los até a conclusão. As alterações são importantes para que o produto final realmente esteja de acordo com o desejado pelo cliente.

Assim, o problema não é a mudança em si, mas a forma como os

desenvolvedores e os stakeholders lidam com ela. Idealmente as duas partes devem ceder. Os desenvolvedores precisam entender que é necessário atender às mudanças de requisitos, apenas do trabalho adicional que elas ocasionam, em contrapartida, os clientes precisam assumir os riscos que as alterações nos requisitos acarretam, como atrasos no prazo e aumento dos custos.

Organizações maduras veem o cliente como um parceiro com um interesse como: o sucesso do projeto. Existe a consciência de que é preciso manter transparência ao discutir os prazos, o custo e a qualidade do projeto. Toda não conformidade com o planejado é comunicada ao cliente e este é incentivado a se comunicar com os desenvolvedores.

A assinatura de contratos é uma formalidade de necessária, porém manter um diálogo constante entre partes pode ser ainda importante. Obviamente, não é possível que existam apenas negociações informais entre clientes e desenvolvedores, mas trata-se de um mecanismo útil na resolução de conflitos. Organizações maduras entendem a importância de contratos bem definidos, mas procuram envolver ao máximo o usuário na sua escrita e estão preparadas para tratar situações imprevistas.


163

Gerenciamento de projetos

Organizações maduras fazem planos de projetos realísticos e honestos. Propor custos ou prazos reduzidos, porém inviáveis, é uma estratégia adotada por alguns para, por exemplo, ganhar concorrência. Além de desleal, tal prática é realmente desastrosa. As consequências frequentes são projetos de baixa qualidade – perdendo-se a confiança do cliente – e desenvolvedores pressionados e muito exigidos. Perde-se também o espirito de trabalho em equipe.

Para fazer planos realísticos, as organizações maduras analisam e gerenciam os riscos continuamente. Buscam métricas mais precisas para calcular os prazos e os custos dos projetos anteriores serve para a definição dos parâmetros dos projetos atuais e é sempre realimentada com novos resultados obtidos. O aprendizado com projetos anteriores favorece a repetição de sucessos e reduz possibilidades de fracasso.

Métricas

Organizações maduras alimentam suas bases de dados de projetos anteriores constantemente. Durante os projetos, métricas são empregadas auxiliando a definição de tarefas e a alocação de recursos.

Podem ser empregadas medidas para conhecer o desempenho individual e de toda a equipe, o que permite estimativas mais seguras de recursos alocados a projetos. A aplicação de relatórios de emprego de tempo, por exemplo, possibilita derivar, identificar o desempenho individual e da equipe e estimar a duração de atividades em projetos futuros.

O fato de o trabalho ser constantemente avaliado pode levar os desenvolvedores ao receio de serem penalizados. Essa reação ocorre se não houver um feedback positivo de gerente de projeto. O proposito da coleta de dados não deve ser punir erros, mas aprimorar estimativas de prazos e sustos melhorando o gerenciamento dos projetos. Além disso, as informações obtidas servem para identificar necessidades de treinamentos, inclusive ajudando em sua justificativa aos níveis superiores da organização.

Para que tais objetivos sejam alcançados, é fundamental que os

desenvolvedores forçarem dados realistas, evitando altera-los para justificar suas dificuldades. Essa confiança somente é obtida em organizações em que existe feedback constante entre subordinados e superiores e onde honestidade é considerada um valor importante.

Treinamento e coaching

Organizações maduras possuem treinamentos formais para novos contratados e programas como reciclagem para pessoal mais antigo.

164


Um dos objetivos dos treinamentos para novos contratados é apresentá-los aos padrões utilizados pela empresa no desenvolvimento de software. Isso permite que os processos seguidos pela organização o amis rápido possível. Garante-se, assim, a padronização dos métodos de trabalho.

Os funcionários mais antigos sentem-se mais valorizados quando há incentivos em sua formação continua. Além disso, podem ser necessários novos projetos e emprego de processos, linguagens ou ferramentas que são conhecidos pela equipe. Se for possível treinar o pessoal disponível em vez de contratar novos funcionários, é possível que se consiga reduzir custos de desenvolvimento.

Para guiar a carreira dos funcionários nos que diz a respeito a novos treinamentos, direcionamento de novos projetos ou apenas fornecendo feedback para suas questões, algumas empresas utilizam o coaching: funcionários mais experientes monitoram e auxiliam o desenvolvimento da carreira dos maiores novos.

Revisões dos pares

A seção Individualismo comentou as razões por que é difícil para um desenvolvedor encontrar defeitos nos resultados de seu próprio trabalho. Uma maneira simples de contornar o problema é encarregar outra pessoa de realizar uma revisão.

Organizações maduras utilizam uma prática chamada de revisões por pares. Cada artefato do projeto produzido por um membro da equipe passa pela revisão de outro funcionário. Tais artefatos incluem, por exemplo, documentos de requisitos, diagramas de análises ou, ainda, trechos de códigos.

Esta prática é eficaz para encontrar erros e não conformidades com os padrões estabelecidos, mas deve ser conduzida corretamente, de forma a evitar conflitos entre equipe e funcionários. A administração de tais revisões desse estar a cargo de gerentes experientes, preocupados em evitar atritos. Os participantes precisam entender que se está julgando os resultados do trabalho e não a pessoa que a executou.

FONTE: KOSCIANSKI, André; SOARES, Michel dos Santos. Qualidade de software: aprenda as metodologias e técnicas mais modernas para o desenvolvimento de software. São Paulo: Novatec Editora, 2007, p. 87-89.

165

Caro acadêmico! Nesse capítulo, você estudou que:

• Medição é o processo de atribuição de valor a entidades no mundo real. É através da medição que são obtidos os valores das medidas.

• A medida é um parâmetro de quantificação atribuído a um produto ou processo. Este parâmetro pode ser uma quantidade, dimensão, capacidade, extensão ou tamanho.

• O GQM é uma abordagem que visa integrar os objetivos de medição com as necessidades do processo de software.

• O PSM é uma abordagem que visa descrever um processo de medição apoiado pelos objetivos técnicos e de negócios.

RESUMO DO TÓPICO 2

166

AUTOATIVIDADE

Caro acadêmico! Como forma de fixar o conteúdo estudado realize a autoatividade proposta a seguir:

1 O que é medição de software?

2 O que significa GQM?

3 Quais são as fases de um programa de medição baseado em GQM?

4 Em que nível está o foco do PSM?

167

REFERÊNCIAS

ALMEIDA, Marcus Garcia de. Fundamentos de informática. Rio de Janeiro: Brasport, 2002.

ARAUJO, Luis César G. de; GARCIA, Adriana Amadeu; MARTINES, Simone. Gestão de processos: melhores resultados e excelência organizacional. São Paulo: Atlas, 2011.

BARTIÈ, Alexandre. Garantia da qualidade de software: adquirindo maturidade organizacional. Rio de Janeiro: Campus, 2002.

BASS, L. et al. Software architecture in practice. Cap. 10. Reading MA: Addison Wesley, 1998.

BASILI, Victor R.; WEISS, David M. A methodology for collectin valid software engineering data. IEEE Transactions on Software Engineering. v. SE-10, n. 6, 1984.

BASILI, Victor R.; CALDIERA, Gianluigi; ROMBACH, H. Dieter. Goal question metric paradigm. In: MARCINIAK, John J. Encyclopedia of Software Engineering. John Wiley & Sons: 1994. v. 1, p. 528-532.

BASILI, Victor; HEIDRICH, Jens; LINDVALL, Mikael; MÜNCH, Jürgen; REGARDIE, Myrna; ROMBACH, Dieter; SEAMAN, Carolyn; TRENDOWICZ, Adam. Bridging the gap between business strategy and software development. ICIS, 2007. Proceedings. Dusseldorf. Germany. April, 2007.

BOEHM, Barry W. A spiral model of software development and enhancement. IEEE, 1988.

BRIAND, Lionel C.; DIFFERDING, Christiane M.; ROMBACH, H. Dieter. Practical guidelines for measurement-based process improvement. Software Process Improvement and Practice. v. 2, 1997.

BROOKS, Frederick Phillips. O mítico homem-mês: ensaios sobre engenharia de software. Rio de Janeiro: Elsevier, 2009.

CARVALHO, Ariadne Maria Brito Rizzoni; CHIOSSI, Thelma Cecília dos Santos. Introdução à Engenharia de Software. Campinas: Editora Unicamp, 2001.

CHAN, Janis Fisher. Communication skills for managers. Fifth edition. AMACOM, 2002.

168

COATES, Dennis E. People skills training: are you getting a return on your investment? Performance Support Systems, Inc., 2006.

CROSBY, P. B. Quality is free: the art of making quality certain. New York: McGraw-Hill, 1979.

CMMI Product Development Team. CMMI for development, version 1.2. Pittsburgh: Software Engineering Institute, Carnegie Mellon University, 2006. Disponível em: <http://www.sei.cmu.edu/pub/documents/06.reports/pdf/06tr008.pdf>. Acesso em: 12 nov. 2007.

DEMARCO, Tom. Controle de projetos de software: gerenciamento, avaliação, estimativa. Rio de Janeiro: Campus, 1991.

DEMING, W. E. Out of the crisis: quality, productivity and competitive position. Cambridge University Press, 1988.

FEIGENBAUM, A. V. Total quality control. McGraw-Hill, 1983.

FENTON, Norman E.; PFLEEGER, Shari Lawrence. Software metrics: a rigorous and practical approach. 2. ed. Boston: PWS, 1997.

FOROUZAN, Behrouz; MOSHARRAF, Firouz. Fundamentos da ciência da computação. São Paulo: Cengage Learning, 2011.

FUKUDA, K. Iro no namae (The name of colors). Tóquio: Shufuno-tomo, 1994.

GHEZZI, Carlo; JAZAYERI, Mehdi; MANDRIOLI, Dino. Fundamentals of software engineering. 2nd ed. New Jersey: Pearson Education, 2003.

GRESSE, Christiane; HOISL, Barbara; WÜST, Jürgen. A process model for GQM - based measurement. Technical Report STTI-95-04-E, Software Technology Transfer Initiative, Department of Computer Science, University of Kaiserslautern. Kaiserslautern, 1995.

IEEE – Institute of Electrical and Electronic Engineers. SWEBOK: Guide to the Software Engineering Body of Knowledge. Los Alamitos, California, 2004.

ISHIKAWA, K. What is total quality control?: the Japanese way. Prentice-Hall, 1985.

ISO/IEC – International Organization for Standardization and International Electrotechnical Commission. ISO/IEC 15939 Software engineering – Software measurement process. 2002.

169

ISO/IEC – International Organization for Standardization and International Electrotechnical Commission. ISO/IEC TR 15504 Information technology – Software process assessment – Part 1: Concepts and vocabulary, Part 2: Performing an assessment, Part 3: Guidance on performing an assessment, Part 4: Guidance on use for process improvement and process capability determination, Part 5: An exemplar process assessment model. 2003-2006.

IYER, Rukmini. 6 ‘soft’ skills you need for success. Disponível em: <http://www.rediff.com/getahead/2005/jun/30soft.htm>. Acesso em: 12 jul. 2009.

JURAN, J. M. Juran´s quality control handbook. McGraw-Hill, 1988.

KERZNER, Harold. Gerenciamento de projetos: uma abordagem sistêmica para planejamento, programação e controle. São Paulo: Editora Blucher, 2011.

_________. Gestão de Projetos: as melhores práticas. Porto Alegre: Bookman, 2002.

KETTELERIJ, Richard. Designing a measurement programme for software development projects. Master’s Thesis. Faculty of Science. University of Amsterdam. The Netherlands, 2006.

KOCHANSKI, Djone. Um framework para apoiar a construção de experimentos na avaliação empírica de jogos educacionais. 2009. 224f. Dissertação (Mestrado em Computação Aplicada) – Universidade do Vale do Itajaí, São José, 2009.

KOSCIANSKI, André; SOARES, Michel dos Santos. Qualidade de software: aprenda as metodologias e técnicas mais modernas para o desenvolvimento de software. São Paulo: Novatec, 2007.

MAFFEO, Bruno. Engenharia de software e especificação de sistemas. Rio de Janeiro: Campus, 1992.

MANDL-STRIEGNITZ, Patricia. How to successfully use software project simulation for educating software project managers. Proc. 31st Frontiers in Education Conference. IEEE, 2001, p. 19-24.

MARCUS, A. Human communications issues in advanced user interfaces. Communications of the ACM, v. 36, n. 4, p. 101 – 109. Abr, 1993.

MCT – Ministério de Ciência e Tecnologia, Secretaria de Política de Informática. Qualificação CMM e CMMI no Brasil. 2006. Disponível em: <http://www.mct.gov.br/index.php/content/view/13885.html>. Acesso em: 12 nov. 2007.

170

MICHLMAYR, Martin. Software process maturity and the success of free software projects. Department of Computer Science and Software Engineering. University of Melbourne. Disponível em: <www.cyrius.com/publications/michlmayr-process_maturity_success.pdf>. Acesso em: 14 mar. 2008.

NEWTON, Rischard. O gestor de projetos. São Paulo: Pearson Prentice Hall, 2011.

PARK, Robert E.; GOETHERT, Wolfhart B.; FLORAC, William A. Goal-Driven software measurement – A Guidebook (CMU/SEI-96-HB-002, ADA313946). Pittsburgh, Pa.: Software Engineering Institute, Carnegie Mellon University, 1996.

PETERS, James F.; PEDRYCS, Witold. Engenharia de software. Rio de Janeiro: Campus, 2001.

PFAHL, Dietmar; KLEMM, Marco; RUHE, Günther. Using system dynamics simulation models for software project management education and training. Software Process Simulation Modeling Workshop (ProSim2000), London, 2000.

PFLEEGER, Shari Lawrence. Engenharia de software: teoria e prática. 2 ed. São Paulo: Prentice Hall, 2004.

PINTO, J. K.; SLEVIN, D. P. Critical factors in successful project implementation. IEEE Transactions on Engineering Management, 34, 1987, p. 22-27.

PMI - Project Management Institute. Um guia do conjunto de conhecimentos do gerenciamento de projetos (PMBOK® Guide) – 4ª. Edição, Official Portuguese Translation, Paperback. Editora Project Management Institute, 2008.

PRESSMAN, Roger S. Engenharia de software. São Paulo: Makron Books, 1995.

PSM – Practical Software and Systems Measurement. Practical software and systems measurement: a foundation for objective project management, Version 4.0c. 2003. Disponível em: <http://www.psmsc.com>. Acesso em: 25 jan. 2008.

REZENDE, Denis Alcides. Engenharia de software empresarial. Rio de Janeiro: Brasport, 1997.

ROCKENBACH, Renato. FWMetric: framework para métricas. 2003. 98 f. Dissertação (Mestrado em Ciência da Computação) – Programa de Pós-Graduação em Ciência da Computação, Universidade Federal de Santa Catarina, Florianópolis, 2003.

ROYCE, Winston W. Managing the development of large software systems. Proceedings of IEEE WESCON, August. IEEE, 1970, p. 1-9.

171

SAAD, Alfredo C. Terceirização de serviços de tecnologia da informação. Rio de Janeiro: Brasport, 2006.

SEI – Software Engineering Institute. Capability maturity model integration. Version 1.2. Pittsburgh: Software Engineering Institute, Carnegie Mellon University, 2007. Disponível em: <http://www.sei.cmu.edu/cmmi>. Acesso em: 10 mar. 2008.

SHAW, Mary; GARLAN, David. Software architecture: perspectives on an emerging discipline. Upper Saddle River, NJ: Prentice Hall, 1996.

SHEWHART, Walter Andrew. Economic control of quality of manufactured product. New York: D. Van Nostrand Company, 1931.

SOFTEX. MPS.BR – Melhoria de Processo de software, Guia Geral, Versão 1.2. 2007. Disponível em: <http://www.softex.br/portal/mpsbr/_guias/MPS.BR_Guia_Geral_V1.2.pdf>. Acesso em: 25 mar. 2008.

SOLINGEN, Rini van; BERGHOUT, Egon. The Goal/question/metric method: a practical guide for quality improvement of software development. London: McGraw-Hill, 1999.

SOMMERVILLE, Ian. Engenharia de software. São Paulo: Pearson Addison Wesley, 2003.

STAA, Arndt von. GQM – Goal, question, metric. Laboratório de Engenharia de Software. Departamento de Informática. PUC-Rio, 2008.

STRATHERN, Paul. Turing e o computador em 90 minutos. Rio de Janeiro: Jorge Zahar Ed., 2000.

SWEBOK. Guide to the software engineering body of knowledge. P. Bourque and R. Dupuis (Eds.). IEEE Computer Society Press, 2004.

TITTEL, Ed. The Importance of soft skills. Disponível em: <http://www.itknowledgeexchange.com>. Acesso em: 15 dez. 2008.

WANGENHEIM, Christiane Gresse von. Utilização do GQM no desenvolvimento de software. Laboratório de Qualidade de Software, Instituto de Informática, Universidade do Vale do Rio dos Sinos. São Leopoldo, 2000.

WASSERMAN, Anthony I. Tool Integration in software engineering environments. In: F. Longe d., SOFTWARE ENGINEERING ENVIRONMENTS. p. 138-150. Berlin: Springer-Verlag, 1990.

172

YOURDON, Edward. Projetos virtualmente impossíveis: guia completo do desenvolvedor de software para sobreviver aos projetos virtualmente impossíveis. São Paulo: Makron Books, 1999.

_________. Ressurreição e ascensão dos analistas e dos programadores. São Paulo: Makron Books, 1997.

_________. Declínio e queda dos analistas e programadores. São Paulo: Makron Books, 1995.

engenharia de software - uniasselvi

Documents