modelagem de sistemas empresariais - uniasselvi

2016

ModelageM de SiSteMaS eMpreSariaiS

Prof. Neli Miglioli Sabadin

Copyright © UNIASSELVI 2016

Elaboração:

Prof. Neli Miglioli Sabadin

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.

003S113m Sabadin; Neli Miglioli

Modelagem de sistemas empresariais/ Neli Miglioli Sabadin: UNIASSELVI, 2016.191 p. : il

ISBN 978-85-7830-962-6

1. Sistemas.I. Centro Universitário Leonardo da Vinci.

Impresso por:

III

apreSentação

Prezado (a) acadêmico (a)

Bem-vindo à disciplina de Modelagem de Sistemas Empresariais. Através desta disciplina verificaremos como o caminho da modelagem se modificou nos últimos anos, para se adequar aos constantes progressos das linguagens de programação, dos sistemas operacionais, dos bancos de dados, regras de negócio cada vez mais complexas e paradigmas da programação que buscam cada vez mais agilidade.

Vale lembrar que um dos assuntos mais relevantes da modelagem é que ela tem o objetivo de permitir o entendimento do projeto a qualquer pessoa da equipe, seja por parte da solicitante ou da solicitada, e em qualquer ponto do processo. Como já diz o ditado popular, “uma imagem vale mais que mil palavras”.

Conheceremos na primeira unidade os modelos de processo de desenvolvimento tradicionais e os modelos evolucionários. Na sequência, na segunda unidade, verificaremos como é realizado o levantamento dos requisitos e as técnicas para essa atividade, além de entendermos como funcionam as equipes e as fases do desenvolvimento do projeto. Para finalizar, conheceremos a UML, bem como seus diagramas. E complementando os estudos, será apresentada uma atividade para consolidar os conhecimentos aprendidos na disciplina de Modelagem de Sistemas Gerenciais.

Aproveito a oportunidade para destacar a importância de desenvolver as autoatividades, lembrando que essas atividades NAO SÃO OPCIONAIS. Elas objetivam a fixação dos conceitos apresentados. Em caso de dúvida na realização das atividades, sugiro que você entre em contato com seu tutor externo ou com a tutoria da UNIASSELVI, não prosseguindo as atividades sem ter sanado todas as dúvidas que irão surgindo.

Bom estudo! Sucesso na sua trajetória acadêmica e profissional!

Neli Miglioli Sabadin

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!

UNI

VII

SuMário

UNIDADE 1 - INTRODUÇÃO AOS MODELOS DE PROCESSO TRADICIONAIS: MODELO CASCATA E INCREMENTAL E MODELOS EVOLUCIONÁRIOS: MODELO ESPIRAL E PROTOTIPAÇÃO ........................ 1

TÓPICO 1 - MODELOS DE CICLO DE VIDA .................................................................................. 31 INTRODUÇÃO ..................................................................................................................................... 32 MODELOS DE PROCESSOS PRESCRITIVOS OU TRADICIONAIS ..................................... 4 2.1 MODELO EM CASCATA ............................................................................................................... 4 2.1.1 Modelo Incremental ............................................................................................................... 7 2.1.2 Modelos de processo evolucionário .................................................................................... 9 2.1.3 Modelo Espiral ........................................................................................................................ 9 2.1.4 Prototipação ............................................................................................................................ 10RESUMO DO TÓPICO 1........................................................................................................................ 12AUTOATIVIDADE ................................................................................................................................. 13

TÓPICO 2 - INTRODUÇÃO A MODELAGEM ESTRUTURADA E MODELAGEM ORIENTADA A OBJETO .................................................................... 151 INTRODUÇÃO ..................................................................................................................................... 152 IMPORTÂNCIA DA MODELAGEM DE SISTEMAS .................................................................. 183 EVOLUÇÃO HISTÓRICA DA MODELAGEM ............................................................................. 20 3.1 MODELAGEM ESTRUTURADA ................................................................................................. 21 3.2 PARADIGMA DA ORIENTAÇÃO A OBJETO (OO) ................................................................. 23RESUMO DO TÓPICO 2........................................................................................................................ 26AUTOATIVIDADE ................................................................................................................................. 27

TÓPICO 3 - MÉTODO DE DESENVOLVIMENTO ÁGIL .............................................................. 291 INTRODUÇÃO ..................................................................................................................................... 292 PRECEITOS E PRINCÍPIOS ............................................................................................................... 31 2.1 FATORES HUMANOS ................................................................................................................... 32 2.2 METODOLOGIAS ÁGEIS DE DESENVOLVIMENTO DE SOFTWARE ................................ 33 2.2.1 Extreme Programming (programação extrema) XP .......................................................... 34 2.2.2 Desenvolvimento de Software Adaptativo (ASD)............................................................. 35 2.2.3 Scrum ....................................................................................................................................... 36 2.2.4 Método de Desenvolvimento de Sistemas Dinâmicos (DSDM) ...................................... 39 2.2.5 Crystal ...................................................................................................................................... 40 2.2.6 Desenvolvimento Dirigido a Funcionalidades (FDD) ...................................................... 40 2.2.7 Desenvolvimento de Software Enxuto (LSD) .................................................................... 41 2.2.8 Modelagem Ágil (AM) .......................................................................................................... 41 2.2.9 Processo Unificado Ágil (AUP) ............................................................................................ 42 2.2.10 Rational Unified Process (RUP) ......................................................................................... 42LEITURA COMPLEMENTAR ............................................................................................................... 45RESUMO DO TÓPICO 3........................................................................................................................ 59AUTOATIVIDADE ................................................................................................................................. 61

VIII

UNIDADE 2 - ENGENHARIA DE REQUISITOS E EQUIPE DE DESENVOLVIMENTO ...... 63

TÓPICO 1 - ENGENHARIA DE REQUISITOS ................................................................................. 651 INTRODUÇÃO ..................................................................................................................................... 652 ENGENHARIA DE REQUISITOS .................................................................................................... 65 2.1 DEFININDO OS REQUISITOS...................................................................................................... 68 2.1.1 Requisitos Funcionais ............................................................................................................ 68 2.1.2 Requisitos não funcionais ..................................................................................................... 69 2.2 CRITÉRIOS PARA VALIDAÇÃO E ACEITAÇÃO DE REQUISITOS ..................................... 71 2.3 PROBLEMAS ENCONTRADOS REFERENTES A REQUISITOS ............................................ 73 2.4 ESPECIFICAÇÃO DE REQUISITOS ............................................................................................ 74 2.4.1 Especificação em Linguagem Natural ................................................................................. 76 2.4.2 Especificação Estruturada ..................................................................................................... 77 2.4.3 Documento de requisito de software .................................................................................. 79 2.4.4 Gerenciamento de requisitos ................................................................................................ 82LEITURA COMPLEMENTAR ............................................................................................................... 83RESUMO DO TÓPICO 1........................................................................................................................ 86AUTOATIVIDADE ................................................................................................................................. 88

TÓPICO 2 - DESCOBERTA DE REQUISITOS .................................................................................. 911 INTRODUÇÃO ..................................................................................................................................... 912 TÉCNICAS DE LEVANTAMENTO .................................................................................................. 92 2.1 ENTREVISTA ................................................................................................................................... 93 2.1.1 Etnografia - Observação pessoal .......................................................................................... 94 2.1.2 Questionário ............................................................................................................................ 95 2.1.3 Brainstorming ........................................................................................................................... 96 2.1.4 JAD (Joint Application Design) ............................................................................................... 97RESUMO DO TÓPICO 2........................................................................................................................ 99AUTOATIVIDADE ................................................................................................................................. 100

TÓPICO 3 - DESENVOLVIMENTO E EQUIPE DE SOFTWARE ................................................... 1011 INTRODUÇÃO ..................................................................................................................................... 1012 FASES DO DESENVOLVIMENTO DE SISTEMAS ...................................................................... 101 2.1 ESTUDO DE VIABILIDADE ......................................................................................................... 102 2.1.1 Análise...................................................................................................................................... 103 2.1.2 Projeto ...................................................................................................................................... 104 2.1.3 Implementação ....................................................................................................................... 105 2.1.4 Implantação ............................................................................................................................. 105 2.2 GERENCIAMENTO DE PROJETOS ............................................................................................ 105 2.3 EQUIPE DE DESENVOLVIMENTO ............................................................................................. 107 2.3.1 Gerente ..................................................................................................................................... 108 2.3.2 Analistas .................................................................................................................................. 109 2.3.3 Projetistas ................................................................................................................................. 110 2.3.4 Arquitetos de software .......................................................................................................... 110 2.3.5 Programadores ....................................................................................................................... 112LEITURA COMPLEMENTAR ............................................................................................................... 113RESUMO DO TÓPICO 3........................................................................................................................ 116AUTOATIVIDADE ................................................................................................................................. 117

UNIDADE 3 - REVISÃO DE CONCEITOS DA UML, DIAGRAMAS DE VISÃO COMPORTAMENTAL E ESTRUTURAL E UM DETALHAMENTO NOS CASOS DE USO ................................................................................................... 119

IX

TÓPICO 1 - UML (UNIFIED MODELING LANGUAGE) .............................................................. 1211 INTRODUÇÃO ..................................................................................................................................... 1212 MODELO CONCEITUAL DA UML ................................................................................................. 121 2.1 BLOCOS DE CONSTRUÇÃO BÁSICOS DA UML .................................................................... 122 2.1.1 Itens estruturais ..................................................................................................................... 122 2.1.2 Itens comportamentais .......................................................................................................... 124 2.1.3 Itens de agrupamento ............................................................................................................ 125 2.1.4 Itens anotacionais ................................................................................................................... 125 2.2 RELACIONAMENTOS NA UML................................................................................................. 125RESUMO DO TÓPICO 1........................................................................................................................ 127AUTOATIVIDADE ................................................................................................................................. 128

TÓPICO 2 - DIAGRAMAS DA UML: DIAGRAMAS ESTRUTURAIS E COMPORTAMENTAIS ................................................................................................ 1291 INTRODUÇÃO ..................................................................................................................................... 1292 DIAGRAMAS ........................................................................................................................................ 129 2.1 DIAGRAMAS ESTRUTURAIS ...................................................................................................... 131 2.1.1 Diagrama de Objetos ............................................................................................................. 131 2.1.2 Diagrama de Estrutura Composta ....................................................................................... 132 2.1.3 Diagrama de Classes .............................................................................................................. 134 2.1.4 Diagrama de Pacotes .............................................................................................................. 135 2.2 DIAGRAMAS COMPORTAMENTAIS ........................................................................................ 136 2.2.1 Diagramas de atividade ........................................................................................................ 136 2.2.2 Diagramas de Caso de Uso ................................................................................................... 137 2.2.3 Diagrama de Transição de Estados...................................................................................... 138 2.3 DIAGRAMAS DE INTERAÇÃO ................................................................................................... 139 2.3.1 Diagrama de Sequência ......................................................................................................... 139 2.3.2 Diagrama de Temporização .................................................................................................. 140 2.3.3 Diagrama de Comunicação ................................................................................................... 140 2.3.4 Diagrama de Visão Geral de Interação ............................................................................... 141 2.4 DIAGRAMAS DE IMPLEMENTAÇÃO ....................................................................................... 142 2.4.1 Diagrama de Componentes .................................................................................................. 142 2.4.2 Diagrama de Implantação ..................................................................................................... 143RESUMO DO TÓPICO 2........................................................................................................................ 145AUTOATIVIDADE ................................................................................................................................. 147

TÓPICO 3 - MODELO DE CASO DE USO ........................................................................................ 1491 INTRODUÇÃO ..................................................................................................................................... 1492 CASO DE USO ...................................................................................................................................... 1503 ATORES .................................................................................................................................................. 1504 FLUXO DE EVENTOS ......................................................................................................................... 1515 RELACIONAMENTO .......................................................................................................................... 152 5.1 RELACIONAMENTO ENTRE ATORES ...................................................................................... 152 5.2 ATOR X CASO DE USO ................................................................................................................. 152 5.3 INCLUSÃO E EXTENSÃO ............................................................................................................ 153 5.4 EXTENSÃO ...................................................................................................................................... 1546 GENERALIZAÇÃO .............................................................................................................................. 156RESUMO DO TÓPICO 3........................................................................................................................ 158AUTOATIVIDADE ................................................................................................................................. 159

TÓPICO 4 - DIAGRAMA DE CLASSE ............................................................................................... 1611 INTRODUÇÃO ..................................................................................................................................... 161

X

2 DIAGRAMAS DE CLASSE ................................................................................................................ 161LEITURA COMPLEMENTAR ............................................................................................................... 165RESUMO DO TÓPICO 4........................................................................................................................ 174AUTOATIVIDADE ................................................................................................................................. 175

TÓPICO 5 - DIAGRAMA DE SEQUÊNCIA ...................................................................................... 1771 INTRODUÇÃO ..................................................................................................................................... 1772 TIPOS DE MENSAGEM ..................................................................................................................... 177 2.1 NOTAÇÃO DO DIAGRAMA DE SEQUÊNCIA ........................................................................ 178LEITURA COMPLEMENTAR ............................................................................................................... 180RESUMO DO TÓPICO 5........................................................................................................................ 188AUTOATIVIDADE ................................................................................................................................. 189REFERÊNCIAS ......................................................................................................................................... 190

1

UNIDADE 1

INTRODUÇÃO AOS MODELOS DE PROCESSO TRADICIONAIS:

MODELO CASCATA E INCREMENTAL E MODELOS EVOLUCIONÁRIOS:

MODELO ESPIRAL E PROTOTIPAÇÃO

OBJETIVOS DE APRENDIZAGEM

PLANO DE ESTUDOS

Esta unidade tem por objetivos:

• introdução aos conceitos de ciclo de vida;

• modelagem orientada e estruturada;

• conhecimento dos modelos ágeis de desenvolvimento.

Esta unidade de ensino contém três tópicos. No final de cada um deles você encontrará atividades que contribuirão para a apropriação dos conteúdos.

TOPICO 1 – MODELOS DE CICLO DE VIDA

TÓPICO 2 – INTRODUÇÃO À MODELAGEM ESTRUTURADA E MODELAGEM ORIENTADA A OBJETO

TÓPICO 3 – METÓDO DE DESENVOLVIMENTO ÁGIL

3

TÓPICO 1UNIDADE 1

MODELOS DE CICLO DE VIDA

1 INTRODUÇÃO

A existência de um sistema de informação passa por um processo conhecido como Ciclo de Vida, com três estágios bastante conhecidos pelo analista de sistema: concepção, desenvolvimento e vida útil. De acordo com Silva (2014, p. 28), o nome de cada fase da vida de um sistema pode sofrer variações, mas, na sua essência, nada muda. Como vemos na definição:

Existe um encadeamento específico dessas fases, para a construção do sistema dá-se o nome de Ciclo de vida. O processo de software é o conjunto de atividades que constituem o desenvolvimento de um sistema computacional. Estas atividades são agrupadas em fases, como: • Definição de requisitos,• Análise, projeto, • Desenvolvimento, • Teste e implantação.

Cada fase do desenvolvimento de software é definida. Além das suas atividades, as funções e responsabilidades de cada membro da equipe, e, como produto resultante, os artefatos. Como tudo que dá certo se repete, no mercado de software ocorre o mesmo. Repetiram-se as práticas que ofereceram resultados positivos. E a formalização em modelos de ciclo de vida. Em outras palavras, os modelos de Ciclo de Vida são o esqueleto ou as estruturas predefinidas, nas quais encaixamos as fases do processo. De acordo com Macêdo e Spínola (2016), a NBR ISO/IEC 12207:1998, o Ciclo de Vida é a “Estrutura contendo processos, atividades e tarefas envolvidas no desenvolvimento, operação e manutenção de um produto de software, abrangendo a vida do sistema desde a definição de seus requisitos, até o término de seu uso”.

O modelo de Ciclo de Vida é a primeira escolha a ser feita no processo de software, e a partir desta escolha definir-se-á desde a maneira mais adequada para obter as necessidades do cliente, até quando e como o cliente receberá sua primeira versão operacional do sistema. Vale ressaltar que não existe um modelo ideal. O perfil e complexidade do empreendimento do cliente, o tempo disponível, o custo, a equipe, o ambiente operacional são fatores que influenciarão diretamente na escolha do Ciclo de Vida de software a ser adotado. Da mesma forma, também é difícil uma empresa adotar somente um Ciclo de Vida no processo.

Os ciclos de vida se comportam de maneira sequencial (fases seguem determinada ordem) e/ou incremental (divisão de escopo) e/ou iterativa (retroalimentação de fases) e/ou evolutiva (software é aprimorado).

UNIDADE 1 | INTRODUÇÃO AOS MODELOS DE PROCESSO TRADICIONAIS: MODELO CASCATAE INCREMENTAL E MODELOS EVOLUCIONÁRIOS: MODELO ESPIRAL E PROTOTIPAÇÃO

4

Não existe uma regra, a escolha de um modelo de processo depende muito das características do projeto. Para escolher o modelo mais adequado é importante conhecer alguns modelos de Ciclo de Vida e as situações em que são aplicáveis.

2 MODELOS DE PROCESSOS PRESCRITIVOS OU TRADICIONAIS

Originalmente, modelos prescritivos foram propostos para trazer ordem ao caos existente na área de desenvolvimento de software. Segundo Pressman (2011, p.58), esses modelos proporcionavam uma contribuição quanto à estrutura utilizável no trabalho de engenharia de software e forneceram um roteiro razoavelmente eficaz para as equipes deste.

2.1 MODELO EM CASCATA

Também chamado de “modelo de ciclo de vida clássico”, o Modelo em Cascata organiza as atividades do processo de desenvolvimento de forma sequencial, como mostra a Figura 1. Uma característica desse modelo é que cada fase resulta na elaboração de um ou mais documentos, que devem ser aprovados antes de se iniciar a fase seguinte. Ou seja, uma fase só será iniciada após a conclusão daquela que a precede. Uma vez que, na prática, essas fases se sobrepõem de alguma forma, geralmente permite-se um retorno à fase anterior para a correção de erros encontrados. O resultado final, ou melhor, a entrega do sistema completo ocorre de uma única vez, ao final da fase de Entrega e Implantação. No Modelo em Cascata, todo o projeto deve ser entendido em suas fases iniciais, seguindo até o final com pouquíssima interação com o cliente.

TÓPICO 1 | MODELOS DE CICLO DE VIDA

5

FIGURA 1 - MODELO EM CASCATA

FONTE: Disponível em: <http://www.inf.ufes.br/~monalessa/PaginaMonalessa- NEMO/ES_Mestrado/Artigos/ProcessoDeSoftware.pdf> Acesso em: 23 fev. 2016

Os principais estágios do Modelo em Cascata refletem diretamente as atividades fundamentais do desenvolvimento, segundo Sommerville (2011, p. 20):

1. Análise e definição de requisitos: Os serviços, restrições e metas do sistema são estabelecidos por meio de consulta aos usuários. Em seguida, são definidos em detalhes e funcionam como uma especificação do sistema.2. Projeto de sistema e software: O processo de projeto de sistemas aloca os requisitos tanto para sistemas de hardware como para sistemas de software, por meio de definição de uma arquitetura geral do sistema. O projeto de software envolve a identificação e descrição das abstrações fundamentais do sistema de software e seus relacionamentos.3. Implementação e teste unitário: Durante esse estágio, o projeto do software é desenvolvido como um conjunto de programas ou unidades de programa. O teste unitário envolve a verificação de que cada unidade atende à sua especificação.4. Integração e teste de sistema: As unidades individuais do programa ou programas são integradas e testadas como um sistema completo, para assegurar que os requisitos do software tenham sido atendidos. Após o teste o sistema de software é entregue ao cliente.

No capítulo 2- Detalharemos os tipos de requisitos e técnicas de levantamento de requisitos.

ESTUDOS FUTUROS


6

5. Operação e manutenção: Normalmente (embora não necessariamente), essa é a fase mais longa do ciclo de vida. O sistema é instalado e colocado em uso. A manutenção envolve a correção de erros que não foram descobertos em estágios iniciais do ciclo de vida, com melhora da implementação das unidades do sistema e ampliação de seus serviços em resposta às descobertas de novos requisitos.

Existe uma variação do Modelo em Cascata que é chamado de modelo V. Nesse modelo, procura-se enfatizar a estreita relação entre as atividades de teste (teste de unidade, teste de integração, teste de sistema e teste de aceitação) e as demais fases do processo.

Pressman (2011) explica que à medida que a equipe de software desce em direção ao lado esquerdo do V, os requisitos básicos do problema são refinados em representações progressivamente cada vez mais detalhadas e técnicas do problema e de sua solução. Como mostra a Figura 2.

FIGURA 2 - MODELO V

FONTE: Adaptado de Pressman (2011, p. 60)


7

O Modelo em Cascata é o modelo mais antigo na engenharia de software, e nos últimos anos recebeu várias críticas, conforme relatadas por Pressman (2011, p. 61):

• Projetos reais raramente seguem o fluxo sequencial que o modelo propõe. Embora o modelo linear possa conter interações, ele o faz indiretamente. Como consequência, mudanças podem provocar confusão à medida que a equipe de projeto prossegue.• Frequentemente, é difícil para o cliente estabelecer explicitamente todas as necessidades. O modelo em cascata requer isso e tem dificuldade para adequar a incerteza natural que existe no início de muitos projetos.• O cliente deve ter paciência. Uma versão operacional do(s) programa(s) não estará disponível antes de estarmos próximo do final do projeto. Um erro grave, se não detectado até o programa operacional ser revisto, pode ser desastroso.

2.1.1 Modelo Incremental

Nem todos os projetos que conseguem ter todos os requisitos são razoavelmente bem definidos, e devido ao tamanho do sistema a ser desenvolvido, isso torna impossível a adoção de um modelo sequencial, especialmente pela necessidade de disponibilizar uma versão para o usuário rapidamente. Para esses casos o Modelo Incremental é o mais indicado, como detalharemos.

Pressman (2011) diz que o Modelo Incremental combina elementos dos fluxos de processos lineares e paralelos. A Figura 3 ilustra esses modelos.


8

FIGURA 3 - MODELO INCREMENTAL

FONTE: Pressman (2011, p. 54)

O princípio fundamental desse modelo é que, seja iteração ou ciclo, uma versão operacional do sistema é gerada e entregue para avaliação e uso detalhado do cliente.

Para que isso aconteça, os requisitos têm que ser levantados detalhadamente

e há de se constatar que o sistema é modular, de modo que se possa planejar o desenvolvimento em incrementos. O primeiro incremento, tipicamente, contém funcionalidades centrais, tratando dos requisitos básicos. A cada ciclo, novas funcionalidades são adicionadas e as funcionalidades providas anteriormente podem ser modificadas para melhor satisfazer às necessidades dos clientes/usuários. Outras características são tratadas em ciclos subsequentes. Dependendo do tempo estabelecido para a liberação dos incrementos, algumas atividades podem ser feitas para o sistema como um todo ou não.


9

2.1.2 Modelos de processo evolucionário

Pressman (2011) afirma que o software, assim como todos os sistemas complexos, evolui ao longo do tempo e, conforme o desenvolvimento deste software avança, temos mudanças nas necessidades de negócio e de produtos, uma vez que mudam frequentemente. Isso torna inadequado seguirmos um planejamento em linha reta de determinado produto. Muitas vezes, os prazos reduzidos, a necessidade de atender à pressão comercial e até mesmo da concorrência e em outras situações como essas ou similares, faz-se necessário um modelo de processo que tenha sido projetado especificamente para desenvolver um produto que evolua ao longo do tempo. Modelos Evolucionários são caracterizados por serem iterativos e apresentarem características que possibilitem desenvolvermos versões cada vez mais completas do software. Os Processos Evolucionários se caracterizam por dois modelos comuns: Prototipação e Espiral.

2.1.3 Modelo Espiral

O Modelo Espiral foi originalmente proposto por Boehm em 1988. Para definir esse modelo de uma maneira mais simples, basta analisa-lo como um Modelo em Cascata, onde cada fase é precedida por uma análise de risco e sua execução é feita evolucionariamente (ou incrementalmente). Neste modelo de desenvolvimento é possível avaliar riscos de projeto, tomando-se decisões baseadas na experimentação de diferentes soluções. Para entendermos melhor, veja a Figura 4.

A dimensão radial representa o custo acumulado atualizado e a dimensão angular representa o progresso através da espiral. Cada setor da espiral corresponde a uma tarefa (fase) do desenvolvimento. No modelo original foram propostas quatro tarefas (fases ou quadrantes) onde, por exemplo, na primeira volta pode gerar como resultado a especificação do produto, na espiral subsequente o resultado pode ser o protótipo, e nas voltas seguintes podem ser relativos a versões aprimoradas do sistema (PRESSMAN, 2008, p.38).


10

FIGURA 4 - MODELO ESPIRAL


2.1.4 Prototipação

Em relação a esse paradigma, Pressman (2011) afirma que, embora possa ser utilizada como um modelo de processo isolado (stand-alone-process), é mais comumente utilizada como uma técnica passível de ser implementada no contexto de qualquer um dos modelos apresentados. Ele explica o funcionamento deste paradigma de maneira reduzida.

Na fase de comunicação, faz-se uma reunião com os envolvidos para definir os objetivos gerais do software, identificar quais requisitos já são conhecidos e esquematizar quais áreas necessitam, obrigatoriamente, de uma definição mais ampla. Uma interação de prototipação é planejada rapidamente e ocorre a modelagem (na forma de um “projeto rápido”).

Durante a fase de modelagem do projeto rápido: se concentra em uma representação daqueles aspectos do software que serão visíveis aos usuários finais, como, por exemplo, o layout da interface com o usuário ou formatos de exibição na tela. E, finalmente, a construção de um protótipo: Nesta fase é feita a construção do protótipo, que é empregado e avaliado, conforme vemos na Figura 5.


11

FIGURA 5 - PROTOTIPAÇÃO


Sommerville (2011, p. 31) alerta que, às vezes, os desenvolvedores são pressionados pelos gerentes para entregar protótipos descartáveis, especialmente quando há atrasos na entrega da versão final do software. No entanto, isso costuma ser desaconselhável:

1. Pode ser impossível ajustar o protótipo para atender aos requisitos não funcionais, como requisitos de desempenho, proteção, robustez e confiabilidade, que foram ignorados durante o desenvolvimento do protótipo.2. Mudanças rápidas durante o desenvolvimento inevitavelmente significam que o protótipo não está documentado. A única especificação do projeto é o código do protótipo. Para a manutenção a longo prazo, isso não é bom o suficiente.3. As mudanças durante o desenvolvimento do protótipo provavelmente terão degradado a estrutura do sistema. O sistema será difícil e custoso de ser mantido.4. Padrões de qualidade organizacional geralmente são relaxados para o desenvolvimento do protótipo.

12

Neste tópico, vimos:

• Um breve contato com conceitos e modelos relacionados ao processo de desenvolvimento de software.

• Modelos de processos prescritivos ou tradicionais: Modelo em Cascata e Modelo Incremental e um resumo das fases.

• Modelos de processo evolucionário: Modelo espiral e Prototipação.

RESUMO DO TÓPICO 1

13

1 Qual deve ser a primeira escolha a ser feita no processo de software?

2 Projetos reais raramente seguem o fluxo sequencial que o modelo propõe. Embora o modelo linear possa conter interações, ele o faz indiretamente. Como consequência, mudanças podem provocar confusão à medida que a equipe de projeto prossegue. Essa é uma crítica que vem sendo apresentada referente a qual modelo de desenvolvimento?

3 Quando se começa um projeto, nem todos conseguem ter todos os requisitos razoavelmente bem definidos, e devido ao tamanho do sistema a ser desenvolvido, isso torna impossível a adoção de qual modelo? E qual modelo pode ser sugerido?

4 Preencha de acordo com a definição das fases de desenvolvimento:

AUTOATIVIDADE

Normalmente (embora não necessariamente), essa é a fase mais longa do Ciclo de Vida. O sistema é instalado e colocado em uso. A manutenção envolve a correção de erros que não foram descobertos em estágios iniciais do Ciclo de Vida, com melhora da implementação das unidades do sistema e ampliação de seus serviços em resposta às descobertas de novos requisitos.O processo de projeto de sistemas aloca os requisitos tanto para sistemas de hardware como para sistemas de software, por meio de definição de uma arquitetura geral do sistema. O projeto de software envolve a identificação e descrição das abstrações fundamentais do sistema de software e seus relacionamentos.Os serviços, restrições e metas do sistema são estabelecidos por meio de consulta aos usuários. Em seguida, são definidos em detalhes e funcionam como uma especificação do sistema.As unidades individuais do programa ou programas são integradas e testadas como um sistema completo, para assegurar que os requisitos do software tenham sido atendidos. Após o teste, o sistema de software é entregue ao cliente.Durante esse estágio, o projeto do software é desenvolvido como um conjunto de programas ou unidades de programa. O teste unitário envolve a verificação de que cada unidade atende à sua especificação.

14

5 Qual é o modelo ideal que se aplica à maioria dos projetos de software?

6 A definição de que, embora possa ser utilizada como um modelo de processo isolado (stand-alone-process), é mais comumente utilizada como uma técnica passível de ser implementada no contexto de qualquer um dos modelos apresentados, se refere a qual modelo de desenvolvimento?

15

TÓPICO 2

INTRODUÇÃO A MODELAGEM ESTRUTURADA E

MODELAGEM ORIENTADA A OBJETO

UNIDADE 1

1 INTRODUÇÃO

Se pedissem para você desenhar ou procurar na internet um item bem específico: Uma cadeira com bolinhas amarela e confortável. A princípio não parece ser um pedido muito difícil, certo?

Mas, qual das cadeiras era a solicitada?

FIGURA 6 - CADEIRA DE BOLINHA

FONTE: Disponível em: <http://arquitetura-tamiris.blogspot.com/2011/03/cadeira-de-bolinha-amarelinhaa.html>. Acesso em: 22 mar. 2016.

16


FIGURA 7- CADEIRA DE BOLINHA

FONTE: Disponível em: <http://revistacasaejardim.globo.com/Revista/Common/0,,ERT75860-16940,00.html>. Acesso em: 22 mar. 2016.

Isso foi apenas uma maneira de ilustrar a dificuldade de atender aos requisitos. Mas se foi tão difícil para um item tão simples como uma cadeira, imagine para o sistema de uma empresa.

Para ajudar nessa tarefa, têm-se os modelos, que são uma visualização dos requisitos, bem como o desejo do cliente do que deve ser implementado. Juntos, eles auxiliam no entendimento do que o cliente solicitou e do que a equipe deve desenvolver.

O ponto mais importante do desenvolvimento de um sistema é compreender as necessidades e desejos do usuário e da organização e visualizar os benefícios que serão obtidos com esse sistema, mas se isso não for bem entendido, os requisitos e as atividades relacionadas ao seu desenvolvimento não terão significado algum.

O termo modelagem já sugere a criação de um modelo, a elaboração de um esboço do que se pretende fazer, por meio de um gráfico, um desenho, antes de começar a construção propriamente dita. Essa atividade abrange vários segmentos, pode ser uma casa, um carro, um vestido ou até mesmo um software. Abaixo há alguns esboços de coisas bem diferentes, mas que seguem a mesma linha de raciocínio.

17

TÓPICO 2 | INTRODUÇÃO A MODELAGEM ESTRUTURADAE MODELAGEM ORIENTADA A OBJETO

FIGURA 8- MODELO CASA

FONTE: Disponível em: < http://www.tudoconstrucao.com/10-modelos-de-plantas-de-casas-para-2015/>. Acesso em: 22 mar. 2016.

FIGURA 9- MODELO CARRO

FONTE: Disponível em: < http://pt.dreamstime.com/fotos-de-stock-royalty-free-desenho-do-carro-image7844748>. Acesso em: 22 mar. 2016.

FIGURA 10- MODELO VESTIDO

FONTE: Disponível em: <http://vida-estilo.estadao.com.br/noticias/moda,veja-quais-sao-os-vestidos-de-casamento-mais-iconicos-de-todos-os-tempos,1786989>. Acesso em: 22 mar. 2016.

18


É durante a fase de modelagem que o autor do projeto, independentemente do tipo, prepara um “modelo” com todos os requisitos, funcionalidade ou características, que o seu cliente ou usuário solicitou. Nesse modelo apresentam-se a estrutura e o comportamento do sistema que será desenvolvido, enxergando seu funcionamento. Durante essa fase é possível verificar com o usuário se o modelo proposto atende às suas necessidades, conforme os requisitos informados.

A criação de modelos é de suma importância para o entendimento do projeto como um todo.

2 IMPORTÂNCIA DA MODELAGEM DE SISTEMAS

Pode-se construir uma casa para um cachorro apenas juntando algumas tábuas, alguns pregos e algumas ferramentas básicas. Com um planejamento mínimo, em poucas horas e com um pouco de habilidade, nosso cachorro terá uma casa (BOOCH et al., 2000).

FIGURA 11 - CASA DE CACHORRO

FONTE: Disponível em: <http://bioretro.eco.br/lar-cao-tambem-sustentavel/>. Acesso em: 23 fev. 2016.

Ainda segundo o autor, se o plano for construir a casa para sua família, com certeza uma pequena pilha de tábuas e alguns pregos não será o suficiente, pois, com certeza, sua família será um pouco mais exigente que o seu cachorro. Para fazer a sua casa, antes de sair batendo o primeiro prego é necessário que você saiba o que

19


sua família espera, será melhor fazer um planejamento bem detalhado de como será essa construção. Fazer alguns desenhos e verificar todos os procedimentos para garantir a segurança da edificação. Durante esse detalhamento, você verá que é muito difícil construir uma casa sozinho, e que terá que ter uma equipe para auxiliar, com cada membro da equipe sabendo o que deve desempenhar. Se tudo correr bem e o modelo for seguido, provavelmente, ao final do projeto, sua família ficará satisfeita. Vale ressaltar que, para não gerar frustrações ao final do projeto, é muito importante definir as expectativas desde o início.

FIGURA 12 - CASA SEM PROJETO

FONTE: Disponível em: <http://atl.clicrbs.com.br/mundoidao/2008/08/26/casa-e-construida-de-cabeca-para-baixo/> Acesso em: 23 fev. 2016.

Agora, se você não quer construir software equivalente a uma casa, Booch et al. (2000) advertem que o segredo estará em criar o código correto e pensar em como será possível elaborar menos software. Isso faz com que o desenvolvimento de programa de qualidade se torne uma questão de arquitetura, processo e ferramentas. Para uma empresa de software ter sucesso, existem vários elementos que contribuem para isso, um deles é a utilização da modelagem.

Ainda segundo Booch et al. (2000, p.6) constroem-se modelos para compreender melhor o sistema que estamos desenvolvendo. E com ela é possível alcançar quatro objetivos:

• Os modelos ajudam a visualizar o sistema como ele é ou como desejamos que seja.• Os modelos permitem especificar a estrutura ou o comportamento de um sistema.• Os modelos proporcionam um guia para a construção do sistema.• Os modelos documentam as decisões tomadas.

Vale ressaltar que a modelagem não se restringe apenas a grandes sistemas. Ainda de acordo com Booch et al. (2000), softwares pequenos, equivalentes a uma casa de cachorro, poderão receber os benefícios da modelagem, porém é verdade que quanto maior e mais complexo o sistema, maior será a importância da modelagem, por um motivo bem simples, que não é possível compreendê-los em sua totalidade.

20


3 EVOLUÇÃO HISTÓRICA DA MODELAGEM

Bezerra (2015) apresenta um breve resumo histórico da evolução das técnicas de desenvolvimento, para explicar como chegamos ao cenário atual.

Décadas de 1950/1960: Os sistemas eram bem simples, e o seu desenvolvimento era direto ao assunto, não tinha um planejamento inicial, como dizem, “ad hoc”. Como os sistemas eram significativamente mais simples, as técnicas de modelagem também: Eram usados fluxogramas e diagramas de módulos.

Década de 1970: Começaram a surgir computadores mais avançados e acessíveis. Houve grande ampliação do mercado computacional. Sistemas mais complexos começavam a surgir. Consequentemente, modelos mais robustos foram propostos. Os autores Larry Constantine e Edward Yourdon são grandes colaboradores nessas técnicas.

Década de 1980: Nessa fase os computadores se tornaram ainda mais avançados e mais baratos. Surge a necessidade por interfaces mais sofisticadas, o que originou a produção de sistemas de softwares mais complexos. A Análise Estruturada surgiu no início desse período, com os trabalhos de Edward Yourdon, Peter Coad, Tom De Marco, James Martin e Chris Gane.

Década de 1990: No início dessa década é o período em que surge um novo paradigma de modelagem, a Análise Orientada a Objetos, como resposta a dificuldades encontradas na aplicação da análise estruturada em algumas aplicações. Grandes colaboradores desse paradigma são Sally Shlaer, Stephen Mellor, Rebecca Wirfs-Brock, James Rumbaugh, Grady Booch e Ivar Jacobson.

Já no fim da década, o paradigma da orientação a objetos atinge sua maturidade. Os conceitos de padrões de projeto, frameworks, componentes e qualidade começam a ganhar espaço. Surge a Linguagem de Modelagem Unificada UML.

Década de 2000: O reúso por meio de padrões de projetos e frameworks se solidifica. As denominadas metodologias ágeis começam a ganhar espaço. Técnicas de testes automatizados e refatoração começaram a se difundir entre os desenvolvedores que trabalham com orientação a objeto. Grandes nomes dessa fase são: Rebecca Wirfs-Brock, Martin Fowler e Eric Vans.

Como percebemos, durante a década de 90 surgiram várias propostas e técnicas para modelagem de sistema segundo o paradigma da orientação a objeto. Era comum, durante essa década, duas técnicas possuírem diferentes notações gráficas para modelar a mesma perspectiva de um sistema. Todas tinham pontos fortes e fracos em relação à notação utilizada, mas via-se a necessidade de uma notação que viesse a se tornar um padrão para a modelagem de sistemas orientados a objeto, e que fosse amplamente aceita, nas indústrias e na academia.

21


FONTE: Disponível em: <https://www.passeidireto.com/arquivo/19056116/principios-de-analise-e-projeto---eduardo-bezerra/7>. Acesso em: 11 abr. 2016.

Alguns esforços surgiram em 1996 para essa padronização, o que resultou na definição da UML (Unified Modeling Language), que detalharemos a seguir em um tópico específico, mas antes falaremos na Modelagem Estruturada e da Modelagem Orientada a Objetos.

3.1 MODELAGEM ESTRUTURADA

A modelagem estruturada teve seu início na década de 1970, com uma abordagem bem sistemática, utilizando técnicas de construção de modelos. O seu princípio é a divisão em módulos e submódulos. Ele é de fácil utilização, especialmente por ser diagrama de fácil compreensão e minimização, a lacuna de conhecimento, muitas vezes, existente entre os analistas e os usuários. A sua documentação é feita através dos diagramas de fluxo de dados (DFD), Diagrama de entidade-relacionamento (DER).

O Diagrama de fluxo de dados tem como objetivo representar graficamente o fluxo dos dados, normalmente usados para apresentar uma visão geral do sistema, onde podemos verificar a entrada e saída das informações e onde os dados serão armazenados.

Entidades Externas: São categorias lógicas de objetos ou pessoas que representam Origem ou destino de dados, e que acionam um sistema e/ou recebem informações. Podem ser pessoas, sistemas ou unidades departamentais, segundo Rezende (2005, p.170).

Fluxo de dados: Representa um processo de transformação de dados, é o meio por onde os dados e as informações trafegam, eles sempre envolvem um processo, sua representação é um retângulo com cantos arredondados;

Processos: Transformam fluxos de dados em uma atividade, ou seja, são as atividades que transformam as entradas, transportam dados de processo a processo, armazena os dados, e produz as saídas de um sistema.

Depósito de dados: São locais de armazenamento de dados, são arquivos físicos.

22


FIGURA 13- SUBSISTEMAS DE FATURAMENTO

FONTE: Rezende (1997, p. 109)

Diagrama entidade-relacionamento (DER): O principal propósito do DER é representar os objetos de dados e suas relações, sendo que cada entidade termina representada pelo menos por uma tabela de dados, e normalmente expressa por um depósito de dados do DFD.

Os objetos de dados são representados por retângulos rotulados e os relacionamentos são indicados por losangos, e as conexões entre os dados e os relacionamentos são estabelecidos usando-se uma série de linhas e ligações especiais.

23


FIGURA 14- ELEMENTOS E SÍMBOLOS DER

FIGURA 15- EXEMPLO DE DIAGRAMA DER

FONTE: Disponível em: < http://www.devmedia.com.br/artigo-sql-magazine-61-modelagem-de-dados-para-um-sistema-de-controle-de-orcamento/11726>. Acesso em: 23 fev. 2016.

3.2 PARADIGMA DA ORIENTAÇÃO A OBJETO (OO)

Uma forma mais eficiente de pensar em modelagem e desenvolvimento de projetos é a Proposta Orientada a Objetos, que organiza os problemas em torno de situações reais, como elas realmente acontecem na prática, e isso impõe uma forma completamente diferente de pensar e organizar a solução, se comparado à forma como o pensamento estruturado apresenta esta. (BOOCH, 1994).

Inicialmente é importante definir a palavra paradigma. Pode-se dizer, então, que o termo “paradigma da orientação a objetos” é uma forma de abordar um problema. Segundo Bezerra (2015, p. 5):

24


Há alguns anos, Alan Kay, um dos pais do paradigma a orientação a objetos, formulou a chamada “analogia biológica”. Por meio dela, ele imaginou um sistema de software que funcionasse como um ser vivo. Nesse sistema, cada “célula” interagiria com outras células através do envio de mensagens com o propósito de realizar um objetivo comum. Além disso, cada célula se comportaria como uma unidade autônoma.

Ele pensou em construir um sistema de software a partir de agentes autônomos que interagem entre si. E estabeleceu os seguintes princípios da orientação a objetos Kay apud Bezerra (2005, p 6).

1. Qualquer coisa é um objeto.2. Objetos realizam tarefas por meio da requisição de serviços a outros objetos.3. Cada objeto pertence a uma determinada classe. Uma classe agrupa objetos similares.4. A classe é um repositório para comportamento associado ao objeto.5. Classes são organizadas em hierarquia.

Pode-se concluir que a Orientação a Objeto como técnica para modelagem de sistemas diminui a diferença semântica entre a realidade que está sendo modelada e os modelos construídos.

A visão contemporânea no desenvolvimento de software, segundo Booch et al. (2000), adota uma perspectiva orientada a objeto. Nessa visão, o principal bloco de construção de todos os sistemas de software é o objeto ou classe. Objeto é alguma coisa geralmente estruturada a partir do vocabulário do espaço ou problema ou do espaço da solução. E uma Classe é a descrição de um conjunto de objetos comuns. Todos os objetos têm uma identidade. É possível atribuir nomes ou diferenciá-los de alguma maneira. Um estado (costuma haver dados a eles relacionados) e um comportamento, que indica que você pode fazer algo com o objeto ou ele poderá fazer algo com outros objetos.

Entre as ideias fundamentais básicas para a tecnologia orientada a objeto temos:

• Objetos.• Classes.• Métodos.• Herança.• Encapsulamento.

Objetos: Cada conceito é uma ideia ou um entendimento coletivo que temos do nosso mundo. Os conceitos que adquirimos nos permitem dar sentido sobre as coisas do nosso mundo. Essas coisas às quais nossos conceitos se aplicam são denominados objetos. Um objeto pode ser real ou abstrato.

• Os objetos possuem informações (contêm dados) e desempenham ações (possuem funcionalidade).

25


• Qualquer coisa à qual um conceito ou tipo de objeto se aplica – uma instância de um conceito ou tipo de objeto.

• Um objeto é uma instância de uma classe.

Classe: O termo classe refere-se à implementação de software de um tipo de objeto. Um tipo de objeto especifica uma família de objetos sem estipular como o tipo e o objeto são implementados. Os tipos de objetos são especificados durante a análise OO. Os tipos de objetos são implementados como módulos, enquanto na linguagem orientada a objeto os tipos de objetos são classificados como classes.

• Uma classe é uma implementação de um tipo de objeto.• Uma classe especifica uma estrutura de dados e os métodos operacionais

permissíveis que se aplicam a cada um de seus objetos.• Uma classe pode ter sua própria estrutura de dados e métodos, bem como

herdá-la de sua superclasse.

Métodos:

• Os métodos especificam a maneira pela qual os dados de um objeto são manipulados.

• Uma especificação dos passos pelos quais uma operação deve ser executada.• Ele é um script de implementação de uma operação.• Diferentes métodos podem ser usados para executar a mesma operação.• Os métodos de um tipo de objeto referenciam somente as estruturas de dados

desse tipo de objeto.• A ação que um objeto ou uma classe podem desempenhar.• Os métodos são similares às funções e procedures do universo da programação

estruturada.

Encapsulamento: O ato de empacotar ao mesmo tempo dados e objetos é denominado encapsulamento. O objeto esconde seus dados de outros objetos e permite que os dados sejam acessados por intermédio de seus próprios métodos. Isso é chamado de ocultação de informações (information hiding).

• O encapsulamento protege os dados do objeto do uso arbitrário e não intencional.

• O encapsulamento é o resultado (ou ato) de ocultar do usuário os detalhes da implementação de um objeto.

• O encapsulamento é importante porque separa a maneira como um objeto se comporta da maneira como ele é implementado.

FONTE: Disponível em: <http://www.macoratti.net/net_oocb.htm>. Acesso em: 11 abr. 2016.

26

RESUMO DO TÓPICO 2

Neste tópico, vimos que:

• A modelagem facilita a comunicação entre as partes envolvidas.

• A importância da modelagem de sistemas, como parte imprescindível no desenvolvimento dos projetos.

• A evolução histórica da modelagem, o que deu certo e o que mudou.

• As técnicas de Modelagem estruturada e o Paradigma da Orientação a Objeto (OO).

27

1 “Cada conceito é uma ideia ou um entendimento coletivo que temos do nosso mundo. Os conceitos que adquirimos nos permitem dar sentido sobre as coisas do nosso mundo. Essas coisas às quais nossos conceitos se aplicam são denominadas objetos.” Essa definição é verdadeira ou falsa?

2 Para que serve a modelagem?

3 Quais definições apresentadas não estão corretas?

• Encapsulamento – É o agrupamento de ideias afins em uma unidade. Permite ao programador apresentar os detalhes da representação dos dados por trás de um conjunto de operações (como a interface). Reflita sobre o seguinte: você sabe como funciona internamente o seu micro-ondas? Mas você sabe como ligá-lo, programá-lo e desligá-lo. Você interage com o micro-ondas por meio de sua interface sem se preocupar com os detalhes da implementação: esse é um exemplo de encapsulamento.

• Ocultação de informações e implementações – é exatamente o uso do encapsulamento que restringe a visibilidade de detalhes e informações que ficam internas à estrutura do encapsulamento.

• Mensagens – solicitação de um objeto para que outro objeto efetue uma de suas operações. Os objetos não podem mandar mensagens entre si. As mensagens resultam na chamada de métodos que executam as ações necessárias.

• Classes – as classes são conjuntos de objetos com características semelhantes.• Herança – o mecanismo de herança permite que uma classe seja criada a

partir de outra classe (superclasse), e a nova classe (subclasse) herda todas as suas características.

• Poliformismo – é a propriedade segundo a qual uma operação pode se comportar de modos diversos em classes diferentes. Sistemas orientados a objetos são flexíveis a mudanças, possuem estruturas bem conhecidas e oferecem a oportunidade de criar e implementar componentes totalmente reutilizáveis.

4 Quais são os objetivos atingidos utilizando modelos?

5 Quando e por que a Análise Orientada a Objetos surgiu?

6 Defina os objetivos da análise estruturada e como ela é documentada.

AUTOATIVIDADE

29

TÓPICO 3

MÉTODO DE DESENVOLVIMENTO ÁGIL

UNIDADE 1

1 INTRODUÇÃO

Em 2001, Kent Beck e outros 16 renomados desenvolvedores, autores e consultores da área de software, batizados de “Aliança dos ágeis (Agile Alliance)”, assinaram o Manifesto para o Desenvolvimento Ágil de Software (Agile Software Development Manifesto), que se inicia da seguinte maneira, segundo Pressman (2011, p. 81):

Desenvolvendo e ajudando outros a desenvolver software, estamos desvendando formas melhores de desenvolvimento. Por meio deste trabalho passamos a valorizar:Indivíduos e interações acima de processos e ferramentas.Software operacional acima de documentação completa.Colaboração dos clientes acima de negociação comercial.Respostas a mudanças acima de seguir um plano.Ou seja, embora haja valor nos itens à direita, valorizaremos os da esquerda mais ainda.

Ainda segundo o autor, normalmente, um manifesto é associado a um movimento político emergente: atacando a velha guarda e sugerindo uma mudança revolucionária (normalmente, espera-se que para a melhor). E, de certa forma, é exatamente disso que o desenvolvimento ágil trata. Vale frisar que apesar de parecer benéfica, essa metodologia não é indicada para todos os projetos, produtos, pessoas e situações.

Afinal, no contexto de engenharia de software, o que é agilidade? Jacobson apud Pressman (2011, p. 82) responde essa pergunta:

Atualmente agilidade tornou-se a palavra da moda quando se descreve um moderno processo de software. Todo mundo é ágil. Uma equipe ágil é aquela capaz de responder apropriadamente a mudanças. Mudanças têm muito a ver com desenvolvimento de software. Mudanças no software que está sendo criado, mudanças nos membros da equipe, mudanças devido a novas tecnologias, mudanças de todos os tipos

Para maiores informações, acesse: http://agilemanifesto.org/

DICAS

30


que poderão ter um impacto no produto que está em construção ou no projeto do produto. Suporte para mudanças deve ser incorporado em tudo o que fazemos em software, algo desenvolvido por indivíduos trabalhando em equipes e que as habilidades dessas pessoas, suas capacidades em colaborar estão no cerne do sucesso do projeto.

O Método Ágil de desenvolvimento incentiva a estruturação e as atitudes em equipe que tornam a comunicação mais fácil entre todos os envolvidos no projeto, e também enfatiza a entrega rápida do software operacional e diminui a importância dos artefatos intermediários.

Importante salientar que os custos para as alterações em software aumentam de forma não linear conforme o projeto avança, e quando mais tarde for feita a alteração, mais alto será o custo. É fácil imaginar que se uma alteração for feita durante a fase de requisitos, no início do projeto, estes custos serão mínimos, e o tempo não afetará negativamente o resultado do projeto, como podemos observar na Figura 16.

FIGURA 16 - CUSTO DE ALTERAÇÃO

Fonte: Pressman (2011, p. 83)

31

TÓPICO 3 | MÉTODO DE DESENVOLVIMENTO ÁGIL

2 PRECEITOS E PRINCÍPIOS

Pressman (2011, p.84) ressalta que qualquer processo ágil de software é caracterizado de uma forma que se relacione a uma série de preceitos-chave acerca da maioria dos projetos de software.

1. É difícil afirmar antecipadamente quais requisitos de software irão persistir e quais sofrerão alterações. É igualmente difícil prever de que maneira as prioridades do cliente sofrerão alterações conforme o projeto avança.2. Para muitos tipos de software, o projeto e a construção são “interconduzidos”, ou seja, ambas as atividades devem ser realizadas uma atrás da outra, para que modelos de projeto sejam provados conforme sejam criados. É difícil prever quanto de trabalho de projeto será necessário antes que seu desenvolvimento seja implementado para avaliar o projeto.3. Análise, projeto, desenvolvimento e testes não são tão previsíveis quanto gostaríamos que fossem segundo o ponto de vista do planejamento.

Em análise a esses pontos, surge a dúvida de como é possível administrar a imprevisibilidade. A resposta, conforme observado, consiste na adaptabilidade de processos, ou seja, um processo ágil deve ser adaptável.

Para se conseguir essa agilidade, segundo Pressman (2011, p.84), o grupo “Aliança dos ágeis” estabeleceu 12 princípios:

1. A maior prioridade é satisfazer o cliente por meio da entrega adiantada e contínua de software valioso.2. Acolha bem os pedidos de alterações, mesmo atrasados no desenvolvimento. Os processos ágeis se aproveitam das mudanças como uma vantagem competitiva na relação com o cliente.3. Entregue o software em funcionamento frequentemente, de algumas semanas para alguns meses, dando preferência a intervalos mais curtos.4. O pessoal do comercial e os desenvolvedores devem trabalhar em conjunto diariamente ao longo de todo o projeto.5. Construa projetos em torno de indivíduos motivados. Dê a eles o ambiente e apoio necessários e confie neles para ter o trabalho feito.6. O método mais eficiente e efetivo de transmitir informações para e dentro de uma equipe de desenvolvimento é uma conversa aberta, de forma presencial.7. Software em funcionamento é a principal medida de progresso.8. Os processos ágeis promovem desenvolvimento sustentável. Os proponentes, desenvolvedores e usuários devem estar capacitados para manter um ritmo constante indefinidamente.9. Atenção contínua para com a excelência técnica e para com bons projetos aumenta a agilidade.10. Simplicidade, a arte de maximizar o volume de trabalho não efetuado, é essencial.11. As melhores arquiteturas, requisitos e projetos emergem de equipes que se auto-organizam.12. A intervalos regulares, a equipe se avalia para ver como tornar-se mais eficiente, então sintoniza e ajusta seu comportamento de acordo.

32


O autor ressalta que nem todo modelo de processo ágil aplica esses 12 princípios de maneira igual, adequando-se e priorizando um ou outro princípio. Entretanto, os princípios definem um espírito ágil mantido em cada um dos modelos de processo.

2.1 FATORES HUMANOS

Os defensores das metodologias ágeis de desenvolvimento esforçam-se para reforçar a importância dos “fatores humanos”. Pressman (2011) afirma que o desenvolvimento ágil foca talentos e habilidades de indivíduos, moldando o processo de acordo com as pessoas e equipes específicas. Abaixo listaremos algumas características ou traços-chave que uma pessoa de uma equipe ágil e a equipe em si devem possuir.

Competência: Abrange talentos inatos, habilidades específicas relacionadas a software e conhecimento generalizado do processo que a equipe escolheu para aplicar. Habilidade e conhecimento de processo podem e devem ser ensinados para todas as pessoas que sejam membros de uma equipe ágil.

Foco comum: Embora os membros de uma equipe ágil possam realizar tarefas e tenham habilidades diferentes em um projeto, todos devem estar focados em um único objetivo: entregar um incremento de software funcionando ao cliente, dentro do prazo estipulado. Para atingir essa meta, a equipe também irá focar em adaptações contínuas (pequenas e grandes) que farão com que o processo se ajuste às necessidades da equipe.

Colaboração: Criar informações que ajudarão todos os envolvidos a compreender o trabalho da equipe e a construir informações (software para computadores e banco de dados relevantes) que forneçam valor de negócio para o cliente. Para realizar essas tarefas, os membros da equipe devem colaborar entre si, e com todos os demais envolvidos.

Habilidade à tomada de decisão: Ter liberdade para controlar seu próprio destino, ou seja, a equipe deve ter autonomia, autoridade na tomada de decisões. Tanto nos assuntos técnicos como de projetos.

Habilidade de solução de problemas confusos: Os gerentes de software devem reconhecer que a equipe ágil terá de lidar continuamente com ambiguidade e que será continuamente atingida por mudanças. Em alguns casos, a equipe tem de aceitar o fato de que o problema que eles estão solucionando hoje talvez não seja o problema que necessita ser solucionado amanhã. Entretanto, lições aprendidas de qualquer atividade de solução de problemas podem ser futuramente benéficas para a equipe no projeto.

33


Confiança mútua e respeito: Deve ser uma equipe consistente, pois demonstra confiança e o respeito necessário para torná-la fortemente unida. O todo é maior que a soma das partes.

Auto-organização: No contexto do desenvolvimento ágil, a auto-organização implica três fatores:

1. A equipe ágil se organiza para o trabalho a ser feito;2. A equipe organiza o processo para melhor se adequar ao seu ambiente local;3. A equipe organiza o cronograma de trabalho para melhor cumprir a entrega do incremento de software.

FONTE: Disponível em: <https://www.passeidireto.com/arquivo/16282034/engenharia-de-software---uma-abordagem-profissional----7-edicao/35>. Acesso em: 11 abr. 2016.

A auto-organização possui uma série de benefícios técnicos, mas o mais importante é o fato de servir para melhorar a colaboração e levantar o moral da equipe. Vale ressaltar que a equipe faz seu próprio gerenciamento, pois seleciona quanto trabalho acredita ser capaz de realizar dentro da iteração e se compromete com o trabalho. É extremamente desmotivador para o conjunto um terceiro assumir compromissos por ele.

2.2 METODOLOGIAS ÁGEIS DE DESENVOLVIMENTO DE SOFTWARE

Como foi visto até agora, as metodologias ágeis têm o objetivo de acelerar o desenvolvimento do software visando a melhoria contínua do processo, gerando benefícios como o aumento da comunicação e interação da equipe, organização diária para o alcance da meta definida, evitar falhas na elaboração, respostas rápidas às mudanças e aumento significativo da produtividade. A seguir, algumas metodologias de desenvolvimento ágil.

• Extreme Programming XP.• Desenvolvimento de Software Adaptativo (ASD).• Scrum.• Método de Desenvolvimento de Sistemas Dinâmicos (DSDM).• Crystal.• Desenvolvimento Dirigido à Funcionalidade (FDD).• Desenvolvimento de Software Enxuto (LSD).• Modelagem Ágil (AM).• Processo Unificado Ágil (AUP).• Rational Unified Process (RUP).

34


2.2.1 Extreme Programming (programação extrema) XP

Em seu livro, Pressman (2011, p.87) define um conjunto de cinco valores que estabelecem as bases para todo o trabalho realizado com parte da XP, onde cada um deles é usado como um direcionador das atividades, ações e tarefas específicas da XP:

• Comunicação• Simplicidade• Feedback (realimentação ou retorno)• Coragem e• Respeito.

A Extreme Programming emprega uma abordagem orientada a objetos como seu paradigma de desenvolvimento preferido e envolve um conjunto de regras e práticas constantes no contexto de quatro atividades metodológicas, que são: planejamento, projeto, codificação e testes. A Figura 17 ilustra o processo e destaca alguns conceitos e tarefas-chave associados a cada uma das atividades metodológicas.

FIGURA 17 - EXTREME PROGRAMMING


Segundo Sommerville (2011, p.44), em um processo XP os clientes estão intimamente envolvidos na especificação e priorização dos requisitos do sistema. Os requisitos não estão especificados como uma lista de funções requeridas do

35


sistema. Pelo contrário, o cliente do sistema é parte da equipe de desenvolvimento e discute cenários com outros membros da equipe. Juntos eles desenvolvem um “cartão de história” englobando as necessidades do cliente.

FIGURA 18 - DESENVOLVIMENTO XP

FONTE: Sommerville (2011, p.45)

2.2.2 Desenvolvimento de Software Adaptativo (ASD)

É uma técnica para a construção de software e sistemas complexos. As bases se concentram na colaboração humana e na auto-organização das equipes. Nesta técnica de desenvolvimento define-se um ciclo de vida que incorpora três fases: especulação, colaboração e aprendizagem.

Princípio ou prática Descrição

Planejamento incremental

Os requisitos são gravados em cartões de história e as histórias que serão incluídas em um release são determinadas pelo tempo disponível e sua relativa prioridade. Os desenvolvedores dividem essas histórias em 'Tarefas'. Veja quadro 3.1 e 3.2.

Pequenos releasesEm primeiro lugar, desenvolve-se um conjunto mínimo de funcionalidades útil, que fornece o valor do negócio. Releases do sistema são frequentes e gradualmente adicionam funcionalidade ao primeiro release.

Projeto simples Cada projeto é realizado para atender às necessidades atuais e nada mais.

Desenvolvimento test-first

Um framework de testes iniciais automatizados é usado para escrever os testes para uma nova funcionalidade antes que a funcionalidade em si seja implementada.

RefatoraçãoTodos os desenvolvedores devem refatorar o códio continuamente assim que encontrarem melhorias de código. Isso mantém o código simples e manutenível.

Programação em pares

Os desenvolvedores trabalham em pares, verificando o trabalho dos outros e prestando apoio para um bom trabalho sempre.

Propriedade Coletiva

Os pares de desenvolvedores trabalham em todas as áreas do sistema, de modo que não se desenvolvam ilhas de expertise. Todos os conhecimentos e todos os desenvolvedores assumem responsabilidade por todo o código. Qualquer um pode mudar qualquer área.

Integração contínuaAssim que o trabalho em uma tarefa é concluído, ele é integrado ao sistema como um todo. Após essa integração, todos os testes de unidade do sistema devem passar.

Ritmo sustentávelGrandes quantidades de horas-extras não são consideradas aceitáveis, pois o resultado final, muitas vezes, é a redução da qualidade do código e da produtividade a médio prazo.

Cliente no localUm representante do usuário final do sistema (o cliente) deve estar disponível todo o tempo à equipe de XP. Em um processo de Extreme Programming, o cliente é um membro da equipe de desenvolvimento e é responsável por levar a ela os requisitos de sistema para implementação.

36


FIGURA 19 - DESENVOLVIMENTO DE SOFTWARE ADAPTATIVO (ASD)

FONTE: Pressman (2011, p.94)

2.2.3 Scrum

Os princípios do Scrum são consistentes com o manifesto ágil e são usados para orientar as atividades de desenvolvimento dentro de um processo que incorpora as seguintes atividades estruturais: Requisitos, análise, projeto, evolução e entrega. Em cada atividade metodológica ocorrem tarefas a realizar dentro de um padrão de processo chamado Sprint. O fluxo geral do processo de Scrum é ilustrado na Figura 20.

37


FIGURA 20 - DESENVOLVIMENTO SCRUM


Segundo o guia do Scrum (2013, p. 4), ele é baseado nas teorias empíricas de controle de processo, ou empirismo. O empirismo garante que o conhecimento vem da experiência e de tomada de decisões baseadas no que é conhecido. O Scrum emprega uma abordagem iterativa e incremental para aperfeiçoar a previsibilidade e o controle de riscos.

São três os pilares que apoiam a implementação de controle de processo empírico: transparência, inspeção e adaptação, que detalharemos a seguir:

Transparência: Aspectos significativos do processo devem estar visíveis aos responsáveis pelos resultados. Esta transparência requer aspectos definidos por um padrão comum para que os observadores compartilhem um mesmo entendimento do que está sendo visto.Por exemplo:• Uma linguagem comum referindo-se ao processo deve ser compartilhada por todos os participantes; e,• Uma definição comum de “Pronto” deve ser compartilhada por aqueles que realizam o trabalho e por aqueles que aceitam o resultado do trabalho.Inspeção: Os usuários Scrum devem, com frequência, vistoriar os artefatos Scrum e o desenvolvimento em direção a detectar variações. Esta inspeção não deve, no entanto, ser tão frequente que atrapalhe a própria execução das tarefas. As inspeções são mais benéficas quando realizadas de forma diligente por inspetores especializados no trabalho a se verificar.

Esse assunto merece seu estudo, acesse http://www.scrumguides.org/docs/scrumguide/v1/Scrum-Guide-Portuguese-BR.pdf

DICAS

38


Adaptação: Se um inspetor determina que um (ou mais) aspectos de um processo desviou para fora dos limites aceitáveis, e que o produto resultado será inaceitável, o processo ou o material sendo produzido deve ser ajustado. O ajuste deve ser realizado o mais breve possível, para minimizar mais desvios.

O Scrum (2013, p.4) prescreve quatro eventos formais, contidos dentro dos limites da Sprint, para inspeção e adaptação, como descrito na seção Eventos do Scrum deste documento.

• Reunião de planejamento da Sprint• Reunião diária• Reunião de revisão da Sprint• Retrospectiva da Sprint

Steffen (2011) afirma que o Scrum não é um processo ou uma técnica, mas um framework que, quando usado puro ou em conjunto com demais práticas ou processos, promove maior flexibilidade, visibilidade e produtividade, além, é claro, de outros benefícios que ainda serão abordados. É importante que fique claro que Scrum não é uma abordagem prescritiva. Não é um processo previsível, ele não define o que fazer em toda circunstância. É uma ferramenta, um framework, um conjunto de práticas que torna tudo visível. O Scrum deixa muitas decisões a critério da equipe, porque acredita que a equipe sabe como melhor resolver algum problema apresentado, assim como quais práticas ela está madura suficiente para adotar. Ainda segundo a autora, os envolvidos em um projeto podem ser divididos em dois grupos:

• Stakeholders (interessados no produto, mas não comprometidos)• Time Scrum, que é composto do Product Owner, ScrumMaster e equipe de

desenvolvimento (7 + ou - 2, ou seja, de 5 até 9 pessoas).O Product Owner gerencia o product Backlog• Representa todos os demais stakeholders (cliente, usuários, representantes de

negócios, etc.). • Responsável por definir a funcionalidade do produto • Foco nos negócios. É responsável pelo gerenciamento do Product Backlog,

pelo ROI e prioridades. • Responsável pelo aceite do produto - resultado de cada Sprint. • Não é um comitê, mas uma única pessoa. • É o único responsável pela manutenção do Backlog. • Não pode ser o ScrumMaster • Define para onde o time deve ir mas não como chegar lá, não em qual

velocidade.

O ScrumMaster é quem gerencia o processo, ele é o facilitador da equipe e é responsável por:

• Garantir que os valores e as práticas do Scrum foram entendidos pelo time e estão sendo seguidos.

39


• Ensinar e treinar a equipe de forma que ela seja autogerenciável e multifuncional. • Ensinar/Garantir que o Product Owner também está desempenhando seu

trabalho. • Remover impedimentos (visíveis e não visíveis) (internos e externos). • Motivar e manter a saúde da equipe, trabalho em equipe, comunicação,

minimizando atritos e promovendo a cooperação.• Assegurar a melhoria contínua. • Gerenciar as expectativas. • Obter o comprometimento das partes (Stakeholders e Equipe).

O time de desenvolvimento se gerencia, sendo:

• Responsável por tornar os requisitos em um produto para o usuário. • Responsável pela entrega do produto e pela qualidade do mesmo. • Deve ser composto de todos os membros necessários para tomar decisões e

realizar as tarefas, ou seja, é multifuncional. • Responsável pela seleção, detalhamento das atividades e estimativas de

cada Sprint e pelo comprometimento do trabalho a ser executado, ou seja, é autogerenciado, nenhum gestor define quem irá realizar determinada tarefa. Eles se auto-organizam para realizar e terminar o prometido no prazo especificado.

• Compartilham as responsabilidades. • Trabalham como uma equipe para desenhar, codificar, testar e implementar o

produto de SW.• No Time Scrum não existe necessariamente uma divisão funcional através de

papéis tradicionais, tais como programador, designer, analista de testes ou arquiteto e troca de bastões.

• Todos no projeto trabalham juntos (colaboram) para completar o conjunto de trabalho com o qual se comprometeram conjuntamente para um Sprint.

FONTE: Disponível em: <https://www.ibm.com/developerworks/community/blogs/rationalbrasil/entry/scrum_basicamente14?lang=en>. Acesso em: 11 abr. 2016.

2.2.4 Método de Desenvolvimento de Sistemas Dinâmicos (DSDM)

Este método oferece uma metodologia para construir e manter sistemas que atendem restrições de prazo apertado através do uso de prototipagem incremental em um ambiente de projeto controlado. Baseia-se em uma versão modificada do princípio de Pareto, de que 80% de uma aplicação pode ser entregue em 20% do tempo que levaria a aplicação completa (100%).

Somente o trabalho suficiente é requisitado para cada incremento, para facilitar o movimento para o próximo incremento. Os detalhes remanescentes podem ser completados depois, quando outros requisitos de negócio forem conhecidos ou alterações tiverem sido solicitadas e acomodadas.

40


2.2.5 Crystal

Alistair Cockburn e Jim Highsmith criaram a família Crystal de métodos ágeis, visando conseguir elaborar uma abordagem de desenvolvimento de software que priorizasse a adaptabilidade (“maneuverability”) durante o que Cockburn caracteriza como um “jogo de invenção e comunicação cooperativo e com recursos limitados, tendo como primeiro objetivo entregar software útil em funcionamento e, como segundo, preparar-se para o jogo seguinte”, conforme Pressman (2011).Ainda segundo o autor, para conseguir a adaptabilidade os criadores definiram um conjunto de metodologias com elementos essenciais comuns a todas, mas com papéis, padrões de processos, produtos de trabalho e prática únicos para cada uma delas. Na verdade, a família Crystal é um conjunto de exemplos de processos ágeis que provaram ser efetivos para diferentes tipos de projetos. A intenção é possibilitar que equipes ágeis selecionem o membro da família Crystal mais apropriado para seu projeto e ambiente.

2.2.6 Desenvolvimento Dirigido a Funcionalidades (FDD)

Como outras abordagens ágeis, o FDD adota uma filosofia que enfatiza a colaboração entre as pessoas da equipe FDD; gerencia problemas e complexidade de projetos, utilizando a decomposição baseada em funcionalidades, seguida pela integração dos incrementos de software e comunicação de detalhes técnicos usando meios verbais, gráficos e de texto Pressman (2008, p.98).

A abordagem FDD define cinco atividades metodológicas “colaborativas”, conforme mostrado na Figura 21. Essa abordagem oferece maior ênfase às diretrizes e técnicas de gerenciamento de projeto do que muitos outros métodos ágeis.

41


FIGURA 21 - DESENVOLVIMENTO DIRIGIDO A FUNCIONALIDADES

Fonte: Pressman (2011, p. 98)

2.2.7 Desenvolvimento de Software Enxuto (LSD)

Esse método pode ser sintetizado em: eliminar desperdícios, incorporar qualidade, criar conhecimento, adiar compromissos, entregar rápido, respeitar as pessoas e otimizar o todo. Cada princípio pode ser adaptado ao processo de software.

2.2.8 Modelagem Ágil (AM)

Quando se fala em Modelagem Ágil, Pressman (2011) aponta que esta adota todos os valores consistentes com o Manifesto Ágil. Sua filosofia reconhece que uma equipe ágil deve ter a coragem de tomar decisões que possam causar a rejeição de um projeto e sua refabricação. A equipe também deve ter a humildade para reconhecer que os profissionais de tecnologia não possuem todas as respostas e que os experts em negócios e outros profissionais envolvidos devem ser respeitados e integrados ao processo.

O autor continua mostrando que Modelagem Ágil é particular no desenvolvimento de sistemas. Embora sugira uma ampla gama de princípios de modelagem essenciais e suplementares, os que a tornam única são:

• Modele com um objetivo.• Use modelos múltiplos.• Viajar leve.• Conteúdo é mais importante do que a representação.• Tenha conhecimento, domínio dos modelos e das ferramentas que for

utilizar.• Adapte localmente

42


2.2.9 Processo Unificado Ágil (AUP)

Adota, segundo Pressman (2011), a filosofia serial para o que é amplo e iterativa para o que é particular no desenvolvimento de sistemas. Adotando as atividades clássicas: início, elaboração, construção e transição. Essa metodologia fornece uma camada serial, ou seja, uma sequência linear de atividades, que capacita a equipe visualizar o fluxo do processo geral de um projeto de software. Entretanto, dentro de cada atividade, a equipe itera ou se repete para alcançar a agilidade e para entregar incrementos de software significativo para os usuários finais tão rapidamente quanto possível. Cada atividade dirige-se para as seguintes atividades: Modelagem, Implementação, Teste, Aplicação e Configuração.

2.2.10 Rational Unified Process (RUP)

Segundo Vianna (2016), a Rational é bem conhecida pelo seu investimento em Orientação a objetos. A empresa foi a criadora da Unified Modeling Language (UML), assim como de várias ferramentas que a suportam, sendo a mais conhecida o Rational Rose. O Rational Unified Process (RUP) é uma metodologia completa criada pela Rational para viabilizar que grandes projetos de software sejam bem-sucedidos. O RUP é na verdade um produto composto de material de referência na forma de páginas HTML, descrevendo toda a metodologia.

O RUP reconhece que os modelos de processo convencionais apresentam uma visão única do processo. Em contrapartida, o RUP é normalmente descrito em três perspectivas, segundo Sommerville (2011, p. 34):

1. Uma perspectiva dinâmica, que mostra as fases do modelo ao longo do tempo.2. Uma perspectiva estática, que mostra as atividades realizadas no processo.3. Uma perspectiva prática, que sugere boas práticas a serem usadas durante o processo.

O RUP adota as seguintes premissas básicas: Uso de iterações para evitar o impacto de mudanças no projeto, Gerenciamento de mudanças e Abordagens dos pontos de maior risco, o mais cedo possível. A estrutura básica do RUP é apresentada na Figura 22, o projeto passa por quatro fases básicas. Estas fases são, de acordo com Sommerville (2011, p.34):

• Concepção - entendimento da necessidade e visão do projeto,• Elaboração - especificação e abordagem dos pontos de maior risco,• Construção - desenvolvimento principal do sistema,• Transição - ajustes, implantação e transferência de propriedade do sistema.

43


FIGURA 22 - FASES RUP

FONTE: Disponível em: <http://www.devmedia.com.br/artigo-engenharia-de-software-o-processo-unificado-integrado-ao-desenvolvimento-web/8032>. Acesso em: 22 mar. 2016.

Em relação a essas fases, Vianna (2016) aponta que:

Apesar de parecer um modelo em cascata, na verdade cada fase é composta de uma ou mais iterações, o que se assemelha a um modelo em espiral. Estas iterações são em geral curtas (1-2 semanas) e abordam algumas poucas funções do sistema. Isto reduz o impacto de mudanças, pois quanto menor o tempo, menor a probabilidade de haver uma mudança neste período para as funções em questão.

A visão estática do RUP dá prioridade às atividades que ocorrem durante o processo de desenvolvimento. Segundo o RUP, essas são chamadas de workflows. Segundo Pressmman (2011, p. 34), existem seis workflows centrais, identificadas no processo, e três no de apoio, conforme mostra a Tabela 1.

44


TABELA 1 - WORKFLOWS ESTÁTICOS NO RUP

Workflow DescriçãoModelagem de

negóciosOs processos de negócios são modelados por meio de caso de uso de negócios.

RequisitosAtores que interagem com o sistema são identificados e casos de uso são desenvolvidos para modelar os requisitos do sistema.

Análise de projeto

Um modelo de projeto é criado e documentado com modelos de arquitetura, modelos de componentes, modelos de objetos e modelos de sequência.

Implementação

Os componentes do sistema são implementados e estruturados em subsistemas de implementação. A geração automática de código a partir de modelos de projeto ajuda a acelerar esse processo.

TesteO teste é um processo iterativo que é feito em conjunto com a implementação. O teste do sistema segue a conclusão da implementação.

Implantação Um release do produto é criado, distribuído aos usuários e instalado em seu local de trabalho.

Gerenciamento de configuração e

mudançasEsse workflow de apoio gerencia as mudanças do sistema.

Gerenciamento de projeto

Esse workflow de apoio gerencia o desenvolvimento do sistema.

Meio ambienteEsse workflow está relacionado com a disponibilização de ferramentas apropriadas para a equipe de desenvolvimento de software.

Fonte: Adaptado de Sommerville (2011, p. 35)

Os workflows de apoio são bem mais amplos em suas definições, pesquise e leiaa respeito em Sommerville (2011), capítulos 22, 23 e 25. Acesso à documentação do RUP em http://www.wthreex.com/rup/portugues/index.htm

DICAS

45


LEITURA COMPLEMENTAR

ANÁLISE COMPARATIVA DA UTILIZAÇÃO DO MODELO TRADICIONAL (WATERFALL) DE DESENVOLVIMENTO DE PROJETOS E O MODELO

ÁGIL (AGILE)EM FÁBRICAS DE SOFTWARE

Mario Augusto Rivas

Resumo: Nos últimos anos a utilização das metodologias ágeis na indústria da tecnologia da informação tem aumentando consideravelmente, devido entre outros fatores à alta produtividade e qualidade dos produtos elaborados. Neste cenário, fábricas de software que tradicionalmente utilizavam a metodologia tradicional nas iniciativas de desenvolvimento, estão começando a aplicar frameworks ágeis tais como Scrum ou XP. O presente artigo desenvolve uma análise comparativa entre o modelo tradicional (waterfall) e o modelo ágil no contexto das fábricas de software, destacando os principais tópicos que devem ser considerados na avaliação da metodologia, por meio de uma matriz comparativa.

Palavras-chave: Agile; Scrum; Waterfall; Fábrica de Software.

1 INTRODUÇÃO

A metodologia tradicional de desenvolvimento de software (waterfall) baseia-se numa sequência de estágios de produção independentes, que têm por objetivo entregar, ao final desta, o produto definido na fase inicial. Este processo linear de desenvolvimento é apontado como um dos responsáveis pelo baixo índice de sucesso dos projetos de software, em razão de atores tais como a imprevisibilidade dos requisitos, mudança continua do ambiente e a utilização de métodos orientados a processos em vez de pessoas.

As metodologias ágeis, em contrapartida, estão orientadas a flexibilizar a cadeia produtiva de software, no intuito de focalizar no produto em detrimento da burocracia do processo. Perante esta situação, surge nas fábricas de software a necessidade de entender a aplicabilidade destas metodologias como fator de vantagem competitiva dentro do contexto operacional e comercial.

a) Objetivo

O objetivo principal deste trabalho é comparar a implantação das principais premissas dos modelos tradicional (Waterfall) e ágil (Agile) nas fábricas de software, considerando a taxonomia e o contexto destas.

b) Problema

O problema de muitos artigos e trabalhos acadêmicos têm focalizado na problemática da migração do modelo tradicional para o modelo ágil, porém não foi possível achar artigos que tratem o processo de análise que antecede à

46


decisão estratégica de migrar. Alguns autores destacam a resistência que pode acontecer nas organizações que adotem o modelo ágil, por conta da incerteza inerente ao custo e duração do projeto, embora o modelo tradicional também não ofereça nenhuma assertividade nestes quesitos. Outros autores, concluem que “estrutura e culturas organizacionais orientadas à inovação podem se engajar mais facilmente no modelo ágil que as organizações construídas em base a burocracia e formalização. As organizações devem avaliar cuidadosamente se estão prontas para percorrer o caminho ágil”.

Dito processo decisório é influenciado não somente pelas diferencias estruturais dos modelos senão também pelo contexto da própria fábrica de software e do mercado, variáveis que não podem ser generalizadas.

A relevância deste trabalho reside em apresentar uma versão consolidada da comparação dos modelos tradicional e ágil, desde o ponto de vista funcional das fábricas de software, no intuito de facilitar a tomada de decisão nas organizações.

c) Hipótese

A hipótese sugerida é que a escolha de uma metodologia de desenvolvimento depende de fatores intrínsecos do projeto e da fábrica de software, e sua aplicabilidade não pode ser generalizada sem considerar o contexto interno e externo da organização.

A metodologia proposta para desenvolver este trabalho baseia-se na pesquisa bibliográfica tradicional do tipo conceitual, contemplando a gestão de fábricas de software e os modelos de gestão de desenvolvimento tradicional e ágil. Uma revisão bibliográfica tradicional conceitual busca sintetizar diferentes áreas de conhecimento conceitual, contribuindo para um melhor entendimento das questões.

d) Justificativa Fundamentada

O desenvolvimento de software nos últimos 30 anos evoluiu do conceito artesanal vinculado a indivíduos altamente técnicos trabalhando isoladamente, ao surgimento de fábricas de software com times colaborativos distribuídos globalmente.

As metodologias de desenvolvimento não acompanharam o mesmo ritmo de mudanças, gerando uma defasagem entre processo e tecnologia que só veio a ser evidenciada com a aparição dos modelos ágeis. Neste contexto as fábricas de software enfrentam a necessidade de adotar novas metodologias para evitar a perda de posicionamento no mercado, incluindo a utilização de modelos ágeis, eventualmente sem a devida avaliação organizacional prévia.

47


2 FÁBRICAS DE SOFTWARE

O desenvolvimento de software era originalmente uma tarefa realizada por técnicos individuais especializados na linguagem de programação, no sistema operacional e no próprio computador. A imprevisibilidade do desempenho dos programadores levou Robert Bemer a criar o termo “fábrica de software”, sugerindo a criação destas unidades nas organizações, utilizando suas próprias ferramentas e processos.

a) Origem e Definição

O conceito de “fábrica de software” evoluiu nos anos 1960 e 1970, nos Estados Unidos e no Japão. A primeira fábrica de software foi a Hitachi Software em 1969, pondo em prática a ideia dos executivos dessa empresa de separar o grupo de desenvolvimento de software do restante da empresa. Nos Estados Unidos a System Development Corp (SDC), que seria integrada à Unisys mais tarde, implantou na sua fábrica de software de Santa Monica uma organização baseada em três elementos: um conjunto integrado de ferramentas; procedimentos e políticas de gerenciamento padronizadas e uma organização matricial.

O termo “fábrica de software” pode ser definido como a organização previsível e controlada dos elementos que compõem o desenvolvimento de software, incluindo processos, recursos e conhecimento. Esta definição enquadra as fábricas de software numa dimensão maior do que simplesmente a produção de código fonte, abrangendo potencialmente fábricas de testes ou especificações, por exemplo.

b) Modelos operacionais

As fábricas de software podem ser classificadas de acordo com seu escopo de fornecimento. Fábricas dedicadas somente à codificação e teste unitário compõem o segmento menor nesta classificação, seguido em ordem crescente pelas fábricas de projetos físicos que incluem o desenho detalhado e os testes integrados e de aceitação, e pelas fábricas de projetos de software que abrangem todas as atividades desde o projeto conceitual. Fernandes ainda descreve um nível superior de “fábricas de projetos ampliadas”, cujos escopos transcendem a visão tecnológica. O modelo de outsourcing de sistemas como especialização da fábrica de projetos e a fábrica de componentes, também fazem parte desta classificação.

48


CLASSIFICAÇÃO DAS FÁBRICAS DE SOFTWARE

Todos os tipos de fábrica de software, independente da classificação, possuem processos definidos que atendem às necessidades da linha de produção. No caso das fábricas de programas, por exemplo, o processo central refere-se à construção e teste unitário dos programas, e deve estar baseado na adoção de alguns dos frameworks de mercado (waterfall, RUP, Scrum, etc.). Isto não é necessariamente válido para as fábricas de projetos de software, nas quais o processo central é o gerenciamento de projetos e os frameworks adotados são outros (PMBOK, PRINCE 2, etc.).

3 MODELO TRADICIONAL DE DESENVOLVIMENTO

Até meados dos anos 60 o papel do software foi secundário em relação ao hardware, na indústria da computação. Esta situação começou a mudar com a chegada das primeiras linguagens de programação teoricamente independentes do hardware (Fortran, Algol, Cobol, etc.), abrindo possibilidades para a reutilização do software e das técnicas de programação. No ano 1970 o Dr. Winston Royce publicou o artigo original que deu origem ao framework mais popular de desenvolvimento de software, chamado waterfall (cascata). Este modelo baseia-se na sequência de atividades padronizadas cujos resultados individuais são utilizados como pré-requisito para a atividade subsequente, graficamente descrito como uma cascata que começa com os requisitos do sistema e termina com a operação (execução) deste.

a) O Modelo de Gestão de Desenvolvimento do Dr. Winston Royce

Embora a adoção do modelo do Dr. Royce (waterfall) fosse quase total na comunidade do software, os conceitos nele expressados foram simplificados ou reduzidos num modelo linear conhecido como “cascata”.

49


MODELO WATERFALL

O desenho original do Dr. Royce envolve a iteração entre fases consecutivas do waterfall, no entendimento de que o resultado de cada fase pode ter impacto na fase anterior. Por exemplo, na fase de desenho podem ser encontrados elementos novos que impactem a análise feita, logo a fase de análise precisa ser revisitada. Isto pode parecer obvio no relacionamento entre as fases de teste e codificação, porém para o resto do processo não é considerado com fins de planejamento. Eventualmente o Dr. Royce destaca o risco inerente deste modelo: “Eu acredito neste conceito, mas a implementação descrita acima [waterfall] possui riscos e convida às falhas”.

Na opinião do autor do modelo, o maior risco é o fato de que as iterações transcendam as fases consecutivas e gerem uma revisão total do desenho (design), pois, caso exista uma incompatibilidade entre os novos requisitos e o desenho atual, as mudanças necessárias podem ser tão destrutivas, que impliquem em um completo redesenho do sistema.

A proposta do Royce para mitigar os riscos decorrentes do modelo é composta pelos seguintes passos:

1) criar uma fase de desenho preliminar do software antes da fase de análise; 2) gerar documentação abrangente do desenho; 3) a partir do desenho preliminar fazer uma simulação completa do processo

(flexibilizando os requisitos de documentação), para chegar num protótipo ou versão “1” que possa ser utilizada para o processo completo;

4) planejar, controlar e monitorar o teste e 5) envolver ao cliente.

a) Críticas ao Modelo Tradicional

50


Alguns autores argumentam que o método waterfall sempre foi efetivo em projetos com requisitos bem definidos, tecnologia bem conhecida e baixo risco geral. Neste contexto, o escopo, os requisitos, a tecnologia, as tarefas requeridas e os níveis de recursos são suficientemente previsíveis para que o projeto possa ser totalmente planejado antecipadamente. O modelo waterfall fundamentalmente assume que os “sistemas são totalmente especificáveis, previsíveis e podem ser feitos por meio de um meticuloso e extensivo planejamento”.

Estas premissas referidas pelos autores acima são claramente conflitantes com a realidade da grande maioria dos projetos de software nos quais o fator humano (originalmente menosprezado pelos metodologistas do software dos anos 60 e 70) revela-se como pouco previsível: “…esta técnica [waterfall] requer que todas as boas ideias apareçam ao começo do ciclo de desenvolvimento, estágio no qual podem ser incorporadas ao plano. Porém, como todos nós sabemos, as boas ideias aparecem espontaneamente ao logo do processo – no começo, na metade e mesmo um dia antes da implantação...Com a técnica waterfall, uma boa ideia que apareça tarde no ciclo de desenvolvimento não é um presente, é uma ameaça”.

4 MODELO ÁGIL

Em fevereiro de 2001, dezessete metodologistas do software “leve” e pensadores se reuniram para discutir e chegar a um consenso que refletisse suas ideias e conceitos em relação à situação atual do desenvolvimento de software. Entre eles estavam os cofundadores do Scrum, Jeff Sutherland e Ken Schwaber, junto com Mike Beedle que trabalhou nos padrões iniciais do Scrum e foi coautor do primeiro livro de Scrum. O grupo denominou-se ‘The Agile Alliance’ e estampou o acordo no documento ‘Manifesto for Agile Software Development’, influenciado pelas melhores práticas da indústria japonesa, particularmente pelos princípios de desenvolvimento enxuto (lean) de empresas como Toyota e Honda.

a) O Manifesto Ágil

Longe de ser uma guia metodológica ou um framework, o Manifesto Ágil é considerado uma intenção manifesta e coletiva dos seus autores, de impulsionar uma visão inovadora na engenharia de software: “Estamos descobrindo maneiras melhores de desenvolver software, fazendo-o nós mesmos e ajudando outros a fazerem o mesmo. Por meio desse trabalho, passamos a valorizar: Indivíduos e interações mais que processos e ferramentas. Software em funcionamento mais que documentação abrangente. Colaboração com o cliente mais que negociação de contratos. Responder a mudanças mais que seguir um plano. Ou seja, mesmo havendo valor nos itens à direita (do termo ‘mais que’), valorizamos mais os itens à esquerda. ”.

Este enfoque da disciplina do desenvolvimento de software, radicalmente oposto à crença tradicional que enxerga a eficiência na produção de sistemas como fruto da evolução dos processos de engenharia, teve de enfrentar vários paradigmas até então considerados axiomáticos entre a comunidade.

51


Claro exemplo desta situação é o reconhecimento tácito da dinâmica dos requisitos enunciada anos antes no princípio de incerteza dos requisitos de Humphrey: “para um sistema de software, novo os requisitos não serão completamente conhecidos até depois que os usuários o tenham utilizado”. O Manifesto Agile não só reconhece esta situação, mas também assume a necessidade de integrar as mudanças de requisitos em todo o processo de desenvolvimento, visando colaborar com o cliente na obtenção da melhor vantagem competitiva. Outro paradigma questionado por este movimento refere ao papel do cliente no processo de desenvolvimento, que tradicionalmente estava delimitado a definir os requisitos de negócio e receber o produto já terminado no outro extremo da cadeia de produção. O Manifesto Agile sugere a participação diária do cliente durante todo o processo, não só definindo os requisitos como também participando das decisões que afetam o produto a ser criado.

Nos anos subsequentes à criação da Agile Alliance, surgiram em Europa e nos Estados Unidos diversos frameworks de desenvolvimento, orientados a difundir o Manifesto Agile nas organizações, dos quais o mais popular até hoje é o Scrum.

b) Scrum

De acordo com um dos criadores, o Scrum é um framework simples utilizado para organizar as equipes e fazer o trabalho de forma mais produtiva e com alta qualidade. A origem do termo refere a uma formação clássica do rugby, na qual um grupo pequeno, coeso e organizado de jogadores, consegue elencar os esforços individuais num objetivo comum. O Scrum focaliza na geração do valor agregado para o cliente, eliminando o desperdiço e priorizando a entrega periódica de software funcional. Essa entrega periódica decorre da estrutura iterativa do processo, conformada por períodos de duas (2) a quatro (4) semanas chamados Sprints, cada um dos quais se encerra com a entrega de um incremento no produto final.

O Scrum possui três (3) papéis, três (3) cerimônias e três (3) artefatos. O Product Owner (dono do produto) tem como responsabilidade definir os requisitos do produto; decidir a data de implantação e o conteúdo; priorizar os requisitos de acordo ao valor agregado e aceitar ou rejeitar os resultados do trabalho. Embora o framework não inclua a participação de um gerente de projeto, o papel de líder da equipe é adjudicado ao Scrum Master, quem deve atuar como um facilitador assegurando que a equipe esteja produtiva e funcional; removendo barreiras e blindando a equipe de interferências externas, além de assegurar que o framework seja seguido. O terceiro papel é a própria equipe de desenvolvimento, que tem por responsabilidades a produção do trabalho, sendo auto-organizada em todos os aspectos.

O Scrum prevê uma cerimônia ou reunião ao começo de cada iteração denominada Sprint Planning, na qual são definidos os requisitos que a equipe irá entregar ao final do sprint. Vale ressaltar que as reuniões do Scrum têm sido chamadas de cerimônias pelos praticantes deste framework no Brasil, pois os treinamentos oficiais têm usado majoritariamente essa terminologia. Todos os

52


dias durante o sprint acontece a reunião diária de alinhamento conhecida como Daily Scrum Meeting, geralmente feita numa sala sem cadeiras (standup meeting ou reunião em pé) para estimular a objetividade da reunião. O objetivo desta é que cada membro da equipe responda as perguntas:

a) O que foi feito ontem? b) O que será feito hoje?c) Quais os problemas que estão sendo enfrentados?

A terceira cerimônia requerida pelo Scrum é o Sprint Review Meeting, que tem por objetivos revisar o que está sendo entregue ao cliente e analisar o funcionamento da equipe durante o sprint, também chamado de Sprint Retrospective.

Alinhado com as premissas do Manifesto Agile que priorizam o software em funcionamento mais que a documentação abrangente, Scrum exige somente três (3) artefatos documentais: o Product Backlog que contém os requisitos ainda não criados do produto, o Sprint Backlog descrevendo os requisitos a serem desenvolvidos no sprint e o Burndown Chart, gráfico que expõe o avanço na execução dos requisitos ao longo do sprint e serve como status do projeto.

O CICLO DO SCRUM

53


c) Aplicabilidade do Scrum em projetos de grande escala e missão crítica Embora existam numerosos casos de sucesso em implantações de Scrum,

ainda persistem na comunidade acadêmica e na indústria de tecnologia de informação dúvidas respeito à aplicabilidade deste framework em projetos de grande escala e/ou missão crítica. Alguns autores argumentam que a maioria dos projetos desenvolvidos com Scrum é de pequena escala e relativamente simples, com grande sucesso. Entretanto, existem poucos e muito limitados estudos referentes à aplicabilidade do Scrum em grandes projetos.

Na opinião dos autores, ainda não existem dados conclusivos para determinar a aplicabilidade do framework neste tipo de projetos, porém sugerem os seguintes pontos a serem considerados:

• Investir tempo na composição idônea das equipes, considerando os projetos nos quais trabalharão.

• Escolher um Scrum Master que não só remova os impedimentos para avançar no projeto, senão que seja capaz de gerenciar a consistência do produto horizontalmente entre os times do projeto.

• Dedicar suficiente tempo para o planejamento e desenho.• Adaptar o framework de acordo à natureza do projeto.

Outra dimensão importante que deve ser considerada em projetos de grande escala advém do fato comum na indústria de software de terceirizar segmentos do desenvolvimento, muitas vezes para locações distantes geograficamente como Índia e China. Os autores sugerem a adaptação eventual do framework ágil escolhido para resolver problemas decorrentes da separação dos times. “As práticas ágeis modificadas resolvem este problema [a separação geográfica] dissolvendo algumas das práticas do framework enquanto se mantém a essência dos princípios e valores ágeis, e fornecendo uma nova estrutura de colaboração. Esta nova estrutura não é burocrática, porem pode ser ajustada em base às necessidades e níveis de confiança da organização”.

5 ANÁLISE COMPARTIVA DOS MODELOS

De acordo com o exposto anteriormente, o modelo ágil para gestão do desenvolvimento possui diferenças significativas em relação ao modelo tradicional ou waterfall, às quais serão explicitadas em relação aos tipos de fábricas de software propostos.

a) Gestão dos Requisitos e Escopo

O modelo tradicional tem como premissa a preexistência dos requisitos do cliente detalhados e completos, assumindo que todo o contexto pode ser definido a priori pelo demandante, i.e. o cliente. Os requisitos no modelo ágil são dinâmicos e podem ser modificados durante todo o processo de desenvolvimento. “Mudanças nos requisitos são bem-vindas, mesmo tardiamente no desenvolvimento. Processos ágeis tiram vantagem das mudanças com o propósito de alcançar vantagem

54


competitiva para o cliente”. Embora o impacto da gestão dos requisitos seja maior para fábricas de programas ou componentes, em geral é o modelo comercial destas que define o impacto real. Modelos de contratação “fixed price/fixed time” são claramente os mais afetados.

b) Processo e Controle

O Manifesto Ágil prioriza as interações e os indivíduos perante as ferramentas e os processos. Neste ponto a diferença em relação ao modelo tradicional se manifesta claramente, devido ao fato deste último ser totalmente atrelado a processos estritos, similares a uma linha de produção industrial. A necessidade de reconhecer o indivíduo como elemento fundamental da produção no modelo ágil, se contrapõe à visão mecanicista do modelo tradicional, na qual a aderência aos processos de engenharia é a chave do sucesso. Isto se reflete também nos perfis de liderança sugeridos pelas metodologias baseadas nos modelos tradicional e ágil. Enquanto no modelo tradicional a liderança é manifesta através do comando e controle, normalmente personificado no papel do Gestor do Projeto (Project Manager), o Scrum define o Scrum Master como um papel de facilitador que ajuda ao time alcançar as metas e que tem escassa autoridade formal.

c) Envolvimento do Cliente

No modelo tradicional o cliente cumpre um papel importante no começo e no fim do projeto, quando são feitas as definições dos requisitos e a homologação dos resultados, respectivamente. Muito pelo contrário, nos projetos gerenciados no modelo ágil, o cliente é um papel fundamental, participando ativamente ao longo de todo o processo.

Por definição, as fábricas de software são estruturas lógicas isoladas das áreas de negócios ou incluso empresas externas à organização cliente, motivo pelo qual o envolvimento direto do cliente acontece (geralmente) nos eventos administrativos padrão (contratação, pagamentos, etc.). A vinculação permanente dentro do processo da fábrica, como sugere o modelo ágil, envolve certo grau de dificuldade para as fábricas externas à organização cliente, e se faz pouco produtivo para fábricas de menor porte (programas, componentes e projeto físico).

d) Gestão da Documentação

Segundo o Manifesto Agile, a prioridade sempre é o software em funcionamento, mais que a documentação extensiva, logo a gestão da documentação ocupa um lugar menos importante na gestão do projeto, até mesmo porque o próprio código gerado deve servir como documentação tácita. Contrariamente, o modelo tradicional adota uma política de documentação explícita.

“Ocasionalmente sou solicitado para revisar o progresso de outros desenhos de software. Meu primeiro passo é investigar o estado da documentação. Se a documentação está em falta minha primeira recomendação é simples. Substitua o gerente do projeto. Pare todas as atividades que não sejam relacionadas

55


à documentação. Coloque a documentação no padrão adequado. A gestão do software é simplesmente impossível sem um grande volume de documentação”.

Para as fábricas de programas ou componentes, a documentação é de caráter técnico e mudanças do modelo tradicional para o modelo ágil não deveriam representar maiores impactos. Enquanto aos outros tipos de fábrica de software, o impacto é diretamente proporcional à complexidade e diversidade das atividades nelas desenvolvidas.

e) Matriz de Comparação

A Tabela 1 exibe um resumo dos impactos decorrentes da aplicação das premissas acima discutidas, nos distintos tipos de fábrica de software.

56


IMPACTO COMPARATIVO DA ADOÇÃO DAS PREMISSAS DOS MODELOS TRADICIONAL E AGILE NOS DISTINTOS TIPOS DE FÁBRICA DE SOFTWARE.

CONCLUSÃO

Nos últimos anos observou-se uma tendência importante de adoção das metodologias ágeis no mercado das fábricas de software. Numerosos trabalhos acadêmicos tem abordado esta temática do ponto de vista operacional, porém nem sempre a comparação entre os modelos tradicional e Agile foi contextualizada no conceito de fábrica de software. As fábricas podem ser classificadas segundo o escopo de atuação em fábricas de programas e/ou componentes, fábricas de projetos físicos, fábricas de projetos de software e/ou outsourcing, e fábricas de projetos ampliadas. O modelo tradicional desenvolvido a partir do trabalho de Royce, mais conhecido como Waterfall ou cascata, foi durante muitos anos o

57


padrão para a gestão do desenvolvimento. Sua estrutura linear, semelhante a uma linha de produção industrial, e fortemente separada em etapas isoladas, facilitou sua rápida assimilação. À medida que a engenharia de software evoluiu, falhas importantes foram encontradas neste modelo, originárias em suas premissas relativas à imutabilidade dos requisitos decorrente do modelo linear. Em resposta a essa situação, um grupo de metodologista de software redigiu o Manifesto Agile, definindo as bases conceituais do modelo ágil. Este modelo prioriza a interação e as pessoas, mais que as ferramentas e os processos, o software em funcionamento mais que documentação abrangente, colaboração com o cliente mais que negociação de contratos e resposta às mudanças mais que seguir o plano. O modelo ágil reconhece que os requisitos vão mudar constantemente ao longo do processo de desenvolvimento, em parte devido à própria natureza dos seres humanos que trabalham nele, e faz questão de aproveitar a evolução dos requisitos para entregar um produto de maior valor para o cliente.

Na comparação entre os dois modelos surgiram quatro (4) tópicos de destaque: gestão de requisitos, processos e controle, envolvimento do cliente e gestão da documentação. Para cada um destes, foi feita uma comparação contextualizada em cada tipo de fábrica de software (representada na Tabela 1) e ponderada segundo o impacto que teria para ser implantada em cada instância. Foi constatado que as fábricas de programas/componentes não apresentam vantagens importantes na adoção das premissas do modelo ágil; pelo contrário, em razão do escopo reduzido de atuação, fatores como a estabilidade dos requisitos resultam muito favoráveis. Contrariamente, as mesmas premissas aplicadas às fábricas de projetos físicos sugerem um panorama mais favorável para o modelo ágil por conta da flexibilidade dos processos e da redução da documentação. Esta tendência se intensifica no caso das fábricas de projetos de software e das fábricas de software ampliada, nas quais o envolvimento do cliente.

Em razão das limitações deste artigo, grandes generalizações foram assumidas na criação da matriz comparativa, motivo pelo qual as recomendações nela contidas não devem se considerar como regra geral senão como elemento de contexto na tomada de decisões estratégica. Elementos como o modelo comercial da organização, regulamentações locais e contexto tecnológico, não foram avaliados explicitamente, porém são fatores decisórios importantes na escolha do modelo de desenvolvimento da fábrica de software. De acordo ao exposto como hipótese na introdução deste artigo, confirma-se que a escolha de uma metodologia de desenvolvimento depende de fatores intrínsecos do projeto e da fábrica de software, e sua aplicabilidade não pode ser generalizada sem considerar o contexto interno e externo da organização. A matriz de comparação exposta neste artigo deve servir como marco de referência para dita escolha, sendo um elemento passível de ser detalhado em futuros trabalhos acadêmicos.

a) Implicações e Recomendações para a Prática

A análise apresentada neste trabalho revela a importância de considerar o escopo da fábrica de software em cada um dos fatores comparados, na escolha do modelo de gestão do desenvolvimento. Desta forma, surge uma primeira

58


recomendação implícita para evitar o reducionismo de analisar somente o modelo per se no processo decisório, sem contextualizar adequadamente na estrutura da fábrica. Recomenda-se também a utilização (sujeita a adaptações) da matriz de comparação desenvolvida neste trabalho, como ferramenta de abstração e benchmarking para a tomada de decisões respeito ao modelo.

b) Limitações do Estudo

Como mencionado anteriormente, existem diversos fatores comerciais, tecnológicos e regulatórios no contexto da fábrica de software, que não foram adequadamente considerados neste trabalho por conta das limitações de espaço predefinidas.

Outra limitação conhecida deste trabalho refere à possibilidade de modelos híbridos entre os modelos tradicional e ágil durante a fase de migração, como sugerido por Cohn. Esta opção foi propositalmente excluída do escopo da análise apresentada neste artigo, no intuito de manter o foco no objetivo da comparação.

Cabe destacar também a ausência neste artigo de casos de estudo diretos apoiando a pesquisa bibliográfica, relativizando os resultados ao marco teórico.

c) Sugestões de Pesquisas Futuras

Conforme destacado nas limitações do estudo, a ausência de casos práticos impõe restrições às conclusões deste trabalho. Uma primeira sugestão é a ampliação do escopo deste artigo com a inclusão de casos de estudo significativos, a fim de estender e validar a análise comparativa dos modelos.

Uma segunda linha de pesquisa recomendada refere-se ao impacto comercial e financeiro da migração do modelo tradicional para ágil nas fábricas de software, na expectativa de aportar conclusões valiosas num segmento muito pouco explorado pela bibliografia disponível. Um trabalho dessa natureza visa responder questões centrais para os responsáveis das decisões estratégicas nas fábricas de software, que transcendem os aspectos intrínsecos da engenharia.

FONTE: Disponível em: http://www.revistas.unifacs.br/index.php/rsc. Acesso em: 22 mar. 2016.

59

RESUMO DO TÓPICO 3


• As metodologias ágeis priorizam a comunicação e interação dentre os participantes do projeto. Têm o objetivo de acelerar o desenvolvimento do software visando à melhoria contínua do processo, organização diária para o alcance da meta definida, evitar falhas na elaboração, respostas rápidas às mudanças e aumento significativo da produtividade.

• Vimos também os 12 princípios ágeis:

a) A maior prioridade é satisfazer o cliente por meio da entrega adiantada e contínua de software valioso.

b) Acolha bem os pedidos de alterações, mesmo atrasados no desenvolvimento.Os processos ágeis se aproveitam das mudanças como uma vantagem competitiva na relação com o cliente.

c) Entregue o software em funcionamento frequentemente, de algumas semanas para alguns meses, dando preferência a intervalos mais curtos.

d) O pessoal do comercial e os desenvolvedores devem trabalhar em conjunto diariamente ao longo de todo o projeto.

e) Construa projetos em torno de indivíduos motivados. Dê a eles o ambiente e apoio necessários e confie neles para ter o trabalho feito.

f) O método mais eficiente e efetivo de transmitir informações para e dentro de uma equipe de desenvolvimento é uma conversa aberta, de forma presencial.

g) Software em funcionamento é a principal medida de progresso.h) Os processos ágeis promovem desenvolvimento sustentável. Os proponentes,

desenvolvedores e usuários devem estar capacitados para manter um ritmo constante indefinidamente.

i) Atenção contínua para com a excelência técnica e para com bons projetos aumenta a agilidade.

j) Simplicidade, a arte de maximizar o volume de trabalho não efetuado, é essencial.

k) As melhores arquiteturas, requisitos e projetos emergem de equipes que se auto-organizam.

l) A intervalos regulares, a equipe se avalia para ver como tornar-se mais eficiente, então sintoniza e ajusta seu comportamento de acordo.

• Apresentamos uma breve descrição dos métodos ágeis mais conhecidos:

a)Extreme Programming XP b)Desenvolvimento de Software Adaptativo (ASD) c)Scrum d)Método de Desenvolvimento de Sistemas Dinâmicos (DSDM) e)Crystal

60

f)Desenvolvimento Dirigido a Funcionalidades (FDD) g)Desenvolvimento de Software Enxuto (LSD) h)Modelagem Ágil (AM) i)Processo Unificado Ágil (AUP) j)Rational Unified Process (RUP)

61

1 De acordo com a estrutura básica do RUP, o projeto passa por quatro fases básicas. Faça a associação correta para: Concepção, Elaboração, Construção e Transição.

_____________ Entendimento da necessidade e visão do projeto._____________ Desenvolvimento principal do sistema._____________ Especificação e abordagem dos pontos de maior risco._____________ Ajustes, implantação e transferência de propriedade do sistema.

2 Observe o modelo XP e o modelo SCRUM, e a seguir descreva o que é possível determinar.

3 Explique quais são as premissas e as fases do RUP.

4 As metodologias ágeis de desenvolvimento esforçam-se para reforçar a importância das pessoas no desenvolvimento, elas focam talentos e habilidades de indivíduos, moldando o processo de acordo com as pessoas e equipes específicas. Cite algumas dessas características.

5 O RUP é composto por três tipos de visões, a dinâmica, a prática e a estática. Comente a respeito do que acontece em cada uma das etapas centrais.

AUTOATIVIDADE

63

UNIDADE 2

ENGENHARIA DE REQUISITOS E EQUIPE DE DESENVOLVIMENTO


PLANO DE ESTUDOS

Esta unidade tem por objetivos:

• reconhecer a importância da análise de requisitos no processo de desen-volvimento;

• perceber as diferentes etapas que fazem parte da engenharia de requisitos;

• realizar de forma consistente a atividade de análise de requisitos;

• conhecer os integrantes das equipes de desenvolvimento.

Está unidade está dividida em três tópicos. Em cada um deles você encon-trará atividades que contribuirão para a apropriação dos conteúdos apresen-tados.

TÓPICO 1 - ENGENHARIA DE REQUISITOS

TÓPICO 2 - TÉCNICAS DE LEVANTAMENTO

TÓPICO 3 - DESENVOLVIMENTO E EQUIPE DE SOFTWARE

65

TÓPICO 1

ENGENHARIA DE REQUISITOS

UNIDADE 2

1 INTRODUÇÃO

Estamos sempre em movimento, mudando de opinião, de visual, de estado civil e até mesmo de cidade. Com os softwares, isso também acontece. Você acredita que os requisitos de um sistema permanecem inalterados ao longo do tempo? Por exemplo, um projeto iniciado em janeiro terá os mesmos requisitos ao final de 12 meses?

Existem grandes chances de isso não acontecer, e os motivos são os mais variados. Pode ser causado por uma mudança de hardware, a correção de um erro, uma nova lei, ou simplesmente uma nova função a ser desenvolvida. E para que essa mudança ou construção atenda com satisfação às necessidades do cliente, a equipe de analistas precisa conhecer bem os objetivos a que se destina o software, entender o negócio e conhecer os usuários. Esse conhecimento é de extrema importância para que, na coleta de requisitos, a equipe de análise compreenda os problemas e busque, por meio de metodologia própria, solucioná-los. Mas, o que são requisitos?

Nos estudos desta unidade você vai encontrar apoio para responder a essa e a outras questões relacionadas a esse processo envolvendo os requisitos do sistema.

2 ENGENHARIA DE REQUISITOS

De uma maneira simplificada, os requisitos expressam o que o futuro sistema deve fazer para que atenda aos usuários, além, é claro, das restrições e características.

Requisito também pode ser definido como a condição ou capacidade de um software que deve ser implementada por um sistema ou componentes de sistema para que o objetivo seja por fim alcançado, segundo Engholm Jr. (2010). Ainda de acordo com o autor, todo o projeto de software tem um conjunto de requisitos, que são definidos pelas necessidades e expectativas dos usuários que efetivamente usarão o software, relacionados ao atendimento dos objetivos de negócio da empresa com que trabalham.

Durante a fase de levantamento de requisitos é o momento em que as necessidades são exploradas por parte do desenvolvedor em companhia do cliente

UNIDADE 2 | ENGENHARIA DE REQUISITOS E EQUIPE DE DESENVOLVIMENTO

66

e sua empresa. Para que essa etapa seja realizada com uma proposta de solução adequada, é necessário que tarefas, como o estudo de viabilidade, licitação e análise de requisitos, especificação e gerenciamento destes, sejam realizadas de forma cuidadosa e consistente.

Para Sommerville (2011), os requisitos de um sistema são as descrições do que o sistema deve fazer, os serviços que o sistema oferece, bem como as restrições a seu funcionamento. Esses requisitos refletem a necessidade dos clientes para um sistema com finalidade específica, seja ela controlar um dispositivo, colocar ou buscar uma determinada informação. Esse processo de descobrir, analisar, documentar e verificar esses serviços e restrições é chamado de Engenharia de Requisitos (RE, do inglês requirements engineering). O autor ainda adverte sobre a inconsistência da utilização do termo requisito, uma vez que por um lado é feita de maneira abstrata e em alto nível dos serviços e restrições que o sistema deve oferecer, e no outro extremo é uma definição detalhada e formal de uma função do sistema.

Davis apud Sommerville explica essas diferenças:

Se uma empresa pretende fechar um contrato para um projeto de desenvolvimento de software de grande porte, deve definir as necessidades de forma abstrata o suficiente para que a solução para essas necessidades não seja predefinida. Os requisitos precisam ser escritos de modo que vários contratantes possam concorrer pelo contrato e oferecer diferentes maneiras de atender às necessidades da organização do cliente. Uma vez que o contrato tenha sido adjudicado, o contratante deve escrever para o cliente uma definição mais detalhada do sistema, para que este entenda e possa validar o que o software fará. Ambos os documentos podem ser chamados documentos de requisitos para o sistema.

Sommerville (2011) ainda alerta para alguns problemas que surgem durante o processo de engenharia de requisitos. Que são as falhas em não fazer uma clara separação entre os requisitos dos usuários, que expressam os requisitos abstratos de alto nível, e os requisitos do sistema que expressam detalhadamente o que o sistema deve fazer. Sommerville (2011, p. 58) diz que os requisitos dos usuários e de sistemas podem ser definidos da seguinte maneira:

• Requisitos de usuário são declarações, em uma linguagem natural com diagramas, de quais os serviços o sistema deverá fornecer a seus usuários e as restrições com as quais deve operar.• Requisitos de sistema são descrições mais detalhadas das funções, serviços e restrições operacionais do sistema de software. O documento de requisitos do sistema (às vezes, chamado especificação funcional) deve definir exatamente o que deve ser implementado. Pode ser parte do contrato entre o comprador do sistema e os desenvolvedores de software.

A Tabela 2 abaixo mostra os possíveis leitores para os requisitos de usuários e de sistemas. Como observamos, os leitores dos requisitos de usuários não costumam, ainda segundo Sommerville (2011), se preocupar com a forma

TÓPICO 1 | ENGENHARIA DE REQUISITOS

67

como o sistema será implementado, como é o caso de gerentes que não estão interessados nos recursos detalhados do sistema. Já os leitores dos requisitos do sistema precisam saber mais detalhadamente o que o sistema fará, pois estão mais interessados em como o sistema apoiará os processos dos negócios, por exemplo.

TABELA 2 - LEITORES PARA OS REQUISITOS DE USUÁRIOS E DE SISTEMAS

Requisitos de usuário

• Gerentes clientes.• Usuários finais do sistema.• Engenheiros clientes.• Gerentes contratantes.• Arquitetos de sistema.

Requisitos de sistema

• Usuários finais do sistema.• Engenheiros clientes.• Arquitetos de sistema.• Desenvolvedores de software.

FONTE: Adaptado de Sommerville (2010, p. 59)

A imagem a seguir demonstra de uma maneira divertida como essa falta de entendimento entre as partes gera confusão e como o resultado pode deixar o cliente insatisfeito.

FIGURA 23 - PROBLEMAS DE COMUNICAÇÃO

FONTE: Disponível em: <http://www.devmedia.com.br/artigo-engenharia-de-software-introducao-a-teste-de-software/8035>. Acesso em: 22 mar. 2016.


68

E para que esses problemas sejam minimizados é muito importante que os requisitos sejam entendidos pelas partes interessadas. E para ajudar nessa difícil tarefa, os requisitos são divididos em dois grupos: Funcionais e não funcionais.

2.1 DEFININDO OS REQUISITOS

Os requisitos de software são frequentemente classificados como Requisitos funcionais e Requisitos não funcionais. De acordo com Sommerville (2011, p. 59):

Requisitos funcionais: São declarações de serviços que o sistema deve fornecer, de como o sistema deve reagir a entradas específicas e de como o sistema deve se comportar em determinadas situações. Em alguns casos, os requisitos funcionais também podem explicitar o que o sistema não deve fazer. Requisitos não funcionais: São restrições aos serviços ou funções oferecidas pelo sistema. Incluem restrições de timing, restrições no processo de desenvolvimento e restrições impostas pelas normas. Ao contrário das características individuais ou serviços do sistema, os requisitos não funcionais, muitas vezes, aplicam-se ao sistema como um todo.

O próprio autor alerta que a distinção entre os tipos de requisitos não é tão clara como sugerem suas definições. E afirma que os requisitos não são independentes e que, muitas vezes, geram ou restringem outros requisitos. No próximo tópico detalharemos um pouco mais os requisitos funcionais e não funcionais.

2.1.1 Requisitos Funcionais

Os requisitos funcionais devem descrever as funções e as ações do sistema. Colocando de uma maneira mais simples, esses requisitos devem dizer o que o sistema faz, ou não faz, em algumas situações. Lembrando que essa especificação deve ser completa e consistente.

Engholm Jr. (2010) afirma que os Requisitos funcionais são aqueles que definem as funções ou ações fornecidas pelo sistema e que o usuário pode utilizar, além das regras de negócio e as interfaces internas e externas.

Os Requisitos funcionais do sistema, de acordo com Sommerville (2011), variam de requisitos gerais, que indicam o que o sistema deve fazer, até requisitos bem específicos, que refletem os sistemas e as formas de trabalho de uma organização.

Exemplos de Requisitos funcionais:


69

• O sistema deve permitir a inclusão, alteração e remoção de professores com os seguintes atributos: nome, endereço, cidade, etc.

• O sistema fornecerá telas apropriadas para o usuário ler documentos.• Cada pedido tem um único identificador.• O sistema deve gerar diariamente, para cada unidade de ensino, a lista

dos alunos inadimplentes.• O sistema deve permitir pesquisar a lista dos alunos com nota abaixo da

média.

Sommerville (2011, p. 60), em relação aos Requisitos funcionais, afirma que:

Em princípio, a especificação dos requisitos funcionais de um sistema deve ser completa e consistente. Completude significa que todos os serviços requeridos pelo usuário devem ser definidos. Consistência significa que os requisitos não devem ter condições contraditórias. Na prática, para sistemas grandes e complexos, é praticamente impossível alcançar a completude e consistência de requisitos.

2.1.2 Requisitos não funcionais

Os Requisitos não funcionais, ao contrário dos funcionais, não se relacionam com a funcionalidade do software, mas eles definem outras propriedades que também são importantes para o sistema, como qualidade, confiabilidade, desempenho, usabilidade, segurança, portabilidade e Integridade. (SILVA, 2014).

De acordo com Sommerville (2011), os requisitos não funcionais do sistema, como o nome sugere, são requisitos que não estão diretamente relacionados com os serviços específicos oferecidos pelo sistema a seus usuários. Esses requisitos podem estar relacionados às propriedades como confiabilidade e tempo de resposta.

Ainda de acordo com o autor, a Figura 24 apresenta uma classificação dos requisitos não funcionais. Podemos ver que os requisitos não funcionais podem ser provenientes das características requeridas para o software. Sommerville (2011, p.61).

• Requisitos de produto: Esses requisitos especificam ou restringem o comportamento do software. • Requisitos organizacionais: Esses são os requisitos gerais de sistemas derivados das políticas e procedimentos da organização do cliente e do desenvolvedor.• Requisitos externos: Esse tipo abrange todos os requisitos que derivam de fatores externos ao sistema e seu processo de desenvolvimento. Podem incluir requisitos reguladores, que definem o que deve ser feito para que o sistema seja aprovado para uso, tal como um banco central; requisitos legais, que devem ser seguidos para garantir que o sistema opere dentro da lei.


70

FIGURA 24 - REQUISITOS NÃO FUNCIONAIS

FONTE: Sommerville (2011, p. 61)

Os requisitos não funcionais são de difícil verificação, por isso devem ser escritos quantitativamente, para que possam ser objetivamente testados, conforme Tabela 3.

TABELA 3 – REQUISITOS NÃO FUNCIONAIS

VelocidadeTransações processadas/segundo.Tempo de resposta de usuário/evento.Tempo de atualização tela.

Tamanho Megabytes.Número de chips de memória ROM.

Facilidade de uso Tempo de treinamento.Número de frames de ajuda.

Confiabilidade

Tempo médio para falha.Probabilidade de indisponibilidade.Taxa de ocorrência de falhas.Disponibilidade.

RobustezTempo de reinício após falha.Percentual de eventos que causam falhas.Probabilidade de corrupção de dados em caso de falha.

Portabilidade Percentual de declarações dependentes do sistema-alvo.Número de sistemas-alvo.

FONTE: Sommerville (2011, p. 63)


71

2.2 CRITÉRIOS PARA VALIDAÇÃO E ACEITAÇÃO DE REQUISITOS

A validação de requisitos tem como objetivo mostrar que os requisitos levantados definem o sistema desejado pelos usuários.

A importância dessa tarefa está no fato de que erros em um documento de requisitos podem acarretar custos excessivos de trabalho quando são descobertos durante o processo de desenvolvimento ou mesmo depois, durante a operação do sistema. Esses problemas serão detalhados mais a fundo na Tabela 4.

Sommerville (2011) diz que durante o processo de validação dos requisitos, diferentes tipos de verificações devem ser realizados com os documentos de requisitos. Essas verificações incluem:

TABELA 4 - TIPOS DE VERIFICAÇÕES

Verificação de validade

Um usuário pode achar que precisa de um software para determinada função. No entanto, uma análise mais detalhada pode identificar outras funções além das solicitadas. Os sistemas têm diversos stakeholders com diferentes necessidades, e qualquer conjunto de requisitos é inevitavelmente um compromisso da comunidade de stakeholders.

Verificação de consistência

Os requisitos em um documento devem ser consistentes e não conflitantes. Ou seja, não deve haver restrições contraditórias ou descrições diferentes da mesma função do sistema.

Verificação de completude

O documento de requisitos deve incluir requisitos que definam todas as funções e as restrições pretendidas pelo usuário do sistema.

Verificação de realismo

Ou seja, o que se deseja é possível. Usando o conhecimento das tecnologias existentes, os requisitos devem ser verificados para assegurar que realmente possam ser implementados. Verificando o orçamento e o cronograma de desenvolvimento.

Verificabilidade

Com a intenção de reduzir o potencial de conflito entre o cliente e o contratante, os requisitos do sistema devem ser passíveis de verificação. O que significa que você deve ser capaz de escrever um conjunto de testes que demonstrem que o sistema entregue atende a cada requisito especificado.


Para a validação dos requisitos, Sommerville (2011) lista uma série de técnicas para a validação dos requisitos, para serem usadas individualmente ou em conjunto.


72

TABELA 5 – VALIDAÇÃO DE REQUISITOS

Revisão de requisitos

Os requisitos são sistemicamente analisados por uma equipe de revisores que verifica erros e inconsistências.

Prototipação

Nessa abordagem para validação, um modelo executável do sistema em questão é demonstrado para os usuários finais e clientes. Estes podem experimentar o modelo para verificar se ele atende às suas reais necessidades.

Geração de casos de testes

Os requisitos devem ser testáveis. Se os testes forem concebidos como parte do processo de validação, isso frequentemente revela problemas de requisitos. Se é difícil ou impossível projetar um teste, isso normalmente significa que os requisitos serão difíceis de serem implementados e devem ser reconsiderados.


Segundo Engholm Jr. (2010), para que um requisito possa ser validado e aceito devemos verificar se é:

TABELA 6 – VERIFICAÇÃO DOS REQUISITOS

Claro Estar escrito de maneira que seja de fácil entendimento, possibilitando a compreensão por todos os integrantes da equipe de projeto.

Completo Contendo todos os detalhes importantes, como dados de entrada e saída, regras de validação ou interação do usuário com o sistema.

Consistente Requisitos não podem ser contraditórios.Único Requisitos devem ser únicos, sem duplicidade.

Viável Todos os requisitos devem ser viáveis para serem atendidos pela solução.

Testável Os requisitos devem poder ser efetivamente testados quando implementados.

Rastreável Devem poder ser rastreáveis a partir do problema de negócio.FONTE: Adaptado de Engholm Jr. (2010, p. 160)

Devemos atentar e não subestimar os problemas envolvidos na validação dos requisitos. Segundo Sommerville (2011), é difícil mostrar que um conjunto de requisitos atende de fato às necessidades de um usuário; os usuários precisam imaginar o sistema em operação e como esse sistema se encaixa no seu trabalho. E até mesmo para os profissionais qualificados de informática é difícil fazer esse tipo de análise abstrata, e é mais difícil ainda para os usuários do sistema. Por isso, durante o processo de validação dos requisitos, raramente todos os problemas de requisitos serão encontrados.


73

2.3 PROBLEMAS ENCONTRADOS REFERENTES A REQUISITOS

Durante a fase de levantamento de requisitos é necessário que haja uma sintonia entre os analistas, para que o sistema atinja os objetivos. Caso haja problemas nessa fase, o prejuízo pode ser imenso e até mesmo comprometer e inviabilizar todo o sistema. A tirinha apresentada relata bem esse problema.

FIGURA 25 – LEVANTAMENTO DE REQUISITOS

FONTE: Disponível em: http://gerenciandoriscosemprojetos.com/levantamento-de-requisitos/>. Acesso em: 22 mar. 2016.

Dias e Araújo (2012) afirmam que muitos projetos têm falhado devido a problemas no levantamento de requisitos, tais como requisitos incompletos, mal-entendidos ou ambíguos. Faz-se necessário então que esses requisitos sejam bem construídos, de modo que expressem exatamente o que o usuário deseja, da maneira que ele deseja e a forma como poderá ser feito. Por isso é importante conhecer técnicas para tornar a construção destes requisitos mais eficaz e evitar o retrabalho.

Engholm Jr. (2010) alerta que existem vários motivos que podem gerar problemas e até mesmo o fracasso de um projeto. Segundo ele, a falta de especificação da real necessidade e expectativas dos usuários é o maior motivo dessas falhas, seguido por requisitos incompletos, com baixa qualidade e falta de controle de mudanças. Ainda segundo o autor, por mais que possa parecer estranho, uma dificuldade que podemos encontrar em relação a requisitos é manter o foco no produto e nos objetivos relacionados ao projeto. Devemos atentar se os requisitos apresentados estão compatíveis e alinhados com o projeto.

Quando um processo de levantamento de requisitos é ineficaz e não reflete as necessidades reais do cliente, acaba gerando um software de baixa qualidade.


74

De acordo com Dias e Araújo (2016), estudos mostram que de 40% a 60% de todos os problemas encontrados em um projeto de software são causados por falhas no processo de requisitos. Se a fase de engenharia de requisitos for bem feita, esses problemas poderiam ser detectados e corrigidos a um custo muito mais baixo.

2.4 ESPECIFICAÇÃO DE REQUISITOS

Através da Figura 26, apresentada por Engholm Jr. (2010), é possível entender um pouco melhor a representação dos requisitos, onde cada nível é associado ao nível de refinamento dos requisitos.

A partir do detalhamento das necessidades do cliente pode-se obter as características do produto, derivando destas todos os requisitos a serem contemplados pelo projeto. A nuvem representa o domínio do problema, refletindo as necessidades que devem ser atendidas. Também se observa, na imagem, que todo requisito deve ter como base uma necessidade relacionada ao problema de negócio.

FIGURA 26 - REQUISITOS

FONTE: Engholm Jr. (2010, P. 157)


75

Reforçando a afirmação de que todo requisito deve ter como base uma necessidade do projeto, tem-se a Figura 27 para auxiliar a identificar a rastreabilidade dos requisitos.

FIGURA 27 - RASTREABILIDADE DE REQUISITOS

FONTE: Engholm Jr. (2010, p. 152)

A especificação é o processo de escrever os requisitos levantados com os usuários em um documento de requisitos.

Sommerville (2011) alerta para a dificuldade dessa atividade, uma vez que cada stakeholder interpreta de maneira diferente os requisitos, gerando, muitas vezes, inconsistências e conflitos nesta documentação. Ainda segundo o autor, os requisitos de usuário para um sistema devem descrever os requisitos funcionais e não funcionais de uma maneira que sejam inteligíveis para os usuários do sistema e que não tenham conhecimentos técnicos detalhados.

Torna-se ideal não usar jargões de software, notações estruturadas ou notações formais, não se deve incluir detalhes da arquitetura ou do projeto, deve-se apenas especificar o comportamento externo do sistema e em linguagem natural, com tabelas simples e diagramas intuitivos.


76

2.4.1 Especificação em Linguagem Natural

Segundo Sommerville (2011), a Linguagem Natural tem sido usada desde o início da engenharia do software para escrever os requisitos do programa. Essa linguagem é expressiva, intuitiva e natural. Também é potencialmente vaga, ambígua, e seu significado depende do conhecimento do autor.

TABELA 7 – LINGUAGEM NATURAL

Notação DescriçãoSentenças em

linguagem naturalOs requisitos são escritos em frases numeradas em linguagem natural. Cada frase deve expressar um requisito.

Linguagem Natural estruturada

Os requisitos são escritos em linguagem natural em um formulário padrão ou template. Cada campo fornece informações sobre um aspecto do requisito.

Linguagem de descrição do

projeto

Essa abordagem usa uma linguagem de programação, mas com características mais abstratas, para especificar os requisitos, definindo um modelo operacional do sistema. Essa abordagem é pouco usada atualmente, embora possa ser útil para as especificações de interface.

Notações gráficas

Para definição de requisitos funcionais para o sistema são usados modelos gráficos, suplementados por anotações de texto; diagramas de caso de uso e de sequência da UML são comumente usados.

Especificações matemáticas

Essas notações são baseadas em conceitos matemáticos, como máquinas de estado finito ou conjuntos. Embora essas especificações inequívocas possam reduzir a ambiguidade de um documento de requisitos, a maioria dos clientes não entende uma especificação formal. Eles não podem verificar que elas representam o que eles querem e são relutantes em aceitá-las como um contrato de sistema.


Para minimizar os mal-entendidos ao escrever requisitos em linguagem natural, Sommerville (2011) recomenda algumas diretrizes simples:

• Crie um formato-padrão e garanta que todas as definições de requisitos aderem a esse formato. A padronização do formato torna menos prováveis as omissões e mais fácil a verificação dos requisitos.• Use uma linguagem consistente para distinguir entre os requisitos obrigatórios e os desejáveis. Os obrigatórios são os requisitos aos quais o sistema tem de dar suporte e geralmente são escritos usando-se “DEVE”. Já os desejáveis não são essenciais e são escritos usando-se “PODE”.• Use negrito, itálico ou cores para destacar as partes fundamentais.• Não assuma que os leitores compreendem a linguagem técnica da engenharia de software. Evite o uso de jargões, siglas e acrônimos.


77

• Sempre que possível, tente colocar uma lógica a cada um dos requisitos de usuário. Essa justificativa deve explicar por que o requisito foi incluído, e é particularmente útil quando são alterados, uma vez que pode ajudar a decidir sobre quais mudanças são indesejáveis.

2.4.2 Especificação Estruturada

Especificação estruturada, segundo Sommerville (2011), é uma forma de escrever os requisitos do sistema na qual a liberdade do escritor dos requisitos é limitada e todos os requisitos são escritos em uma forma-padrão. Essa abordagem mantém grande parte da expressividade e compreensão da Linguagem Natural, mas garante certa uniformidade imposta sobre a especificação. O autor ainda aponta que para usar uma abordagem estruturada para a especificação de requisitos de sistema, pode-se definir um ou mais templates para representar esses requisitos como formulários estruturados. A especificação pode ser estruturada em torno dos objetos manipulados pelo sistema, das funções desempenhadas, ou pelos eventos processados por este. Ele diz que quando um formulário-padrão é usado para especificar requisitos funcionais, as seguintes informações devem ser incluídas:

• A descrição da função ou entidade a ser especificada.• Uma descrição de suas entradas e de onde eles vieram.• Uma descrição de suas saídas e para onde elas irão.• Informações sobre a informação necessária para o processamento ou outras entidades usadas no sistema.• Uma descrição da ação a ser tomada.• Se uma abordagem funcional é usada, uma precondição define o que deve ser verdade antes que a função seja chamada, e é chamada uma pós-condição, especificando o que é verdade depois da função.• Uma descrição dos efeitos colaterais da opção, caso existam.

Colocar nota explicando a diferença entre acrônimos e sigla: Acrônimos: 1 [Linguística] Palavra formada com as letras ou sílabas iniciais de uma sequência de palavras, pronunciada sem soletração das letras que a compõem (ex.: OVNI por Objeto Voador Não Identificado, PALOP por País Africano de Língua Oficial Portuguesa, etc.). Sigla1 [Paleografia] Letra inicial usada como abreviatura em manuscritos, medalhas e monumentos antigos.2 Monograma.3 [Linguística] Vocábulo formado com as letras ou sílabas iniciais de uma sequência de palavras e que geralmente se pronuncia soletrando o nome de cada letra (ex.: UE por União Europeia, E.U.Apor Estados Unidos da América, etc.).4 [Antigo] Traços empregados pelos pedreiros, como sinais da sua corporação.

FONTE: Disponível em: <"sigla", in Dicionário Priberam da Língua Portuguesa [em linha], 2008-2013, http://www.priberam.pt/dlpo/sigla>. Acesso em: 19 jan. 2016.

NOTA


78

A Figura 28 mostra alguns exemplos de uma especificação estruturada para pesquisa de dados.

FIGURA 28 – ESPECIFICAÇÃO ESTRUTURADA

FONTE: Disponível em: <https://repositorio.ufsc.br/bitstream/handle/123456789/87674/212905.pdf?sequence=1>. Acesso em: 22 mar. 2016.


79

2.4.3 Documento de requisito de software

Segundo Pressman (2011), uma especificação de requisitos de software (software requirementes specification, SRS) é um documento que deve ser construído e especificado antes do projeto começar. Contendo uma descrição detalhada de todos os aspectos do software.

Complementando a informação, Sommerville (2011) diz que esse documento deve incluir tanto os requisitos do usuário para um sistema, quanto uma especificação detalhada dos requisitos deste. Lembrando que, em algumas vezes, os requisitos do software e dos usuários podem ser integrados em uma única descrição. Já em outros, os requisitos dos usuários são definidos como uma introdução à especificação dos requisitos do sistema. De acordo com o autor, o documento de requisitos possui um conjunto diversificado de autores, que alcançam os vários níveis na hierarquia da empresa, do mais alto, que são responsáveis pelo pagamento do sistema, até os engenheiros que são responsáveis pelo desenvolvimento do software. Esses níveis de usuários são definidos conforme a tabela a seguir:

TABELA 8 – NÍVEIS DE USUÁRIOS

Clientes do sistemaEspecificam e leem os requisitos para verificar se estes satisfazem suas necessidades. Os clientes especificam as alterações nos requisitos.

GerentesUsam o documento de requisitos para planejar uma proposta para o sistema e para planejar o processo de desenvolvimento do sistema.

Engenheiros de sistema Usam os requisitos para entender o sistema que será desenvolvido.

Engenheiros de testes do sistema

Usam requisitos para desenvolver testes de validação do sistema.

Engenheiros de manutenção de sistema

Usam os requisitos para entender o sistema e os relacionamentos entre suas partes.


Atualmente existem várias planilhas disponíveis para auxiliar nesse processo de documentação. Elas são muito semelhantes entre si, como pode ser visto nos modelos apresentados por Sommerville (2011) e Pressman (2013).

Uma descrição detalhada de cada tópico SRS de Pressman pode ser obtida no link http://www.processimpact.com/process_assets/srs_template.doc

DICAS


80

FIGURA 29 – MODELO DE DOCUMENTAÇÃO

FONTE: Adaptada Pressman (2013, p.129)


81

A definição do documento de requisitos definida por Sommerville (2011) apresenta a descrição de cada item, como segue:

TABELA 9 – DOCUMENTO DE REQUISITOS

Capítulo Descrição

Prefácio

Deve definir os possíveis leitores do documento e descrever seu histórico de versões, incluindo uma justificativa para a criação de uma nova versão e um resumo das mudanças feitas em cada versão.

Introdução

Deve descrever a necessidade para o sistema. Deve descrever brevemente as funções do sistema e explicar como ele vai funcionar com outros sistemas. Também deve descrever como o sistema atende aos objetivos globais de negócio ou estratégicos da organização que encomendou o software.

GlossárioDeve definir os termos técnicos usados no documento. Você não deve fazer suposições sobre a experiência ou o conhecimento do leitor.

Definição de requisitos de

usuário

Deve descrever os serviços fornecidos ao usuário. Os requisitos não funcionais de sistema também devem ser descritos nessa seção. Essa descrição pode usar a Linguagem Natural, diagramas ou outras notações compreensíveis para os clientes. Normas de produtos e processos que devem ser seguidos e especificados.

Arquitetura do sistema

Deve apresentar uma visão geral e alto nível da arquitetura do sistema previsto, mostrando a distribuição de funções entre os módulos do sistema. Componentes de arquitetura que são reusados devem ser destacados.

Especificação de requisitos do sistema

Deve descrever em detalhes os requisitos funcionas e não funcionais. Se necessário, também podem ser adicionados mais detalhes aos requisitos não funcionais. Interfaces com outros sistemas podem ser definidas.

Modelos do sistema

Pode incluir modelos gráficos do sistema que mostram os relacionamentos entre os componentes do software, o sistema e seu ambiente. Exemplos de possíveis modelos de objetos, modelos de fluxo de dados ou modelos semânticos de dados.

Evolução do sistema

Deve descrever os pressupostos fundamentais em que o sistema se baseia, bem como quaisquer mudanças previstas, em decorrência da evolução de hardware, de mudanças nas necessidades do usuário etc. Essa seção é útil para projetistas de sistema, pois pode ajudá-los a evitar decisões capazes de restringir possíveis mudanças futuras no software.

Apêndices

Deve fornecer informações detalhadas e específicas relacionadas à aplicação em desenvolvimento, além de descrições de hardware e banco de dados, por exemplo. Os requisitos de hardware definem as configurações mínimas ideais para o sistema. Requisitos de banco de dados definem a organização lógica dos dados usados pelo software e os relacionamentos entre esses dados.


82

ÍndicesVários índices podem ser incluídos no documento. Pode haver, além de um índice alfabético normal, um índice de diagramas, de funções, entre outros pertinentes.


2.4.4 Gerenciamento de requisitos

Engholm Jr. (2010) apresenta uma sugestão de processo de gerenciamento de requisitos em projetos de software, onde podemos visualizar os atores, a matriz de responsabilidade, os subprocessos e os produtos e entregáveis de cada um deles.

FIGURA 30 - GERENCIAMENTO DE REQUISITOS

FONTE: Engholm Jr. (2010, p. 159)

O gerenciamento de requisitos é o processo de compreensão e controle de mudanças nos requisitos do sistema. É preciso atenção às necessidades individuais e manter as ligações entre as necessidades dependentes para conseguir avaliar o impacto das mudanças de requisitos. É necessário estabelecer um processo formal para fazer propostas de mudanças e a ligação destas às exigências do sistema.


83

“O processo formal de gerenciamento de requisitos deve começar assim que uma versão preliminar do documento de requisitos estiver disponível. Porém, o planejamento de como gerenciar mudanças de requisitos deve começar durante o processo de elicitação de requisitos”. Sommerville (2011, p.78)


A importância do levantamento de requisitos no sucesso dos projetos de software

Esse artigo pretende descrever resumidamente a relação entre o bom levantamento de requisitos e o sucesso dos projetos de software.

A tarefa de desenvolvimento de software engloba uma série de fases e atividades que, independentemente da metodologia escolhida, ocorrem para a realização do seu objetivo maior: entregar software funcionando corretamente dentro do orçamento e prazos previstos para o seu desenvolvimento.

Para atingir os objetivos do projeto, todas as atividades de desenvolvimento têm que ser criteriosamente elaboradas e desenvolvidas, seja usando uma abordagem de desenvolvimento mais rica em documentação, tais como o poderoso UP (Unified Process) ou as excelentes metodologias ágeis (XP, SCRUM etc). Assim sendo, em qualquer uma delas encontraremos com maior ou menor rigor e formalização, atividades de análise de requisitos, design, definição de arquitetura, codificação e outras. Um trabalho consistente de análise dos requisitos, ou seja, identificar, quantificar, definir, priorizar e classificar os principais problemas que o futuro software deve resolver é a base de um projeto de software de sucesso.

Muita ênfase é dada pelos profissionais de T.I. nas atividades de projeto e codificação. Isso deve-se em boa parte à formação dada aos profissionais de T.I. pelas universidades, que focam em suas grades curriculares principalmente em disciplinas técnicas e científicas. Tem muito a ver também com perfil pessoal e cultural dos profissionais que atuam na área em geral, formada eminentemente por técnicos, bastante interessados em bits e bytes e pouco afetos a assuntos administrativos. Isso tem mudado bastante recentemente, pois os profissionais de T.I. têm percebido a importância da relação entre negócio e T.I. Entretanto, a atividade de levantamento de requisitos é de fundamental importância para que se construa o software certo, ou seja, é necessário, antes de mais nada, que os envolvidos no projeto de software saibam exatamente o que é esperado do aplicativo a ser construído. É muito importante também que todos os envolvidos saibam igualmente o que o software não fará. Isso pode parecer óbvio, mas nem sempre fica claro para todos os envolvidos do projeto sobre qual é a fronteira da aplicação. A fronteira da aplicação pode ser entendida como uma linha imaginária que circula e define objetivamente, dentre os requisitos de software, quais serão automatizados e quais não serão.


84

É fundamental definir corretamente o que vem a ser um requisito: é uma especificação de uma característica ou propriedade que um sistema deve possuir ou fazer, assim como sua restrição de operação. Os requisitos podem ser definidos por diversas classificações, tais como: requisitos de negócio, funcionais, não funcionais, etc. Larga documentação existe sobre o tema, tanto em livros, como na internet, portanto esse artigo não vai se prolongar sobre o assunto.

Toda metodologia de desenvolvimento de software (MDS) propõe uma série de fases e atividades dentro do seu ciclo de vida e o encadeamento entre elas. Independentemente do nome dado a cada fase, é extremamente recomendável que o processo contemple ao menos dois grandes grupos de atividades referentes a requisitos, que poderíamos chamar aqui de:

Especificação de requisitos - São todas as atividades realizadas para identificar, analisar, especificar e definir as necessidades de negócio que um aplicativo deve prover para solução do problema levantado. Requisitos que não refletem as reais necessidades dos usuários, incompletos e/ou inconsistentes, mudanças em requisitos que já foram previamente acordados e a dificuldade para se chegar a um acordo entre profissionais de T.I. e usuários são os maiores problemas enfrentados no grupo de atividades de especificação de requisitos.

Gestão de requisitos - Preocupa-se com a documentação, versionamento, controle de mudanças e qualidade dos requisitos levantados na fase de especificação de requisitos. Todo requisito apresenta um ciclo de vida único que acompanha a dinâmica dos negócios associados. Assim sendo, não se pode esperar que um requisito seja imutável ao longo do tempo, uma vez que o negócio do qual o requisito se desprende é dinâmico.

O gerente de um projeto de desenvolvimento de software deve atentar para a importância do correto entendimento das necessidades do aplicativo e deve disponibilizar seu(s) melhor(es) analista(s) para realizar a atividade de levantamento de requisitos. Essa etapa bem realizada servirá como uma fundação firme para a realização das atividades seguintes do projeto. É de suma importância que o gerente do projeto se envolva ou designe alguém capacitado para a realização da gestão de escopo do projeto, inclusive criando um método criterioso de controle de mudanças. Não se deve confundir criterioso com burocrático. Muitas empresas, cientes dos problemas ocasionados por falta da correta gestão de escopo, tentam “blindar” os requisitos do projeto, tornando qualquer alteração morosa e difícil, cercada de documentos e assinaturas que muitas vezes provocam o efeito contrário ao desejado. É importante que todos os envolvidos no projeto busquem harmonizar seus interesses em prol da consecução dos objetivos do projeto.

Concluindo, podemos afirmar que sem uma correta definição e gestão dos requisitos do aplicativo é praticamente certo que o projeto terá o seu sucesso comprometido, frustrando as expectativas do cliente e comprometendo as metas e planos da empresa contratante.


85

Márcio Andrade SilvaMárcio Andrade Silva - Formado em Análise de sistemas pela FAFI-BH.

Pós-graduado em Engenharia de Software pela PUC Minas.MBA em Gestão de Negócios pela UNA - BH

FONTE: Disponível em: http://www.linhadecodigo.com.br/artigo/1685/a-importancia-do-levantamento-de-requisitos-no-sucesso-dos-projetos-de-software.aspx#ixzz3x8rwTQ00>. Acesso em: 22 mar. 2016.

86

RESUMO DO TÓPICO 1


• Durante o desenvolvimento do sistema é necessário estar sempre atento à qualidade e às necessidades do cliente para que estas sejam atendidas. Para isso é importante saber exatamente o que se espera do sistema.

a) Engenharia de requisitos: Processo de descobrir, analisar, documentar e verificar esses serviços e restrições é chamado de Engenharia de Requisitos (RE, do inglês requirements engineering).

b) Definindo os requisitos: Deve descrever os serviços fornecidos ao usuário. Os requisitos funcionais e não funcionais do sistema devem ter. Esta descrição pode usar a Linguagem Natural, diagramas ou outras notações compreensíveis para os clientes. Normas de produtos e processos que devem ser seguidos devem ser especificados.

c) Requisitos Funcionais: São declarações de funções de como o sistema deve reagir a entradas específicas e como deve se comportar em determinadas situações. É uma interação entre o sistema e o seu ambiente. Algumas vezes, os requisitos funcionais podem também explicitamente declarar o que o sistema não deve fazer. A especificação deve ser completa e consistente.

d) Requisitos Não Funcionais: São restrições aos serviços ou funções oferecidas pelo sistema. Incluem restrições de timing, restrições no processo de desenvolvimento e restrições impostas pelas normas. Ao contrário das características individuais ou serviços do sistema, os requisitos não funcionais, muitas vezes, aplicam-se ao sistema como um todo.

e) Critérios para validação e aceitação de requisitos: A validação de requisitos tem como objetivo mostrar que os requisitos levantados definem o sistema desejado pelos usuários.

f) Problemas encontrados referentes a requisitos: É a falta de especificação da real necessidade e expectativas dos usuários. É o maior motivo dessas falhas, seguido por requisitos incompletos, com baixa qualidade e falta de controle de mudanças.

g) Especificação de requisitos: uma especificação de requisitos de software (software requirementes specification, SRS) é um documento que deve ser construído e especificado antes do projeto começar. Contendo uma descrição detalhada de todos os aspectos do software.

87

h) Especificação em Linguagem Natural: É uma forma de escrever os requisitos do sistema na qual a liberdade do escritor dos requisitos é limitada e todos os requisitos são escritos em uma forma-padrão.

i) Especificação estruturada: Essa linguagem é expressiva, intuitiva e natural. Também é potencialmente vaga, ambígua, e seu significado depende do conhecimento do autor.

j) Documento de requisito de software: Sua utilização é durante o desenvolvimento de um sistema de software, no qual há a necessidade de elaborar o documento descrevendo o conjunto de requisitos do sistema de modo a informar tanto à equipe de projeto, quanto ao cliente, o que será implementado.

k) Gerenciamento de requisitos: A tarefa de gerenciar requisitos se preocupa com as mudanças nos requisitos que já haviam sido acertadas entre cliente e desenvolvedor.

88

AUTOATIVIDADE

No texto abaixo você tem a solicitação para desenvolvimento de software de um cliente proprietário de uma clínica médica. A partir das informações levantadas com o cliente, preencha o documento de análise do problema que dará início à documentação do futuro sistema.

Empresa: Clínica Bem-Estar

Função: Fomos contratados para analisar seu processo atual e verificar como expandir suas operações e melhorar seu nível de serviço.

Histórico: A clínica, fundada há cinco anos, atua no atendimento clínico pediátrico.

A clínica possui 34 médicos cadastrados em diferentes especialidades, como: cardiologia, clínica geral, dermatologia etc. Todos os médicos utilizam internet e e-mail. A faixa etária predominante é de 30, 35, 40, 42, 44 e 48 anos. Todos os médicos são aptos do ponto de vista físico.

O paciente pode ser atendido de forma particular ou por convênios. Os convênios atendidos são o Bruxtr, Vpfzm e UIOlk.

Cada médico faz três plantões semanais de quatro horas seguidas; as consultas possuem um intervalo de 30 minutos. Existe a possibilidade de a consulta ser de retorno, nesse caso são apenas 15 minutos.

A clínica é 24 horas. Cada médico possui uma agenda preta onde são marcadas as consultas. Na marcação da consulta são colocados o nome do paciente, o horário e convênio. Trabalham há três anos na clínica com planilhas Excel.

A clínica possui duas atendentes que são responsáveis por preencher o cadastro inicial do paciente, que contém nome, endereço, telefone, data de nascimento e convênio.

O médico, ao atender o paciente, preenche sua ficha manualmente, informando peso, altura, idade, motivo da consulta, queixa principal, doenças anteriores, diagnóstico e prescrição. A prescrição pode ser a solicitação de exames ou medicamentos com posologia.

A clínica possui de 700 a 800 fichas, sendo que cerca de 600 são de atendimento por convênio.

89

O gerente da clínica está ansioso, pois não consegue controlar questões relacionadas ao número de pacientes atendidos por convênio e particular, médicos mais procurados e picos de movimento. Volume de atendimentos: 56 por dia.

Outra questão de interesse é manter um controle de laboratórios conveniados, pois o médico poderia indicar o laboratório já no momento da prescrição.

TEMPLATE PARA REALIZAÇÃO DA ANÁLISE DO PROBLEMA CLÍNICA BEM-ESTAR

1 Nome da empresa.

2 Contato.

3 Descrição do problema.

4 Identificação do principal objetivo do cliente.

5 Descrição dos usuários do sistema (para cada usuário, descreva cargo e possíveis funções dentro do processo).

6 Descrição detalhada dos processos existentes (COMO O SISTEMA ATUAL FUNCIONA?) • Para marcação da consulta.• Como funciona o processo de atendimento?

7 Itens produzidos no sistema (quais são os relatórios e consultas existentes ou solicitados pelos clientes?)

8 Volume de informações do sistema atual.

9 Descrição de situações consideradas críticas e atores envolvidos.

10 Restrições do projeto.

91

TÓPICO 2

DESCOBERTA DE REQUISITOS

UNIDADE 2

1 INTRODUÇÃO

A descoberta de requisitos, também é chamada de elicitação de requisitos, é o processo de reunir informações sobre o sistema requerido e os sistemas existentes e separar dessas informações os requisitos de usuários e de sistemas. Pode-se listar como fontes de informação durante a fase descoberta de requisitos, segundo Sommerville (2011, p.70):

• Documentação• Stakeholders do sistema e• Sistemas e especificações de sistemas similares.

A interação com os stakeholders pode se dar por meio de observação e entrevistas, e para facilitar o entendimento desses profissionais pode-se usar cenários e protótipos que os ajudam a compreender o funcionamento do futuro sistema.

Sommerville apud Moraes propõe um processo genérico de levantamento e análise que contém as seguintes atividades:

• Compreensão do domínio: Os analistas devem desenvolver sua compreensão do domínio da aplicação.• Coleta de requisitos: É o processo de interagir com os stakeholders do sistema para descobrir seus requisitos. A compreensão do domínio se desenvolve mais durante essa atividade.• Classificação: Essa atividade considera o conjunto não estruturado dos requisitos e os organiza em grupos coerentes.• Resolução de conflitos: Quando múltiplos stakeholders estão envolvidos, os requisitos apresentarão conflitos. Essa atividade tem por objetivo solucionar esses conflitos.• Definição das prioridades: Em qualquer conjunto de requisitos, alguns serão mais importantes do que outros. Esse estágio envolve interação com os stakeholders para a definição dos requisitos mais importantes.• Verificação de requisitos: Os requisitos são verificados para descobrir se estão completos e consistentes e se estão em concordância com o que os stakeholders desejam do sistema.

92


2 TÉCNICAS DE LEVANTAMENTO

O levantamento e análise de requisitos é um processo iterativo, com uma contínua validação de uma atividade para outra, conforme apresentado na Figura 31.

FIGURA 31 - LEVANTAMENTO E ANÁLISE DE REQUISITOS

FONTE: Disponível em: <http://www.devmedia.com.br/engenharia-de-software-2-tecnicas-para-levantamento-de-requisitos/9151>. Acesso em: 22 mar. 2016.

A fase de levantamento de dados, segundo Moraes (2016), é uma fase muito importante e que gera muita insatisfação por parte dos usuários, dentre essas razões podemos destacar:

• Na fase de levantamento de requisitos do projeto, onde não é utilizada uma técnica adequada para extrair os requisitos do sistema;• A falha do analista em não descrever os requisitos do sistema de modo claro, sem ambiguidades, conciso e consistente com todos os aspectos significativos do sistema proposto.

Ainda segundo a autora, dentre as dificuldades encontradas na fase de levantamento de requisitos estão:

• O usuário principal do sistema não sabe o que quer que o sistema faça ou sabe e não consegue transmitir para o analista; • Requisitos identificados, mas que não são realistas e não identificam os requisitos similares informados por pessoas diferentes. • Um stakeholder errado afetará em perda de tempo e dinheiro para ambas as partes envolvidas no desenvolvimento do sistema.

TÓPICO 2 | DESCOBERTA DE REQUISITOS

93

Ela ainda afirma que se identifica um levantamento de requisitos adequado através da boa definição do projeto, da efetividade do projeto, de informações necessárias a um perfeito diagnóstico e de soluções inteligentes.

Vale ressaltar que as técnicas de levantamento de requisitos têm por objetivo superar as dificuldades encontradas nesta fase. Todas as técnicas possuem um conceito próprio e suas respectivas vantagens e desvantagens, que podem ser utilizadas em conjunto pelo analista.

2.1 ENTREVISTA

Segundo Sommerville (2011), as entrevistas, sejam elas formais ou informais, realizadas com os stakeholders, são parte da maioria dos processos da engenharia dos requisitos. Nessas entrevistas, os stakeholders são questionados pela equipe de engenharia de requisitos sobre os sistemas que usam no momento e também sobre o sistema que será desenvolvido. A partir dessas respostas os requisitos surgem.

Sommerville (2011, p.72), classifica essas entrevistas em dois tipos:

• Entrevistas fechadas: em que o stakeholder responde a um conjunto predefinido de perguntas.• Entrevistas abertas: Neste caso não existe uma agenda predefinida. A equipe de engenharia de requisitos explora uma série de questões com os stakeholders, e assim desenvolve uma melhor concepção das necessidades do novo sistema.

Moraes (2016) sugere que é necessário ter um plano de entrevista para que não haja dispersão do assunto principal e a entrevista fique longa, deixando o entrevistado cansado e não produzindo bons resultados. E que as seguintes diretrizes podem ser de grande auxílio na direção de entrevistas bem-sucedidas com o usuário:

• Desenvolver um plano geral de entrevistas.• Certificar-se da autorização para falar com os usuários.• Planejar a entrevista para fazer uso eficiente do tempo.• Utilizar ferramentas automatizadas que sejam adequadas. • Tentar descobrir em que informação o usuário está mais interessado e • Usar um estilo adequado ao entrevistar.

A autora aponta que é importante planejar a entrevista. É necessário que antes dela sejam coletados e estudados todos os dados pertinentes à discussão,

Essas técnicas serão detalhadas de maneira resumida aqui, e sugere-se um estudo detalhado para evitar problemas nessa importante fase.

ESTUDOS FUTUROS

94


como formulários, relatórios, documentos e outros. Para que, dessa forma, o analista esteja bem contextualizado e tenha mais produtividade nos assuntos a serem discutidos na entrevista. Após a entrevista é necessário validar se o que foi documentado pelo analista está de acordo com a necessidade do usuário, que o usuário não mudou de opinião e que entende a notação ou representação gráfica de suas informações.

Moraes (2016) ressalta:

A atitude do analista em relação à entrevista é determinar seu fracasso ou sucesso. Uma entrevista não é uma competição, deve-se evitar o uso excessivo de termos técnicos e não conduzir a entrevista em uma tentativa de persuasão. O modo como o analista fala não deve ser muito alto, nem muito baixo, tampouco indiretamente, ou seja, utilizar os termos: ele disse isso ou aquilo na reunião para o outro entrevistado. O modo melhor para agir seria, por exemplo, dizer: O João vê a solução para o projeto dessa forma. E o senhor André, qual é a sua opinião? Em uma entrevista o analista nunca deve criticar a credibilidade do entrevistado. O analista deve ter em mente que o entrevistado é o perito no assunto e fornecerá as informações necessárias ao sistema.

Para elaborar perguntas detalhadas, Moraes (2016) entende ser necessário solicitar que o usuário:

• Explique o relacionamento entre o que está em discussão e as demais partes do sistema.• Descreva o ponto de vista de outros usuários em relação ao item que esteja sendo discutido.• Descreva informalmente a narrativa do item em que o analista deseja obter informações.• Perguntar ao usuário se o item em discussão depende para a sua existência de alguma outra coisa, para assim poder juntar os requisitos comuns do sistema, formando assim um escopo conciso.• Pode-se utilizar a confirmação, para tanto o analista deve dizer ao usuário o que acha que ouviu ele dizer. Neste caso, o analista deve utilizar as suas próprias palavras em lugar das do entrevistado e solicitar ao entrevistado confirmação do que foi dito.

2.1.1 Etnografia - Observação pessoal

De acordo com Sommerville (2011), a Etnografia é conhecida como a técnica de observação, onde os analistas passam alguns dias na empresa na qual o software será utilizado, dessa forma conseguem entender a política organizacional da empresa, acompanhar os trabalhos diários, para que assim conheçam os processos reais que os usuários vão precisar diariamente no sistema. Esses processos são todos observados e anotados para a montagem dos principais requisitos do software.


95

Segundo Moraes (2016), a Etnografia é uma técnica de observação que pode ser utilizada para compreender os requisitos sociais e organizacionais, ou seja, entender a política organizacional, bem como a cultura de trabalho, com objetivo de familiarizar-se com o sistema e sua história. Os cientistas sociais e antropólogos usam técnicas de observação para desenvolver um entendimento completo e detalhado de culturas particulares. Ainda segundo a autora, nesta técnica o analista se insere no ambiente de trabalho em que o sistema será utilizado. O trabalho diário é observado e são anotadas as tarefas reais em que esse será utilizado. O principal objetivo da Etnografia é que ela ajuda a descobrir requisitos de sistema implícitos, que refletem os processos reais, em vez de os processos formais, onde as pessoas estão envolvidas. Etnografia é particularmente eficaz na descoberta de dois tipos de requisitos:

• Os requisitos derivados da maneira como as pessoas realmente trabalham, em vez da maneira pelas quais as definições de processo dizem como elas deveriam trabalhar.• Os requisitos derivados da cooperação e conscientização das atividades de outras pessoas.

A autora ressalta alguns itens importantes que devem ser executados antes, durante e depois do estudo de observação:

• Antes, se faz necessário identificar as áreas de usuário a serem observadas; além de obter a aprovação das gerências apropriadas para executar tais observações; obter os nomes e funções das pessoas-chave que estão envolvidas no estudo de observação; e explicar a finalidade do estudo.• Durante, é necessário familiarizar-se com o local de trabalho que está sendo observado. Para isso é preciso observar os agrupamentos organizacionais atuais; as facilidades manuais e automatizadas; coletar amostras de documentos e procedimentos escritos que são usados em cada processo específico que está sendo observado; e acumular informações estatísticas a respeito das tarefas, como: frequência em que ocorrem, fazer estimativas de volumes, tempo de duração para cada pessoa que está sendo observada. Além de observar as operações normais de negócios acima, é importante observar as exceções;• Depois, é necessário fazer a documentação das descobertas que resultará das observações feitas. Para consolidar o resultado é preciso rever os resultados com as pessoas observadas e/ou com seus superiores.

2.1.2 Questionário

Os questionários são usados para o levantamento de Requisitos, quando a empresa solicitante possuir filiais em diversas localidades, e ao invés da equipe de analistas ir a todas essas filiais, são elaborados os questionários e enviados para os principais usuários de cada filial. As questões são elaboradas de forma simples, clara e objetiva, para que todos os envolvidos possam compreender e responder.

Moraes (2016) aponta que os questionários utilizados para esse tipo de levantamento podem ser: múltipla escolha, lista de verificação e questões com

96


espaços em branco. A sugestão para ser desenvolvido dessa forma é minimizar o tempo gasto em sua resposta. Ainda de acordo com Moraes (2016), na fase de preparação do questionário deve ser indicado o tipo de informação que se deseja obter. Assim que os requisitos forem definidos, o analista deve elaborar o questionário com questões de forma simples, clara e concisa, deixar espaço suficiente para as repostas que forem descritivas e agrupar as questões de tópicos específicos em um conjunto com um título especial. A autora sugere uma lista de procedimentos para o sucesso dessa atividade:

O questionário deve ser acompanhado por uma carta explicativa, redigida por um alto executivo, para enfatizar a importância dessa pesquisa para a organização. Deve ser desenvolvido um controle que identifique todas as pessoas que receberão os questionários. A distribuição deve ocorrer junto com instruções detalhadas sobre como preenchê-lo e ser indicado claramente o prazo para devolução do questionário. Ao analisar as respostas dos participantes é feita uma consolidação das informações fornecidas no questionário, documentando as principais descobertas e enviando uma cópia com estas informações para o participante como forma de consideração pelo tempo dedicado a pesquisa.(MORAES, 2016. Disponível em: < http://www.devmedia.com.br/articles/viewcomp.asp?comp=9151>. Acesso em: 22 mar. 2016)

2.1.3 Brainstorming

Brainstorming é uma técnica para geração de ideias. Ela consiste em uma ou várias reuniões que permitem que as pessoas sugiram e explorem ideias.

A técnica de Brainstorming é conhecida como a de geração de ideias, são selecionados grupos de setores diferentes e com propostas de ideias que às vezes são quase impossíveis, mas no decorrer das reuniões elas são compreendidas e propostas para o sistema. Essa técnica costuma ocorrer diversas vezes em reuniões marcadas com os usuários da empresa, segundo Moraes (2016).

Moraes (2016) lista as principais etapas necessárias para conduzir uma sessão de Brainstorming:

• Seleção dos participantes: Os participantes devem ser selecionados em função das contribuições diretas que possam dar durante a sessão. A presença de pessoas bem informadas, vindas de diferentes grupos, garantirá uma boa representação;• Explicar a técnica e as regras a serem seguidas: O líder da sessão explica os conceitos básicos de Brainstorming e as regras a serem seguidas durante a sessão;• Produzir uma boa quantidade de ideias: Os participantes geram tantas ideias quantas forem exigidas pelos tópicos que estão sendo o objeto do Brainstorming. Os participantes são convidados, um por vez, a dar uma única ideia. Se alguém tiver problema, passa a vez e espera a próxima rodada.


97

A autora adverte que por mais que as ideias, a princípio, pareçam não convencionais, devem ser encorajadas, pois frequentemente estimulam os participantes, o que pode levar a soluções criativas para o problema. O número de ideias geradas deve ser bem grande, pois quanto mais ideias apresentadas, maior será a chance de aparecerem boas ideias. Os participantes também devem ser encorajados a combinar ou enriquecer as ideias de outros e, para isso, é necessário que todas as ideias permaneçam visíveis a todos os participantes.

A documentação, de acordo com Moraes (2016), é designada para uma pessoa que registra todas as ideias em uma lousa branca ou em papel. E à medida que cada folha de papel é preenchida, ela é colocada de forma que todos os participantes possam vê-la.

Analisar as ideias resultantes desse processo é a fase final do Brainstorming. Nessa fase é realizada uma revisão das ideias, uma de cada vez. As consideradas valiosas pelo grupo são mantidas e classificadas em ordem de prioridade.

2.1.4 JAD (Joint Application Design)

Segundo Moraes (2016), JAD é uma técnica para promover cooperação, entendimento e trabalho em grupo entre os usuários desenvolvedores. Ela facilita a criação de uma visão compartilhada do que o produto de software deve ser. Através da sua utilização, os desenvolvedores ajudam os usuários a formular problemas e explorar soluções. Dessa forma, os usuários ganham um sentimento de envolvimento, posse e responsabilidade com o sucesso do produto. Essa técnica tem quatro princípios básicos:

• Dinâmica de grupo: são realizadas reuniões com um líder experiente, analista, usuários e gerentes, para despertar a força e criatividade dos participantes. O resultado final será a determinação dos objetivos e requisitos do sistema.• Uso de técnicas visuais: para aumentar a comunicação e o entendimento.• Manutenção do processo organizado e racional: o JAD emprega a análise top down e atividades bem definidas. Possibilita, assim, a garantia de uma análise completa, reduzindo as chances de falhas ou lacunas no projeto e cada nível de detalhe recebe a devida atenção.• Utilização de documentação padrão: preenchida e assinada por todos os participantes. Este documento garante a qualidade esperada do projeto e promove a confiança dos participantes.

A autora afirma que a técnica JAD é composta de duas etapas principais. A de planejamento, que tem por objetivo levantar e especificar os requisitos. E o projeto, em que se lida com o projeto de software. Cada etapa consiste em três fases: adaptação, sessão e finalização. A fase de adaptação consiste na preparação para a sessão, ou seja, organizar a equipe, adaptar o processo JAD ao produto a ser construído e preparar o material. Durante a fase de sessão é realizado um ou mais encontros estruturados, envolvendo desenvolvedores e usuários onde

98


os requisitos são desenvolvidos e documentados. Já a fase de finalização tem por objetivo converter a informação da fase de sessão em sua forma final (um documento de especificação de requisitos).

Segundo a autora, há seis tipos de participantes, embora nem todos participem de todas as fases:

• Líder da sessão: é responsável pelo sucesso do esforço, sendo o facilitador dos encontros. Deve ser competente, com bom relacionamento pessoal e qualidades gerenciais de liderança.• Engenheiro de requisitos: é o participante diretamente responsável pela produção dos documentos de saída das sessões JAD. Deve ser um desenvolvedor experiente para entender as questões técnicas e detalhes que são discutidos durante as sessões e ter habilidade de organizar ideias e expressá-las com clareza.• Executor: é o responsável pelo produto sendo construído. Tem que fornecer aos participantes uma visão geral dos pontos estratégicos do produto de software a ser construído e tomar as decisões executivas, tais como alocação de recursos, que podem afetar os requisitos e o projeto do novo produto.• Representantes dos usuários: são as pessoas na empresa que irão utilizar o produto de software. Durante a extração de requisitos, os representantes são frequentemente gerentes ou pessoas-chave dentro da empresa que têm uma visão melhor do todo e de como ele será usado.• Representantes de produtos de software: são pessoas que estão bastante familiarizadas com as capacidades dos produtos de software. Seu papel é ajudar os usuários a entender o que é razoável ou possível que o novo produto faça.• Especialista: é a pessoa que pode fornecer informações detalhadas sobre um tópico específico.

Para Moraes (2016), essa dinâmica de grupo pode ser utilizada para diversas finalidades, como o planejamento de atividades técnicas para um grande projeto, discussão do escopo e objetivos de um projeto e estimativa da quantidade de horas necessárias para desenvolver sistemas grandes e complexos. Vale lembrar que a maioria das técnicas JAD funciona melhor em projetos pequenos ou médios. Para um sistema grande e complexo podem ser usadas múltiplas sessões JAD para acelerar a definição dos requisitos do sistema.

99

RESUMO DO TÓPICO 2


• As técnicas para o levantamento de requisitos, apresentadas de acordo com MORAES (2016):

a) Técnicas tradicionais: São aplicadas em várias áreas do conhecimento. Exemplo: questionários, entrevistas, observação, e análise de documentos.

b) Técnicas de elicitação de grupo: Tem por objetivo compreender melhor o pensamento e comportamento dos grupos e as necessidades dos usuários. Exemplo: brainstorming e as sessões JAD (Joint Application Design).

c) Prototipação: O uso de protótipo auxilia na elicitação e validação dos requisitos de sistema. A prototipação pode ser utilizada para elicitar requisitos quando há um alto grau de incerteza ou quando é necessário um rápido feedback dos usuários.

d) Técnicas contextuais: Surgiram como uma alternativa para as técnicas tradicionais e cognitivas e inclui técnicas de etnografia e análise social.

100

AUTOATIVIDADE

1 Segundo o estudo de caso apresentado a seguir, crie uma lista de 10 perguntas que você, como analista, faria ao cliente que solicitou o sistema.

Estudo de caso: Revendedora de automóveis

Model Car é o nosso cliente, e deseja automatizar o processo de compra e venda de automóveis que é realizado em sua loja. O processo é bem simples, e funciona da seguinte forma:

A Model Car adquire automóveis diretamente da fábrica, ou pelo sistema de troca com seus clientes, sistema esse em que o cliente leva um automóvel da loja e deixa o seu em troca. Para cada veículo da loja é necessário saber quem o vendeu, para no caso de problemas entrar em contato com o responsável, seja a fábrica ou o cliente. Quando ocorre algum problema com o veículo fornecido pela fábrica, é necessário saber as informações básicas para que se possa entrar em contato.

Em virtude de ser uma empresa de pequeno porte, a Model Car trabalha apenas com veículos de passeio e utilitários leves. Sendo que para esses veículos ela também precisa de um cadastro com informações básicas de identificação.

O mesmo acontece com os clientes da Model Car, ela precisa das informações que possam identificar e localizá-los, para que futuramente possam ser enviadas correspondências via carta, e-mail ou telefone com as promoções. Além de permitir a análise do perfil do cliente para compras futuras.

O processo de vendas funciona de duas formas. Na primeira e mais comum, o cliente se dirige até a loja e efetua a compra. A outra forma é onde o vendedor faz visita aos clientes. Neste segundo caso, a comissão é o dobro da primeira modalidade de venda.

O gerente, querendo administrar melhor sua empresa, deseja saber informações que o ajudem na administração do seu negócio, como os valores pagos de comissão, qual o vendedor que mais vendeu, a região com ou sem venda, número de carros vendidos em troca etc. Todas essas informações mês a mês e acumuladas também por trimestre. Além, é claro, do controle de estoque.

101

TÓPICO 3

DESENVOLVIMENTO E EQUIPE DE SOFTWARE

UNIDADE 2

1 INTRODUÇÃO

O desenvolvimento de sistemas é um processo que segue algumas etapas, como projeto ou análise, codificação, testes, implantação. A definição das etapas pode variar de caso para caso, mas, de uma forma geral, o processo de desenvolvimento está relacionado a essas etapas. Neste tópico serão apresentadas as etapas do processo de desenvolvimento de um sistema e as atividades que são necessárias para que essas fases sejam cumpridas.

A única certeza que se tem durante toda a fase de desenvolvimento de software é a mudança, seja no projeto ou na própria equipe. Baseado nessa premissa é preciso alguém para organizar, planejar e executar atividades que facilitem o processo de trabalho e a sua continuidade.

A gerência pode se dar sobre coisas, pessoas ou ambos. O gerente organiza seu ambiente de trabalho, toma decisões, direciona o trabalho de funcionários ou membros de uma equipe.

Pode-se definir o termo equipe como um conjunto de pessoas trabalhando para atingir o mesmo objetivo (Projeto). Gerenciar a equipe do projeto tem como objetivo acompanhar o desempenho da equipe, fornecer feedback, resolver problemas e coordenar mudanças para melhorar o desempenho do projeto.

Começa-se então contextualizando a gerência do projeto e as atividades que fazem parte do desenvolvimento de projeto.

2 FASES DO DESENVOLVIMENTO DE SISTEMAS

O processo de desenvolvimento de software classifica em atividades as tarefas que serão realizadas durante a construção de sistema. Mesmo havendo vários processos de desenvolvimento, há um consenso de que não existe um melhor processo, ou aquele que se aplica a todas as situações de desenvolvimento. Bezerra (2015) afirma que cada processo tem suas particularidades em relação ao modo de arranjar e encadear as atividades de desenvolvimento.

Silva (2014) adverte que, muitas vezes, um analista sem muita experiência pode achar interessante começar o sistema programando, antes de entender por

102


completo as necessidades do cliente. Vale lembrar que essa solução apressada pode resolver a solução de determinado problema, mas pode acarretar outros bem mais complexos. Ele sugere que é indispensável seguir uma metodologia de projeto com ênfase no planejamento adequado. Ainda de acordo com o autor, para o projeto de desenvolvimento de um sistema a equipe deve ter as seguintes fases em mente.

FIGURA 32 – ENCADEAMENTO DAS ATIVIDADES

FONTE: Adaptado de Silva (2014, p. 29)

2.1 ESTUDO DE VIABILIDADE

Essa é a fase que consiste na avaliação detalhada dos custos e benefícios do desenvolvimento do projeto para a empresa. Deve-se analisar se os riscos e as limitações forem superiores aos benefícios. É o momento de cancelar ou fazer mudanças que se adequem da melhor maneira para a empresa.

Ainda nessa fase de avaliação, Silva (2014) esclarece que durante essa fase existem dois pontos importantes que devem ser avaliados. A Viabilidade Técnica e a Viabilidade Econômica. A Viabilidade Técnica refere-se ao ambiente em que o sistema será instalado, a familiaridade dos usuários com a tecnologia aplicada. Já a Viabilidade Econômica demonstra a famosa e conhecida por todos, custo versus benefício. Pois o desenvolvimento do sistema envolve custos operacionais, custos

A Figura 32 demonstra o encadeamento das atividades que serão detalhadas depois.

ESTUDOS FUTUROS

TÓPICO 3 | DESENVOLVIMENTO E EQUIPE DE SOFTWARE

103

de desenvolvimento, de compra de equipamentos, além da contratação, em alguns casos, de profissionais especializados.

2.1.1 Análise

Nesta fase, o analista faz um levantamento detalhado de dados e fatos, para descobrir o que realmente precisa ser desenvolvido. Silva (2014) diz que durante essa fase o trabalho deve ser desenvolvido de forma disciplinada e gradual, obedecendo rigorosamente aos critérios técnicos previstos, evitando que a equipe pule fases, comprometendo assim o desempenho do sistema que será desenvolvido. O autor adverte que é indispensável identificar todos os elementos de dados que podem gerar informações. Esse levantamento pode ser realizado por meio de pesquisas em documentos, entrevistas, análise de arquivos e contato com os usuários. Ele enumera alguns documentos resultantes dessa fase, vale ressaltar que não são todos, pois podem variar de projeto para projeto:

• Definição dos principais objetivos do novo sistema.• Descrição do funcionamento do sistema.• Especificação do fluxo e dados.• Descrição dos arquivos a serem utilizados.• Identificação de prazo para a apresentação de resultados ao usuário e • Construção do modelo lógico.

Formalmente, o termo análise corresponde a “quebrar” um sistema e seus componentes e estudar como eles interagem entre si com o objetivo de entender como esse sistema funciona. Esta é a etapa em que os analistas realizam um estudo detalhado dos requisitos levantados. A partir desse estudo, são construídos os modelos para representar o sistema que será construído. Esses modelos devem ser cuidadosamente validados e verificados. (BEZERRA, 2015). O autor esclarece o objetivo da validação, que é assegurar que as necessidades do cliente estão sendo atendidas pelo sistema. Ele quer assegurar-se de que a especificação que os analistas construíram do software é correta, consistente, completa, realista e sem ambiguidade. Se um modelo não é bem definido, é possível que tanto usuários quanto desenvolvedores tenham diferentes interpretações acerca do sistema a ser desenvolvido. Ainda segundo o autor, a verificação tem o objetivo de analisar se os modelos construídos estão em conformidade com os requisitos definidos. Na verificação dos modelos é onde são analisadas a exatidão de cada modelo em separado e a consistência entre eles.

104


2.1.2 Projeto

Na fase de projeto definida por Bezerra (2015), determina-se “como” o sistema funcionará para entender os requisitos, de acordo com os recursos tecnológicos existentes. Nesta fase considera-se os aspectos físicos e dependentes da implantação. Os modelos que foram construídos nesta fase são adicionados às restrições tecnológicas. Nesta fase se produz uma descrição computacional do que o software deve fazer de uma maneira coerente com a descrição que foi feita na análise.

Alguns exemplos de aspectos a serem considerados nesta fase:

• Arquitetura física do sistema.• Padrão de interface gráfica.• Algoritmos específicos.• O gerenciador de banco de dados.

Essa é a fase onde o analista deve assimilar exatamente o que deve ser feito e fazer a transformação do Modelo Lógico criado na fase anterior, para o Modelo Físico. É durante essa fase que o analista conhece com profundidade o problema do usuário e propõe soluções.

Podemos listar alguns documentos, de acordo com Silva (2014), que são gerados nessa fase de projeto do sistema.

• Diagrama de fluxo de dados Brooks• Tipos de bancos de dados • Especificação dos relatórios

O projeto detalhado é uma das fases mais decisivas do desenvolvimento, ela tem a facilidade do analista que deve completar o fluxo de dados, conforme definido. É nesta fase que se deve definir com os programadores e os usuários,

Para dizer o que é Modelo Lógico e Modelo Físico:

Modelo Lógico: Concentra-se nos detalhes da construção. O modelo lógico, também referenciado como esquema de banco de dados, é gerado aplicando-se as regras de derivação de tabelas para um modelo relacional de banco de dados. Dependendo da situação, é possível definir mais de um modelo lógico.

Modelo Físico: Demonstra como os dados são fisicamente armazenados na base de dados. São detalhados os componentes da estrutura física do banco, como tabelas, campos, tipos de valores, índices, etc.

NOTA


105

todos os detalhes da implementação, além de conter todas as especificações técnicas necessárias para codificação de cada programa.

2.1.3 Implementação

Na fase de implementação o sistema é codificado, ou seja, ocorre a tradução da descrição computacional obtida na fase de projeto em código executável mediante o uso de uma ou mais linguagens de programação (BEZERRA, 2015).

Definição semelhante é dada por Silva (2014):

Com base nos programas definidos no projeto, inicia-se a sua codificação na linguagem de programação escolhida. A implementação consiste na codificação de programas, isto é, na construção física do sistema. Essa atividade está mais centrada nos programadores.

2.1.4 Implantação

Esse momento de implantação constitui um marco fundamental na vida do sistema, pois, se houver falhas, a credibilidade da equipe de sistemas será abalada. Esta fase de implantação consiste na entrega do produto concluído ao cliente e pronto para ser colocado em operação. Essa fase deve ser muito bem planejada e articulada com os gerentes dos setores usuários, além dos seguintes passos (SILVA, 2014, p.36):

• Teste geral do sistema com dados reais.• Treinamento de usuários.• Acompanhamento de todos os procedimentos operacionais pela equipe de análise.• Controle e análise de resultados dos processamentos.

Bezerra define essa fase como sendo a fase em que o sistema é empacotado, distribuído e instalado no ambiente do usuário. Também nessa fase os manuais do sistema são escritos, os arquivos carregados, dados importados para o sistema e os usuários para utilização correta do sistema. Em alguns casos, ocorre também a migração de sistemas e software e dados preexistentes.

2.2 GERENCIAMENTO DE PROJETOS

O gerenciamento de projetos de software é uma parte essencial da engenharia de software. De acordo com o guia PMBOK 5 (2013), o gerenciamento de projetos é a aplicação de conhecimento, habilidades, ferramentas e técnicas às

106


atividades do projeto com o objetivo de atender aos requisitos. O gerenciamento de projetos é dividido em cinco grandes grupos, que são: Iniciação, Planejamento, Execução, Monitoramento e Controle e o Encerramento do projeto. Ainda segundo PMI (2013, p.4), a atividade de gerenciamento de projeto normalmente inclui as seguintes atividades:

• Identificação de requisitos;• Abordagem das diferentes necessidades, preocupações e expectativas das partes interessadas no planejamento e execução do projeto;• Estabelecimento, manutenção e execução de comunicações ativas, eficazes e colaborativas entre os envolvidos no projeto;• Gerenciamento das partes interessadas visando o atendimento aos requisitos do projeto e a criação das suas entregas,• E o equilíbrio das restrições conflitantes do projeto.

Para ilustrar algumas das possíveis restrições conflitantes (PMI, 2013, p.5):

• Escopo;• Qualidade;• Cronograma;• Orçamento;• Recursos e • Riscos.

É importante deixar claro que as circunstâncias e as características de um projeto podem influenciar as restrições nas quais a equipe de gerenciamento de projeto precisa se concentrar.

Hazrati apud Buzon afirma que um artigo publicado na Harvard Business Review tem despertado grande interesse na comunidade. Os resultados indicam que projetos de TI são muito mais arriscados do que se pensa: entre os mais de 1.400 projetos pesquisados, uma média de 27% extrapolou o orçamento e 16% dos projetos poderiam ser chamados de Cisnes Negros, pois excederam o custo em mais de 200% e tiveram atrasos de mais de 70%, um nível de fracasso grande o suficiente para levar empresas à falência.

Azevedo (2008) do site Mundo PMP, também apresenta números alarmantes, ela diz que: “70% dos projetos falham no cumprimento de cronograma, custos e metas de qualidade e 50% são executados acima do orçamento”. Segundo a autora, o problema não é apenas que a maioria dos projetos de TI não consegue alcançar os resultados esperados. Mesmo quando os projetos são executados com sucesso, muitas vezes eles ainda não trazem benefícios para o negócio. O verdadeiro problema é que há uma falta de alinhamento entre os objetivos do negócio e as atividades de TI. A gerência executiva e as unidades de negócios têm uma visibilidade limitada sobre o que TI está fazendo e TI tem uma conexão limitada com os objetivos estratégicos e do negócio. Um olhar mais de perto para esta importante questão, de uma perspectiva de negócios e de uma perspectiva técnica, mostra as causas raízes da falha do projeto.

É possível perceber como a falta de alinhamento gera um problema muito sério no desenvolvimento de sistemas.


107

2.3 EQUIPE DE DESENVOLVIMENTO

Em seu livro “O mítico homem-mês”, escrito em 1975, Frederick Brooks usa de muitas analogias interessantes para ilustrar a importância da equipe de desenvolvimento. Analogias estas, que ainda são atuais.

Passados mais de 40 anos, esse livro continua atual de acordo com os dados apresentados anteriormente, e essa frase ainda se aplica e muito no desenvolvimento de projetos. Brooks (1975) ainda usa outro exemplo no primeiro capítulo, onde fala sobre como grandes empresas de desenvolvimento de software têm dificuldade de terminar seus projetos no prazo, com o gasto previsto e com a qualidade esperada, fazendo referência ao problema mortal do "poço de alcatrão (piche)" para as grandes feras pré-históricas. Pois quando o projeto começa a atrasar, eles vão colocando mais e mais recursos, o que na maioria das vezes não ajuda, é apenas mais uma fera no poço de piche.

FIGURA 33 - MURAL DOS POÇOS DE ALCATRÃO DE LA BREA

FONTE: Brooks Jr. (1975, p.2)

No tópico a seguir vamos conhecer um pouco mais sobre a equipe de desenvolvimento.

ESTUDOS FUTUROS

Conheça mais desse autor, veja: <http://www.dicas-l.com.br/arquivo/planejador_mestre_fred_brooks_mostra_como_projetar_qualquer_coisa.php>

DICAS

108


Bezerra (2015) diz em seu livro que a atividade de desenvolvimento de software é uma tarefa altamente cooperativa, pois tecnologias complexas demandam especialistas em áreas específicas. Segundo ele, uma equipe de desenvolvimento de software é composta por um gerente, analistas, projetistas, programadores, clientes e grupo de avaliação de qualidade, que serão descritos a seguir, individualmente. Ele também alerta que essa descrição dos participantes tem um fim mais didático, pois, na prática, a mesma pessoa desempenha diferentes funções e uma mesma função é desempenhada por várias pessoas.

2.3.1 Gerente

Segundo Bezerra (2015), o gerente de projetos é a pessoa responsável pela gerência ou coordenação das atividades necessárias à construção do sistema. Ele também é o responsável que desempenhará atividades como: orçamento do projeto, estimar o tempo para o desenvolvimento do sistema, definir qual o processo de desenvolvimento, o cronograma das atividades, a mão de obra especializada, bem como os recursos de hardware e software.

O site Portal da Administração explica, de uma maneira geral, que a função do gerente de projetos é determinar e executar as necessidades do cliente, seja por indicação desse, ou baseado em seus próprios conhecimentos. O gerente de projetos deve ser capaz de imaginar o projeto por inteiro, do seu início ao seu final, trabalhando para manter o progresso e a interação mútua dos participantes, reduzindo os riscos de fracasso.


109

FIGURA 34- O GERENTE DE PROJETOS

FONTE: Disponível em: <http://www.humordaterra.com/wp-content/uploads/2011/06/Gerenciamento-de-projetos.jpg>. Acesso em: 22 mar. 2016.

2.3.2 Analistas

De acordo com a definição de Bezerra (2015), analista de sistemas é o profissional que deve ter o conhecimento do negócio e entender seus problemas para que possa definir os requisitos do sistema a ser desenvolvido. Deve estar apto a se comunicar com especialistas do domínio para obter conhecimento acerca dos problemas e das necessidades envolvidas na organização empresarial. Ainda segundo o autor, o analista não precisa ser um especialista, mas deve ter domínio suficiente do vocabulário da área de conhecimento na qual o sistema será implantado, evitando assim que o profissional especialista de domínio seja interrompido a todo momento para explicar conceitos da área.

110


FIGURA 35 – ANALISTAS DE SISTEMAS

FONTE: Disponível em: <http://vidadeprogramador.com.br/page/2/?s=analista+de+sistemas>. Acesso em: 22 mar. 2016.

2.3.3 Projetistas

Bezerra (2015) define o projetista de sistemas como o integrante da equipe de desenvolvimento cujas funções são: avaliar as alternativas de solução (da definição) do problema resultante da análise. Ele diz também que o projetista tem como função gerar a especificação de uma solução computacional detalhada.

2.3.4 Arquitetos de software

O arquiteto de software é um profissional encontrado principalmente em grandes equipes reunidas para desenvolver sistemas complexos, de acordo com Bezerra (2015). É ele quem toma decisões sobre quais subsistemas compõem o sistema como um todo e quais são as interfaces entre esses subsistemas. Além de tomar decisões globais, esse profissional, de acordo com o autor, também deve ser capaz de tomar decisões técnicas detalhadas.


111

Tavares (2014), em relação à atividade de arquitetura de software, diz que:

Deveria ser óbvio colocar a arquitetura no centro de um projeto de desenvolvimento de software. Não só do ponto de vista tecnológico, mas também do ponto de vista do planejamento gerencial. Esta ilustração mostra que as partes interessadas fornecem metas de negócios que são destiladas em condutores arquiteturais, que conduzem toda a estrutura da arquitetura. A arquitetura é iterativamente refinada e pode, por sua vez, refinar os condutores arquiteturais, bem como as metas de negócios. O DAS (documento de arquitetura de software) se torna o principal artefato mantido ao longo de todo o projeto.

FIGURA 36 – ARQUITETURA DE SOFTWARE

FONTE: Tavares (2014)

112


A atividade do arquiteto, segundo Meriat (2011), é ilustrada através da tirinha.

FIGURA 37 – COMO SER UM ARQUITETO DE SOFTWARE

FONTE: Disponível em: < http://www.vitormeriat.com.br/category/charges/>. Acesso em: 22 mar. 2016.

2.3.5 Programadores

Talvez seja o profissional mais conhecido na área de sistemas, pois ele é o responsável pela implementação do sistema. Bezerra (2015) afirma quem em um projeto é comum haver vários programadores. Um programador pode ser proficiente em uma ou mais linguagens de programação, além de ter conhecimento sobre banco de dados e poder ler os modelos resultantes do trabalho do projetista. O autor pontua algumas diferenças entre as atividades desempenhadas entre os programadores e os analistas. O analista de sistemas está envolvido em todas as etapas do desenvolvimento, diferente do programador, que participa unicamente das fases finais (implementação e testes). É comum bons programadores serem “promovidos” a analistas de sistemas. Mas, ainda que,segundo o autor, essa seja uma prática recorrente nas empresas de desenvolvimento de software, há uma falsa lógica, pois nem sempre bons programadores serão bons analistas.


113


6 PASSOS PARA ALAVANCAR A PRODUTIVIDADE DA MINHA EQUIPE DE SERVIÇOS PROFISSIONAIS

por Thiago Reis em Pessoas

Dobrar a produção do time de consultoria e conseguir assumir mais projetos sem precisar contratar novos colaboradores. Qual gerente de projetos não sonha com isso?

Apesar da rotina atribulada, validação de entregas, atendimento ao cliente e alterações no escopo, é possível, com planejamento e foco, ampliar as entregas e resultados. Para ajudá-lo, separamos os seis passos para que você consiga dobrar a produtividade da sua equipe de desenvolvedores mantendo o nível de qualidade das entregas:

1 Identifique os gargalos 80 - 20, conheça bem a sua equipe e respectivas habilidades

A Lei de Pareto (também conhecida como princípio 80-20) afirma que para muitos fenômenos, 80% das consequências advêm de 20% das causas. A lei foi sugerida por Joseph M. Juran, que deu o nome em honra ao economista italiano Vilfredo Pareto.

Aplicando a Lei de Pareto à prestação de serviços profissionais, assumimos que 80% do seu resultado vêm de atividades que concentram 20% do seu esforço. Independente do seu dia a dia, são essas ações que você deve garantir que serão feitas. Analise como otimizá-las e como liberar o tempo da sua equipe. Normalmente gastamos uma quantidade de tempo significativo preparando apresentações e relatórios. Uma maneira de reduzir esse tempo é automatizando esse processo. Encontre os gargalos onde seu time gasta mais tempo.

2 Automatize a distribuição de tarefas

Pesquisas realizadas com nossos clientes que conseguiram atingir um ROI significativo com adoção de uma ferramenta identificaram que um membro da equipe perdia um grande tempo tentando saber quais as atividades ele deveria realizar no dia, assim como os gestores de projetos perdiam enviando e-mails solicitando que uma tarefa seja feita e cobrando se a mesma foi executada.

Para distribuir as tarefas de maneira que elas sejam realizadas corretamente e no tempo determinado, você deve saber delegá-las de forma simples e automática. Uma ferramenta de gestão de projetos colaborativa te ajuda significativamente com esse processo. Em uma pesquisa realizada com nossos clientes, identificamos que membros da equipe tiveram uma economia média de 30 minutos por dia, e gerente de projetos pelos gestores leva 20 minutos a menos, por dia (por projeto) no gerenciamento.

114


3 Defina uma metodologia de trabalho

Tenha sua equipe alinhada a uma única metodologia de trabalho. É importante que os processos estejam claros e bem executados por todos. Isso o ajudará a conversar com toda a equipe em uma mesma linguagem, minimizando ruídos. Além disso, algumas metodologias de projetos, como o CCPM (Gerenciamento de Projetos por Corrente Crítica), já citado aqui no blog anteriormente, têm ganhado destaque ao apontar excelentes resultados na otimização da produtividade sem comprometer prazos de entrega.

4 Meça a produtividade sempre

Há diversas formas de medir a produtividade de seus desenvolvedores. Porém, antes é preciso definir os indicadores de fato importantes para esta resposta conforme a necessidade da sua equipe, empresa ou até mesmo projeto.

Para mensurar, é interessante utilizar sistemas de gerenciamento de projetos que permitam a emissão de relatórios de produtividade periódicos. Através deles é possível conferir relatórios com o andamento diário, semanal ou mensal, além de poder optar por avaliar o trabalho de um membro ou de toda a equipe. Este tipo de ferramenta é muito útil dentro das empresas para encontrar as falhas e aumentar a produtividade.

Analisar a quantidade de horas gastas em determinado período, separando-as em urgentes, importantes, rotineiras e não planejadas, pode trazer dados consideráveis para administrar o tempo gasto em cada etapa do processo e como este tem sido aproveitado. Um profissional que tem seu tempo e produtividade sob controle consegue realizar entregas de 75% a 100% do que foi planejado. Caso o resultado apresentado seja inferior, é hora de reavaliar as definições e reestruturar algo.

5 Converse com os seus funcionários

Gerir pessoas é uma tarefa complexa que pode impactar diretamente na produtividade de sua equipe. Lidar com motivações pessoais, interesses e objetivos diferentes para realizar uma mesma entrega exige muito jogo de cintura. Por isso, manter um diálogo com seus desenvolvedores, seja para esclarecimentos, orientações, feedbacks ou uma simples reunião de alinhamento, é muito importante.

6 Adquira um software para gestão de projetos

Uma ferramenta tecnológica para gerir projetos pode auxiliá-lo não apenas a acompanhar a execução das tarefas delegadas, mas também para evitar procrastinação dos desenvolvedores.

Através de um software é possível avaliar o tempo médio gasto em cada atividade, extrair relatórios de progressos da equipe (comparando o que foi planejado e o que foi executado), minimizar riscos, facilitar o acesso à documentação


115

e até mesmo apontar falhas em processos. Ainda é possível planejar o esforço necessário para cada atividade, analisar o atual comprometimento do membro da equipe, bem como a alocação de recursos e padronizar o apontamento de horas (o famoso timesheet). Tudo isso ajudará consideravelmente a aumentar o nível de produtividade do projeto.

Com estes passos você terá maior envolvimento com sua equipe e controle das respectivas entregas, além de poder aumentar a produtividade.

FONTE: <http://www.projectbuilder.com.br/blog-pb/entry/pessoas/6-passos-para-alavancar-a-produtividade-da-minha-equipe-de-servicos-profissionais> Acesso em: 13 jan 2016.

O site Techtudo apresenta a história de como a programação começa, veja que legal. http://www.techtudo.com.br/platb/desenvolvimento/2011/06/20/historia-da-programacao-como-tudo-comecou/Quer conhecer os maiores programadores da história? Veja a matéria que a revista Exame preparou. Veja quantos você conhece:http://exame.abril.com.br/tecnologia/noticias/os-22-programadores-mais-importantes-da-historia

DICAS

116

RESUMO DO TÓPICO 3


• As fases de desenvolvimento de um sistema e quem as desempenha.

a) Estudo de viabilidade: Essa é a fase que consiste na avaliação detalhada dos custos e benefícios do desenvolvimento do projeto para empresa. Deve-se analisar se os riscos e as limitações forem superiores aos benefícios, é o momento de cancelar ou fazer mudanças que se adequem da melhor maneira para a empresa.

b) Análise: Nesta fase, o analista faz um levantamento detalhado de dados e fatos, para descobrir o que realmente precisa ser desenvolvido.

c) Projeto: Determina-se “como” o sistema funcionará para entender os requisitos, de acordo com os recursos tecnológicos existentes, nesta fase consideram-se os aspectos físicos e dependentes da implantação.

d) Implementação: O sistema é codificado, ou seja, ocorre a tradução da descrição computacional obtida na fase de projeto em código executável mediante o uso de uma ou mais linguagens de programação.

e) Implantação: Esta fase de implantação consiste na entrega do produto concluído ao cliente e pronto para ser colocado em operação.

f) Gerenciamento de projetos: o gerenciamento de projetos é a aplicação de conhecimento, habilidades, ferramentas e técnicas às atividades do projeto com o objetivo de atender aos requisitos.

g) Equipe de desenvolvimento: A equipe de desenvolvimento de software é composta por um gerente, analistas, projetistas, programadores, clientes e grupo de avaliação de qualidade.

h) Gerente: É a pessoa responsável pela gerência ou coordenação das atividades necessárias à construção do sistema. Ele também é o responsável que desempenhará atividades como: orçamento do projeto, estimar o tempo para o desenvolvimento do sistema, definir qual o processo de desenvolvimento, o cronograma das atividades, a mão de obra especializada, bem como os recursos de hardware e software.

i) Analistas: O profissional que deve ter o conhecimento do negócio e entender seus problemas para que possa definir os requisitos do sistema a ser desenvolvido. E que deve estar apto a se comunicar com especialistas do domínio para obter conhecimento acerca dos problemas e das necessidades envolvidas na organização empresarial.

j) Projetistas: Têm como função gerar a especificação de uma solução computacional detalhada.

k) Arquiteto de software: É ele quem toma decisões sobre quais subsistemas compõem o sistema como um todo e quais são as interfaces entre esses subsistemas. E além de tomar decisões globais, esse profissional também deve ser capaz de tomar decisões técnicas detalhadas.

l) Programadores: Talvez o profissional mais conhecido na parte área de sistemas, pois eles são os responsáveis pela implementação do sistema.

117

1 Quais são algumas das atividades de gerenciamento de projeto?

2 Identifique o profissional a que se referem as definições a seguir:

AUTOATIVIDADE

Cargo DescriçãoTalvez o profissional mais conhecido na área de sistemas, pois eles são os responsáveis pela implementação do sistema.Profissional que deve ter o conhecimento do negócio e entender seus problemas para que possa definir os requisitos do sistema a ser desenvolvido. E que deve estar apto a se comunicar com especialistas do domínio para obter conhecimento acerca dos problemas e das necessidades envolvidas na organização empresarial.É ele quem toma decisões sobre quais subsistemas compõem o sistema como um todo e quais são as interfaces entre esses subsistemas. E além de tomar decisões globais, esse profissional também deve ser capaz de tomar decisões técnicas detalhadas.O integrante da equipe de desenvolvimento, cujas funções são: avaliar as alternativas de solução (da definição) do problema resultante da análise.É a pessoa responsável pela gerência ou coordenação das atividades necessárias à construção do sistema. Ele também é o responsável que desempenhará atividades como: orçamento do projeto, estimar o tempo para o desenvolvimento do sistema, definir qual o processo de desenvolvimento, o cronograma das atividades, a mão de obra especializada, bem como os recursos de hardware e software.

3 O gerente de projeto pode encontrar alguns problemas que geram conflito, quais são?

119

UNIDADE 3

REVISÃO DE CONCEITOS DA UML, DIAGRAMAS DE VISÃO

COMPORTAMENTAL E ESTRUTURALE UM DETALHAMENTONOS CASOS DE USO


PLANO DE ESTUDOS

A partir desta unidade você será capaz de:

• revisar conceitos de UML;

• conhecer a visão comportamental dos diagramas da UML;

• aprofundar um pouco mais seu conhecimento nos casos de uso;

• ver exemplo de Diagrama de Classe;

• verificar a aplicação do Diagrama de Sequência.

Esta unidade de ensino contém cinco tópicos. No final de cada um deles você encontrará atividades que contribuirão para a apropriação dos conteúdos.

TÓPICO 1 - UML (UNIFIED MODELING LANGUAGE)

TÓPICO 2 - DIAGRAMAS DA UML: DIAGRAMAS ESTRUTURAIS E COMPORTAMENTAIS

TÓPICO 3 - MODELO DE CASO DE USO

TÓPICO 4 - DIAGRAMA DE CLASSE

TÓPICO 5 - DIAGRAMA DE SEQUÊNCIA

121

TÓPICO 1

UML (UNIFIED MODELING LANGUAGE)

UNIDADE 3

1 INTRODUÇÃO

Nesta unidade será apresentada a linguagem de modelagem unificada, a UML, e a sua importância no desenvolvimento de software. Veremos como uma notação gráfica bem executada no projeto de desenvolvimento de software diminui a dificuldade de entendimento entre as partes envolvidas nessa fase.

Para iniciar os estudos, será apresentada a origem da UML, seus criadores e seus diagramas de modelagem.

Dar-se-á ênfase ao modelo de caso de uso e aos diagramas de classe e de sequência, onde será dedicado um tópico específico para esses diagramas, com o objetivo de ampliar seu conhecimento, devido à sua importância no processo de modelagem.

2 MODELO CONCEITUAL DA UML

A construção da linguagem UML teve muitos contribuintes, mas os principais atores no processo foram Grady Booch (criador da Booch method), James Rumbaugh (criador da OMT) e Ivar Jacobson (criador da OOSE). Esses três pesquisadores, que também eram chamados de “os três amigos”, buscaram aproveitar o melhor das características notações preexistentes, principalmente das técnicas que eles haviam proposto anteriormente, removendo alguns elementos e incluindo outros, com o objetivo de torná-la mais expressiva (BEZERRA, 2015). A UML, ainda segundo o autor, é uma linguagem visual para modelar sistemas orientados a objetos, ou seja, é uma linguagem que define elementos gráficos (visuais) que podem ser utilizados na modelagem de sistemas. Elementos esses que permitem a representação dos conceitos do paradigma de orientação a objeto.

De acordo com Booch et al. (2000), criadores da UML, ela é uma linguagem padrão para a elaboração da estrutura de projetos de software. Pode ser utilizada para a aplicação, visualização, especificação, construção e a documentação de artefatos que façam uso de sistemas complexos de software. Os autores afirmam que a UML é uma linguagem utilizada para:

• Visualizar.• Especificar.

UNIDADE 3 | REVISÃO DE CONCEITOS DA UML, DIAGRAMAS DE VISÃO COMPORTAMENTAL E ESTRUTURAL E UM DETALHAMENTO NOS CASOS DE USO

122

• Construir e• Documentar.

Bezerra (2015) reforça que a UML é independente tanto de linguagem de programação quanto de processos de desenvolvimento. O que significa que ela pode ser utilizada para a modelagem de sistemas, independente de qual linguagem de programação será utilizada e a forma de desenvolvimento.

Booch et al. (2000) alertam que para compreender a UML, você precisa formar um modelo conceitual da linguagem, e isso implica em aprender três elementos principais:

• Os blocos de construção básicos da UML.• As regras que determinam como esses blocos poderão ser combinados e• Mecanismos de uso geral, que dão mais clareza às definições criadas

pelos blocos de construção.

2.1 BLOCOS DE CONSTRUÇÃO BÁSICOS DA UML

O vocabulário da UML abrange três tipos de blocos de construção, segundo Booch et al. (2000):

• Itens (abstrações identificadas como cidadão de primeira classe em um modelo)• Relacionamentos (reúnem esses itens) e • Diagramas (agrupam coleções interessantes de itens).

Existem quatro tipos de itens na UML. Estes itens constituem os blocos de construção básicos orientados a objetos da UML, e você os utilizará para escrever modelos bem formados:

• Estruturais • Comportamentais • Agrupamento e• Anotacionais

2.1.1 Itens estruturais

São os substantivos utilizados em modelos da UML. São a parte mais estática do modelo, representando elementos conceituais ou físicos. Ao todo são sete os itens estruturais, conforme Booch et al. (2000), que definiremos a seguir individualmente:

TÓPICO 1 | UML (UNIFIED MODELING LANGUAGE)

123

• Classes.• Interfaces.• Colaborações.• Casos de uso.• Classes ativas.• Componentes.• Nós.

Classes: As classes são descrições, como conjuntos de objetos que compartilham os mesmos atributos, operações, relacionamento e semântica. As classes implementam uma ou mais interfaces. A sua representação, feita por retângulo, geralmente inclui seu nome, atributos e operações.

Interfaces: É uma coleção de operações que especificam serviços de uma classe ou componente, elas descrevem o comportamento externamente visível desse elemento. A interface define um conjunto de operações (suas assinaturas), mas nunca um conjunto de implementações de operações. São representadas graficamente por um círculo e o respectivo nome. As interfaces raramente aparecem sozinhas, costumam aparecer anexadas a uma classe ou um componente que realiza a interface.

Colaborações: As colaborações contêm dimensões estruturais, assim como comportamentais. Uma determinada classe poderá participar em várias colaborações. Assim, essas colaborações representam a implantação de padrões que formam um sistema. São representadas na forma de elipses com linhas tracejadas, geralmente incluindo seu nome.

Caso de uso: É a descrição de um conjunto de sequência de ações realizadas pelo sistema que proporciona resultados observáveis de valor para um determinado ator. Um caso de uso é realizado por uma colaboração e é utilizado para estruturar o comportamento de itens em um modelo. Semelhante à colaboração, o caso de uso também é representado por uma elipse, mas com linhas contínuas.

Os três itens restantes, ainda continuando com Booch et al. (2000), as classes ativas, os componentes e os nós, são semelhantes às classes, elas descrevem conjuntos de objetos que compartilham os mesmos atributos, operações, relacionamentos e semânticas.


124

Classes ativas: São classes cujos objetos têm um ou mais processos ou threads e, portanto, podem iniciar a atividade de controle. Podemos dizer que o que difere uma classe de uma classe ativa é o fato de que seus objetos representam elementos cujo comportamento é concorrente com o de outros elementos. Outro item que difere é a representação, que neste caso tem linhas mais grossas.

Componentes: São partes físicas e substituíveis de um sistema, que proporcionam a realização de um conjunto de interfaces. Tipicamente, os componentes representam o pacote físico de elementos lógicos diferentes, como classes, interfaces e colaborações. A representação dos componentes é feita por retângulos com abas, incluindo somente seus nomes.

Nós: É um elemento físico existente em tempo de execução que representa um recurso computacional, geralmente com pelo menos alguma memória e, frequentemente, capacidade de processamento. Em um nó pode haver um conjunto de componentes e um nó pode migrar de um nó para outro. Sua representação é um cubo, normalmente com seu nome, segundo Booch et al. (2000).

2.1.2 Itens comportamentais

Os itens comportamentais são os itens que definem as partes dinâmicas dos modelos UML. São também chamados de Verbos do Modelo, representando comportamentos no tempo e no espaço. Constituem itens: interações, máquina de estados e atividades. Existem dois tipos principais de itens comportamentais:

Será detalhado a seguir cada um individualmente.

ESTUDOS FUTUROS

Definição de threads: Um pequeno programa que trabalha como um subsistema independente de um programa maior, executando alguma tarefa específica. Um programa dividido em vários threads pode rodar mais rápido que um programa monolítico, pois várias tarefas podem ser executadas simultaneamente. Os vários threads de um programa podem trocar dados entre si e compartilhar o mesmo espaço de memória e os mesmos recursos do sistema. Acesse o link: <http://www.hardware.com.br/termos/thread>.

NOTA

TÓPICO 1 | UML (UNIFIED MODELING LANGUAGE)

125

Interações: são os conjuntos de troca de mensagens entre objetos, também chamados de comportamento. As interações envolvem outros elementos, inclusive mensagens, sequências de ações (os comportamentos chamados pelas mensagens) e ligações (as conexões entre os objetos). Em UML, as mensagens são representadas por uma seta traçada sob seu nome, conforme Booch et al. (2000).

Máquinas de estado: É um comportamento que especifica as sequências de estado pelas quais objetos ou interações passam durante sua existência em resposta a eventos, bem como suas respostas a esses eventos. Uma máquina de estado abrange outros elementos, incluindo estados, transições (o fluxo de um estado a outro), eventos (itens que disparam uma transição) e atividades (as repostas às transições). Graficamente é representado por um retângulo com bordas arredondadas, com o seu nome e respectivos subestados (BOOCH et al., 2000).

2.1.3 Itens de agrupamento

Itens de agrupamento: São as partes organizacionais dos modelos UML, são os blocos em que os modelos podem ser decompostos. Existe apenas um tipo principal de item de agrupamento, chamado Pacote. Sua representação é como diretórios com guias, geralmente incluindo somente seus nomes e, às vezes, seu conteúdo. Conforme Booch et al. (2000, p. 22):

Um pacote é um mecanismo de propósito geral para a organização de elementos em grupos. Os itens estruturais, os itens comportamentais e até outros itens de grupos podem ser colocados em pacotes. Ao contrário dos componentes (que existem em tempo de execução), um pacote é puramente conceitual (o que significa que apenas em tempo de desenvolvimento).

2.1.4 Itens anotacionais

Itens anotacionais: São as partes explicativas dos modelos de UML, são os comentários utilizados para esclarecer e fazer alguma observação sobre qualquer modelo, e a nota é a forma de representar. Graficamente, uma nota é representada por um retângulo com um dos cantos como uma dobra de página, acompanhado por um texto ou comentário gráfico.

2.2 RELACIONAMENTOS NA UML

Esses relacionamentos são os blocos relacionais básicos de construção da UML. Existem quatro tipos de relacionamentos, são eles:


126

• Dependência.• Associação.• Generalização e • Realização.

Dependência: É um relacionamento semântico entre dois itens, nos quais a alteração de um (o item independente) pode afetar a semântica do outro (o item dependente). Sua representação é feita por linhas tracejadas, possivelmente com setas e ocasionalmente incluindo um rótulo,

Associação: É um relacionamento estrutural que descreve um conjunto de ligações, conforme Booch et al. (2000), em que as ligações são conexões entre os objetos. A agregação é um tipo especial de associação, representando um relacionamento estrutural entre o todo e suas partes. A representação é feita por linhas sólidas, possivelmente direcionadas, ocasionalmente incluindo rótulos e frequentemente contendo outros adornos, como nomes de papéis e multiplicidades.

Generalização: É um relacionamento de especialização/generalização, em que os objetos dos elementos especializados (os filhos) são substituíveis por objetos do elemento generalizado (os pais). Os filhos compartilham a estrutura e o comportamento dos pais. Sua representação é uma linha sólida, com uma seta em branco apontando para o pai.

Realização: É um relacionamento semântico entre classificadores, em que um classificador especifica um contrato que outro classificador garante executar. Esse relacionamento é encontrado entre interfaces e as classes ou componentes que as realizam; e entre casos de uso e as colaborações que os realizam. Sua representação é uma linha tracejada com seta branca, entre uma generalização e um relacionamento de dependência.

127


• A UML é uma linguagem padrão para a elaboração da estrutura de projetos de software. Ela pode ser utilizada para a aplicação, a visualização, a especificação, a construção e a documentação de artefatos que façam uso de sistemas complexos de software.

• Modelo conceitual da UML.

• Blocos de construção básicos da UML.

• Itens estruturais.

• Itens comportamentais.

• Itens de agrupamento.

• Itens anotacionais.

• Relacionamentos na UML.

RESUMO DO TÓPICO 1

128

1 Agora que você conheceu a UML, liste algumas aplicações dela.

2 Quais são os quatro tipos de itens na UML?

3 A definição a seguir se refere a qual item da UML e quais são os itens que a compõem?

“São os substantivos utilizados em modelos da UML. São a parte mais estática do modelo, representando elementos conceituais ou físicos.”

4 Faça a associação correta dos itens estruturais.

AUTOATIVIDADE

É uma coleção de operações que especificam serviços de uma classe ou componente, elas descrevem o comportamento externamente visível desse elemento. A interface define um conjunto de operações (suas assinaturas), mas nunca um conjunto de implementações de operações. São representadas graficamente por um círculo e o respectivo nome.Contém dimensões estruturais, assim como comportamentais. Uma determinada classe poderá participar em várias colaborações. Assim, essas colaborações representam a implantação de padrões que formam um sistema. São representadas na forma de elipses com linhas tracejadas, geralmente incluindo seu nome.É a descrição de um conjunto de sequência de ações realizadas pelo sistema que proporciona resultados observáveis de valor para um determinado ator. Um caso de uso é realizado por uma colaboração e é utilizado para estruturar o comportamento de itens em um modelo. Semelhante à colaboração, o caso de uso também é representado por uma elipse, mas com linhas contínuas. É um elemento físico existente em tempo de execução que representa um recurso computacional, geralmente com pelo menos alguma memória e, frequentemente, capacidade de processamento. São descrições como conjuntos de objetos que compartilham os mesmos atributos, operações, relacionamento e semântica. Elas implementam uma ou mais interfaces. São partes físicas e substituíveis de um sistema, que proporciona a realização de um conjunto de interfaces. Tipicamente representam o pacote físico de elementos lógicos diferentes, como classes, interfaces e colaborações. São classes cujos objetos têm um ou mais processos ou threads e, portanto, podem iniciar a atividade de controle.

129

TÓPICO 2

DIAGRAMAS DA UML: DIAGRAMAS

ESTRUTURAIS E COMPORTAMENTAIS

UNIDADE 3

1 INTRODUÇÃO

Usar a ferramenta certa, para a atividade certa. Agir deste modo, com certeza, facilita e muito o trabalho, você concorda?

Com esse objetivo de facilitar o trabalho e aumentar a produtividade, bem como o entendimento das pessoas envolvidas em cada fase do projeto, é que a UML desenvolveu um diagrama para cada função. Nem sempre se usa todos em todos os projetos, mas é necessário que se tenha o conhecimento do que eles fazem para tirar o melhor proveito e obter sucesso nos projetos.

A seguir será apresentado cada um em detalhes, para que você se sinta confortável em saber qual usar e em que momento.

2 DIAGRAMAS

Um diagrama é a apresentação gráfica de um conjunto de elementos, geralmente representada como gráficos de vértices (itens) e arcos (relacionamentos). Segundo Booch et al. (2000), eles são desenhados para permitir a visualização de um sistema sob diferentes aspectos.

Os artefatos gráficos produzidos durante o desenvolvimento de um sistema, segundo Bezerra (2015), podem ser definidos pela utilização dos diagramas da UML.

Talvez ainda surja o questionamento: “Para que tantos diagramas? ” Segundo Guedes (2014), o objetivo é fornecer múltiplas visões do sistema que está sendo modelado, analisando-o e modelando-o sob diversos aspectos, e procurando, assim, atingir a totalidade da modelagem, permitindo que cada diagrama complemente os outros. Em cada um dos diagramas da UML é analisado o sistema, ou uma parte dele, de um determinado ponto de vista; é como se o sistema fosse modelado em camadas.

Em alguns diagramas o sistema é visto de forma mais ampla, sem muitos detalhes técnicos, apresentando uma visão externa do sistema e de fácil entendimento para pessoas que não têm muito conhecimento técnico, como é o objetivo do Diagrama de Caso de Uso. Diferente de outros diagramas que oferecem

130


uma visão um pouco mais profunda do software, eles têm por objetivo apresentar um aspecto mais técnico ou ainda visualizar apenas uma característica específica do sistema ou um determinado processo.

Guedes (2014) salienta que a utilização de diferentes diagramas permite que falhas possam ser encontradas nos diagramas anteriores e assim diminuir a possibilidade da ocorrência de erros durante a fase de desenvolvimento do software.

Vale ressaltar, como já foi dito anteriormente, que mesmo que cada diagrama tenha sua função, nem sempre é necessário modelar um sistema utilizando-se de todos os diagramas, pois alguns deles possuem funções muito específicas, como é o caso do Diagrama de Tempo, que, por exemplo, tem como objetivo focalizar o tempo ou duração da mensagem ou condições em mudança em uma linha de tempo no diagrama. Detalharemos esse e outros diagramas a seguir.

FIGURA 38 - DIAGRAMAS UML

FONTE: Bezerra (2015, p. 18)

a UML é uma linguagem de modelagem visual, ou seja, é um conjunto de notações e semântica correspondente para representar visualmente uma ou mais perspectivas de um sistema. (BEZERRA, 2015, p. 19)

NOTA

TÓPICO 2 | DIAGRAMAS DA UML: DIAGRAMAS ESTRUTURAIS E COMPORTAMENTAIS

131

A versão 2.0 da UML, como se vê na figura anterior, traz consigo 13 diagramas, que são divididos em quatro grupos: Estruturais, Comportamentais, Implementação e Interação. Esses diagramas serão detalhados a seguir.

2.1 DIAGRAMAS ESTRUTURAIS

De uma maneira resumida, os diagramas estruturais definem a estrutura do sistema tanto na parte de software, quanto de hardware. Como já dissemos, nem todos os diagramas estruturais são necessários para a documentação de um sistema. A seleção correta dos diagramas e a sua combinação são mais importantes para uma modelagem eficiente, do que a modelagem de todos.

2.1.1 Diagrama de Objetos

Este diagrama está amplamente associado ao Diagrama de Classes (detalhado mais adiante). Ele consiste em uma variação do Diagrama de Classes, em que, em vez de classes, são representadas instâncias e ligações entre instâncias. Na verdade, para Guedes (2014), o Diagrama de Objetos é praticamente um complemento do Diagrama de Classes, sendo bastante dependente desse. Este diagrama fornece uma visão dos valores armazenados pelos objetos das classes contidas em um Diagrama de Classes em um determinado momento da execução de um processo. Em outras palavras, ele modela as instâncias das classes contidas no Diagrama de Classes, isto é, o Diagrama de Objetos mostra um conjunto de objetos e seus relacionamentos no tempo. Esses diagramas são importantes para construir os aspectos estáticos do sistema. Normalmente, são compostos por: objetos e vínculos.

Para facilitar o entendimento, a figura abaixo mostra um Diagrama de Objetos para o cliente Silva e seus dois pedidos na COMPRAS & COMPRAS. Podemos ler o diagrama como:

• O objeto Silva da classe Cliente está associado aos objetos 991 e 774, ambos da classe Pedido.

A ordem da documentação dos diagramas não se refere à ordem em que eles devem ser criados.

IMPORTANTE

132


FIGURA 39 - DIAGRAMA DE OBJETOS

FONTE: A autora

2.1.2 Diagrama de Estrutura Composta

De acordo com Guedes (2014), este diagrama é utilizado para modelar colaborações. Uma colaboração descreve uma visão de um conjunto de entidades cooperativas interpretadas por instâncias que contribuem entre si para executar uma função específica. O termo estrutura desse diagrama refere-se a uma composição de elementos interconectados, representando instâncias de tempo de execução que colaboram, por meio de vínculos de comunicação, para atingir algum objetivo comum. Esse diagrama também pode ser utilizado para definir a estrutura interna de um classificador.

FIGURA 40 - EXEMPLO DO DIAGRAMA DE ESTRUTURA COMPOSTA

FONTE: Guedes (2014, p. 21)


133

Para entender um pouco melhor, vamos analisar o modelo sugerido pela IBM. Como a figura ilustra, um Diagrama de Estrutura Composta é exibido no editor de diagrama como uma estrutura que tem o nome do classificador contido (Car). As peças de material composto do classificador e suas conexões de comunicação são exibidas na estrutura do diagrama.

FIGURA 41 - EXEMPLO DO DIAGRAMA DE ESTRUTURA COMPOSTA

A estrutura de diagrama apresenta quatro peças de material composto internas do classificador contido, que representam as quatro rodas do carro e são do tipo Roda. Um link de comunicação conecta as rodas dianteiras e as rodas traseiras com conectores denominados frontaxle e rearaxle. Ou seja, sempre que você cria um Diagrama de Estrutura Composta a partir do classificador Carro, quatro instâncias da classe Roda são criadas. Essas peças são mantidas pela composição dentro da instância Carro e as rodas dianteiras e as rodas traseiras são vinculadas por conectores. Ainda segundo a IBM, os seguintes tópicos descrevem elementos de modelo em diagramas da estrutura composta:

Peças: Em diagramas da estrutura composta, uma peça é um elemento de diagrama que representa um conjunto de uma ou mais instâncias que um classificador estruturado contido possui. Uma peça descreve a função de uma instância em um classificador. Você pode criar peças no compartimento de estrutura de um classificador e em vários diagramas UML, como estrutura composta, classe, objeto, componente, implementação e diagramas de pacote.

Portas: Em diagramas da estrutura composta, uma porta define o ponto de interação entre uma instância do classificador e seu ambiente ou entre o comportamento do classificador e suas peças internas.

Colaborações: Nos diagramas UML, uma colaboração é um tipo de classificador estruturado no qual as funções e atributos cooperam para definir a estrutura interna de um classificador. Você utiliza uma colaboração quando

134


deseja definir apenas as funções e conexões que são requeridas para executar um objetivo específico da colaboração. Por exemplo, o objetivo de uma colaboração pode ser definir as funções ou os componentes de um classificador. Ao isolar as funções principais, uma colaboração simplifica a estrutura e esclarece o comportamento em um modelo.

Usos de Colaboração: Nos diagramas da estrutura composta, um uso de colaboração é um elemento de modelo que representa um uso de uma colaboração para explicar os relacionamentos entre as partes de um classificador estruturado. Você utiliza um uso de colaboração para aplicar um padrão, que é descrito por uma colaboração, para uma situação específica que envolve classes ou instâncias que desempenham as funções de colaboração especificadas. Você pode ter vários usos de colaboração, cada uma envolvendo um conjunto diferente de funções e conectores para uma colaboração determinada.

Conectores em Classificadores Estruturados: Em diagramas UML, um conector é uma linha que representa um relacionamento em um modelo. Ao modelar a estrutura interna de um classificador, você pode utilizar um conector para indicar um link entre duas ou mais instâncias de uma peça ou porta. O conector define o relacionamento entre os objetos ou instâncias que são ligadas a funções no mesmo classificador estruturado e identifica a comunicação entre essas funções. O produto especifica automaticamente o tipo de conector a ser criado.

FONTE:Disponível em:<http://www.ibm.com/support/knowledgecenter/SS5JSH_9.1.1/com.ibm.xtools.modeler.doc/topics/ccompstruc.html?lang=pt-br>. Acesso em: 30 mar. 2016.

2.1.3 Diagrama de Classes

Considerado um dos diagramas mais importantes da UML e um dos mais utilizados, ele serve de apoio para a maioria dos outros diagramas. Como o próprio nome já diz, define a estrutura das classes utilizadas pelo sistema, determinando os atributos e métodos que cada classe tem, além de estabelecer como as classes se relacionam e trocam informações entre si. (GUEDES 2011, p. 31).

Devido à sua importância, o detalharemos um pouco mais no tópico 4.

ESTUDOS FUTUROS


135

2.1.4 Diagrama de Pacotes

Tem por objetivo representar os subsistemas englobados por um sistema de forma a determinar as partes que o compõem. Pode ser utilizado associado com outros diagramas ou de maneira independente. Ele pode ser utilizado também para ajudar a demonstrar a arquitetura de uma linguagem, como ocorre com a própria UML.

Segundo Fowler apud Franco (2014), um pacote é um elemento de agrupamento que permite que você organize suas classes. Interfaces e componentes em unidades de alto nível. Na UML cada classe é um membro de um único pacote, que obriga a organização dessas em pacotes e subpacotes de forma hierárquica.

Por exemplo, se você estiver modelando um sistema distribuído com centenas de classes e que será desenvolvido por equipes diferentes, existe a possibilidade de essas equipes acabarem criando classes com o mesmo nome. Outro objetivo é organizar as classes de acordo com sua responsabilidade, o que auxilia a organizar e estruturar o trabalho de desenvolvimento (FRANCO, 2014).

FIGURA 42 - DIAGRAMA DE PACOTES


136


2.2 DIAGRAMAS COMPORTAMENTAIS

2.2.1 Diagramas de atividade

Esse diagrama era considerado um caso especial do antigo Diagrama de Gráfico de Estados, mas, a partir da UML 2.0, se tornou independente, deixando inclusive de se basear em máquinas de estados e passando a se basear em Redes de Petri, segundo Guedes (2014). Ele se preocupa em descrever os passos a serem percorridos para a conclusão de uma atividade específica, muitas vezes representada por um método ou algoritmo com um certo grau de complexidade, podendo, no entanto, modelar um processo completo. Concentra-se na representação do fluxo de controle e no fluxo de objeto de uma atividade.

FIGURA 43 - DIAGRAMAS DE ATIVIDADES



137

2.2.2 Diagramas de Caso de Uso

Guedes (2014) afirma que este é o diagrama mais geral e informal da UML, sendo utilizado especialmente para auxiliar no levantamento e na análise dos requisitos, em que são determinadas as necessidades do usuário, e na compreensão do sistema como um todo, embora venha a ser consultado durante todo o processo de modelagem e possa servir de base para a maioria dos outros diagramas.

Esse diagrama utiliza uma linguagem simples e de fácil compreensão, para que os usuários possam ter uma ideia geral de como o sistema irá se comportar. Ele procura identificar os atores (usuários, outros softwares que interajam com o sistema ou até mesmo algum hardware especial), que utilizarão de alguma forma o software, bem como as funcionalidades, ou seja, as opções que o sistema disponibilizará aos atores, conhecidas nesse diagrama como Casos de Uso.

Devido à importância desse diagrama, o tópico 3 o detalhará um pouco mais a fundo e o exemplificará.

ESTUDOS FUTUROS

138


FIGURA 44 - EXEMPLO DE CASO DE USO


2.2.3 Diagrama de Transição de Estados

Esse diagrama procura modelar os estados de uma instância de uma classe ou os estados de um processo representado por um Caso de Uso. Embora possa ser usado de forma independente, esse diagrama pode se basear em um Caso de Uso e se apoiar no Diagrama de Classes.


139

FIGURA 45 - DIAGRAMA DE TRANSIÇÕES DE ESTADOS


2.3 DIAGRAMAS DE INTERAÇÃO

2.3.1 Diagrama de Sequência

Preocupa-se com a ordem temporal em que as mensagens são trocadas entre os objetos envolvidos em um determinado processo. Em geral, baseia-se em um Caso de Uso definido pelo diagrama de mesmo nome e apoia-se no Diagrama de Classes para determinar os objetos das classes envolvidas em um processo, bem como os métodos disparados entre esses. Ele costuma identificar o evento gerador do processo modelado, bem como o ator responsável por esse evento, e determina como o processo deve se desenrolar e ser concluído por meio do envio de mensagens que em geral disparam métodos entre os objetos (GUEDES, 2014).

Por ser um diagrama muito utilizado, detalharemos ele um pouco mais no tópico 5.

ESTUDOS FUTUROS

140


2.3.2 Diagrama de Temporização

Esse diagrama somente passou a existir a partir da versão 2.0 da linguagem. Também conhecido como Diagrama de Tempo, descreve a mudança no estado ou na condição de uma instância de uma classe ou seu papel durante um tempo. É tipicamente utilizado para demonstrar a mudança no estado de um objeto no tempo em resposta a eventos externos.

FIGURA 46 - EXEMPLO DE DIAGRAMA DE TEMPORIZAÇÃO


2.3.3 Diagrama de Comunicação

O Diagrama de Comunicação era conhecido, de acordo com Guedes (2014), como Diagrama de Colaboração até a versão 1.5 da UML, tendo seu nome modificado para Diagrama de Comunicação a partir da versão 2.0. Esse diagrama está amplamente associado ao Diagrama de Sequência; na verdade, um complementa o outro. As informações mostradas no Diagrama de Comunicação são, com frequência, praticamente as mesmas apresentadas no Diagrama de Sequência, porém com um enfoque diferente, visto que esse diagrama não se preocupa com a temporalidade do processo, concentrando-se em como os objetos estão vinculados e quais mensagens trocam entre si durante o processo.


141

FIGURA 47 - DIAGRAMA DE COMUNICAÇÃO


2.3.4 Diagrama de Visão Geral de Interação

É uma variação do Diagrama de Atividade que fornece uma visão ampla dentro de um sistema ou processo de negócio. Esse diagrama passou a existir somente a partir da UML 2.0. Costuma englobar diversos diagramas de interação, podendo ser de tipos diferentes, para demonstrar um processo geral (GUEDES, 2014).

142


FIGURA 48 - DIAGRAMA DE VISÃO GERAL DA INTERAÇÃO


2.4 DIAGRAMAS DE IMPLEMENTAÇÃO

2.4.1 Diagrama de Componentes

Está muitas vezes associado à linguagem de programação que será utilizada para desenvolver o sistema modelado. Esse diagrama representa os componentes do sistema quando este for implementado em termos de módulos de código-fonte, bibliotecas, formulários, arquivos de ajuda, módulos executáveis etc., e determina como esses componentes estarão estruturados e interagirão para que o sistema funcione de maneira adequada. Este diagrama pode ser utilizado para modelar, por exemplo, os arquivos de código-fonte de um software, os módulos executáveis de um sistema ou a estrutura física de um banco de dados (GUEDES, 2014).


143

FIGURA 49 - DIAGRAMA DE COMPONENTES


2.4.2 Diagrama de Implantação

Este diagrama determina as necessidades de hardware do sistema, as características físicas como servidores, estações, topologias e protocolos de comunicação, ou seja, todo o aparato físico sobre o qual o sistema deverá ser executado.

144


FIGURA 50 - DIAGRAMA DE IMPLANTAÇÃO


145


• Os 13 modelos que compõem a UML.

a) Diagrama de Objetos: Representa uma “fotografia” do sistema em certo momento. Exibe as ligações formadas entre objetos conforme esses interagem e os valores dos seus atributos.

b) Diagrama de Estrutura Composta: É utilizado para modelar colaborações entre interfaces, objetos ou classes. Detalha partes internas (classe ou componente) que o compõem e como estas se comunicam e colaboram entre si.

c) Diagrama de Classes: Permite a visualização das classes utilizadas pelo sistema e como estas se relacionam. Define a estrutura de classes, atributos e métodos.

d) Diagrama de Pacotes: Demonstra como os elementos do software estão organizados em pacotes e as respectivas dependências.

e) Diagrama de Atividades: Descreve os passos a serem percorridos para a conclusão de uma atividade específica.

f) Diagrama de Caso de Uso: Representa as funcionalidades externamente observáveis do sistema e os elementos externos ao sistema que interagem com ele.

g) Diagrama de Transição de Estados: Baseia-se no Caso de Uso e apoia-se no Diagrama de Classes acompanhando os estados por que passa uma instância de uma classe. Demonstra o comportamento de um elemento através de um conjunto de transição de estado.

h) Diagrama de Sequência: Preocupa-se com a ordem temporal em que as mensagens são trocadas entre os objetos envolvidos em um processo. Representa como o sistema age internamente para que um ator atinja seu objetivo na realização de um caso de uso.

i) Diagrama de Temporização: Enfoca as mudanças de estado de um objeto ao longo do tempo, útil para modelagem de sistemas de tempo real.

j) Diagrama de Comunicação: Associado ao Diagrama de Sequência. São as mesmas informações, porém sem a temporalidade do processo. Concentra-se em como os objetos estão vinculados e quais mensagens trocam entre si.

RESUMO DO TÓPICO 2

146

k) Diagrama de Visão Geral de Interação: É uma variação do Diagrama de Atividades. Fornece uma visão geral dentro de um sistema ou processo de negócio em relação ao controle de fluxo.

l) Diagrama de Implantação: Enfoca a questão da organização da arquitetura física sobre a qual o software irá ser implantado e executado.

m) Diagrama de Componentes: Este diagrama está associado à linguagem de programação que irão para o desenvolvimento do sistema que está sendo modelado.

147

AUTOATIVIDADE

1 Quais são os modelos que compõem os diagramas estruturais?

2 Descreva os componentes do Diagrama de implementação.

3 Qual é o diagrama mais geral e informal da UML? Justifique.

149

TÓPICO 3

MODELO DE CASO DE USO

UNIDADE 3

1 INTRODUÇÃO

Booch et al. (2000) afirmam que nenhum sistema existe isoladamente. E que todo sistema interage com atores humanos ou autômatos que utilizam esse sistema para algum propósito, e esses atores esperam que o sistema se comporte de acordo com a maneira prevista.

Pode-se dizer que uma das utilizações dos Casos de Uso é sua aplicação para captar o comportamento pretendido do sistema que está sendo desenvolvido, sem a preocupação de especificar como esse comportamento será implementado. Eles fornecem uma maneira de compreensão entre os desenvolvedores, usuário final e os especialistas do domínio. Além de auxiliar na validação da arquitetura e para a verificação do sistema durante sua evolução. Vale ressaltar que os casos de uso especificam o comportamento desejado, não determinando como esse comportamento será executado, permitindo assim a comunicação entre os envolvidos.

Para facilitar essa tarefa, Martins (2010, p.12) afirma que o Caso de Uso deve contemplar um processo de ponto a ponto, incluindo vários passos ou transações, de modo a produzir um produto ou serviço de valor para o usuário. O Caso de Uso deve ser composto por um passo ou atividade individual de um processo. Ele sugere alguns questionamentos para facilitar a tarefa de encontrar os casos de uso:

• Quais são as funções requeridas pelos atores?• O sistema armazena informações? • Que atores criam, consultam, atualizam e excluem as informações?• O sistema notifica atores sobre algum evento ocorrido?

Um Caso de Uso é uma descrição de um conjunto de sequências de ações, incluindo variantes que um sistema realiza para produzir um resultado observável do valor de um ator. Um Caso de Uso deve representar um requisito funcional do sistema. Vamos definir os termos e conceitos de um modelo de caso de uso. Veremos também os elementos do Diagrama de Caso de Uso:

• Caso de uso • Atores • Relacionamentos • Associação • Generalização• Dependência: Extensão e Inclusão

150


2 CASO DE USO

Sua representação é feita por uma elipse. É uma descrição de um conjunto de sequência de ações, inclusive variantes, que um sistema executa para produzir um resultado de valor observável por um ator. Ainda segundo Booch et al. (2000), todo Caso de Uso deve ter um nome que o diferencie dos demais casos de uso. Normalmente, um caso de uso é definido exibindo apenas seu nome, conforme mostra a Figura 51:

FIGURA 51 - CASO DE USO

Inserir produto

FONTE: A autora

3 ATORES

Os atores representam papéis desempenhados por usuários ou qualquer outra entidade externa ao sistema (ex. hardware, outros sistemas). Eles podem iniciar casos de uso e também podem prover e/ou receber informações dos casos de uso. (TACLA 2010, p.16).

FIGURA 52 - ATORES

FONTE: A autora

Martins (2010, p.212) sugere algumas perguntas que devem ser feitas para auxiliar na tarefa de encontrar os atores:

• Quem usa o sistema?• Quem instala o sistema?• Quem faz a manutenção dos dados do sistema?• Que outros sistemas se comunicam com este sistema?• Que outros sistemas extraem informações deste sistema?

TÓPICO 3 | MODELO DE CASO DE USO

151

4 FLUXO DE EVENTOS

Um Caso de Uso descreve o que um sistema (ou um subsistema, classe ou interface) faz, mas ele não especifica como isso será feito. Booch (2010) diz que se pode especificar o comportamento de um Caso de Uso pela descrição do fluxo de eventos no texto de maneira clara, para que alguém de fora possa entender facilmente. Durante essa documentação do fluxo de eventos deve-se incluir:

• Quando o caso de uso inicia e termina.• Quando o caso de uso interage com os atores.• Quais objetos são transferidos e• Os fluxos básicos e alternativos.

Segue um exemplo de como documentar um fluxo de eventos:

“Nome do caso de uso”

• Atores:a) (lista dos atores)• Fluxo de eventos:b) Fluxo primário ou básico ou principal (descrição das ações que ocorrem

normalmente)c) Fluxo secundário ou alternativo (ações que ocorrem em situações

adversas, erros, etc.)d) Pré-condições: situação necessária para iniciar o caso de uso.e) Pós-condições: situação após o caso de uso terminar.

Acesse um modelo de um template fornecido para uma Especificação de Caso de Uso, que contém as propriedades de texto do caso de uso. Este documento é usado com uma ferramenta de gerenciamento de requisitos, como o Rational RequisitePro, para especificar e marcar os requisitos contidos nas propriedades do caso de uso, e demonstra detalhadamente como realizar esse processo. Acesse o link: <(http://www.wthreex.com/rup/webtmpl/templates/req/rup_ucspec.htm#2. Flow of Events)>

NOTA

152


5 RELACIONAMENTO

Os relacionamentos indicam associações definidas entre os diversos componentes dos diagramas de Casos de Uso. Os principais componentes a se relacionar em um diagrama são os atores e os Casos de Uso. O relacionamento pode acontecer de diversas formas, dependendo da situação. Durante a construção de um Caso de Uso, os relacionamentos podem envolver dois casos de uso ou mais, dois atores, ou ainda um ator e um caso de uso. Detalharemos esses eventos a seguir.

5.1 RELACIONAMENTO ENTRE ATORES

Relações associativas podem conectar atores para representar comunicação entre eles. A relação pode receber um nome que identifica o conteúdo da mensagem, documento ou objeto que trafega entre os atores. A Figura 53 apresenta uma associação entre dois atores, onde o aluno solicitação a impressão do histórico escolar na secretaria. (TACLA, 2010, p.23).

FIGURA 53 - RELACIONAMENTO ENTRE ATORES

FONTE: A autora

Associação ou comunicação é a mais comum das relações. Pode ser percebida entre dois atores, sua representação é feita por uma linha sólida, indicando a comunicação entre as partes.

5.2 ATOR X CASO DE USO

Já na documentação das associações entre atores e casos de uso, estas servem para indicar se quem dá início à comunicação é o ator ou o Caso de Uso, além de traçar o fluxo da informação, indicando quem alimenta quem com a informação.

A figura a seguir demonstra essa associação ou comunicação entre o ator e o caso de uso, e uma exemplificação de um funcionário e a emissão de um relatório.


153

FIGURA 54 - COMUNICAÇÃO ENTRE ATOR E CASO DE USO

FONTE: A autora

FIGURA 55 - EXEMPLO DE COMUNICAÇÃO ENTRE ATOR E CASO DE USO

FONTE: A autora

5.3 INCLUSÃO E EXTENSÃO

O relacionamento de inclusão é utilizado para incluir um comportamento comum de um caso de uso incluído para um caso de uso base, a fim de suportar a reutilização do comportamento comum.

Ele indica de uma forma explícita que um caso de uso, em algum momento, faz uso de outro caso de uso. Franco (2014, p.28) explica essa atividade:

É como se, para evitar repetição, separássemos parte do comportamento comum em vários casos de uso em um caso de uso distinto, que pode ser agora simplesmente “incluído” por todos os demais. Analogamente, é como separar parte de um algoritmo em um método específico para que todo o resto do programa possa usá-lo simplesmente fazendo uma chamada. Os casos utilizados na inclusão não podem ser acessados diretamente pelos atores do sistema.

Será ilustrado o que foi explicado segundo o autor: um exemplo de uma compra e do pagamento sendo validado com o cartão de crédito.

154


FIGURA 56 - EXEMPLO DE COMPRA COM CASO DE USO

FONTE: Franco (2014, p. 28)

5.4 EXTENSÃO

Já a extensão é quando um Caso de Uso utiliza o comportamento de outro caso de uso em condições especiais. Com o funcionamento semelhante à inclusão, a diferença é que a extensão do comportamento é opcional e ocorre nos chamados pontos de extensão. Como no exemplo apresentado por Franco (2014), observa-se um caso de uso chamado Calcular total da compra e é estendido pelo caso de uso Calcular desconto. A condição para que o desconto seja calculado é que a compra ultrapasse 10.000,00, ou seja, o calcular desconto só será estendido se, e somente se, o valor atender à regra. Como apresenta a Figura 57.

FIGURA 57 - EXEMPLO DE EXTENSÃO

FONTE: Franco (2014, p. 29)

Abaixo temos um exemplo de Melo (2006, p.51), onde encontramos os extends e include em um mesmo modelo. Começaremos apresentando o cenário e a resolução do caso de uso e o diagrama de classe.

Cenário: Dra. Janete é pediatra e tem três consultórios em bairros distintos, onde atende em horários diferentes. Ana, sua secretária, trabalha nos três consultórios. Para que a marcação de consultas seja centralizada, Ana tem que carregar as três agendas de um lado para outro. Dra. Janete contratou um analista free-lancer para lhe desenvolver um sistema que controle a marcação de consultas e a ficha dos pacientes. Para os pacientes é preciso controlar: nome, endereço, telefones de contato, data de nascimento, data da primeira consulta, e-mail, se é particular ou conveniado a plano de saúde. No caso de ser conveniado, registrar qual é o plano de saúde. Para cada plano de saúde credenciado é preciso controlar o limite de consultas no mês, por paciente.


155

Dra. Janete atende no consultório da Ilha às segundas e sextas, de 9h às 18h. Na Tijuca, ela atende às terças e quartas de 10h às 18h. Na quinta, ela atende em Bonsucesso, de 10h às 18h. O intervalo das consultas é de 30 minutos. O horário de almoço é sempre de 12h30min às 13h30min. Só são permitidos três encaixes por dia. Para clientes novos, Ana anota o nome do cliente e o seu telefone. É preciso identificar se uma consulta é de revisão, como, por exemplo, para entrega de exames. Nesse caso, ela não é cobrada. A marcação de consultas deve considerar uma data futura limite.

FIGURA 58 - EXEMPLO COM EXTENDS E INCLUDE

FONTE: Adaptado de Melo (2006, p. 52)

Comentários sobre a resolução: segundo Melo (2006), o caso de uso Manter Agenda é responsável por verificar e exibir a agenda de um consultório numa determinada data. A partir daí, para cada horário vago é possível marcar uma consulta (Extends Caso de Uso Registrar Consulta). Suponha que o usuário queira ver a agenda do dia 30/09/2005. O sistema verificará que dia 30/09 é uma sexta (dia da semana = 6). Para o dia da semana 6, a agenda é do consultório da Ilha. Considerando os atributos desse objeto, o sistema monta a agenda do dia. Inicia com o horário da primeira consulta (9h). Depois monta um horário a cada intervalo de consulta (30 minutos) até o limite do horário de almoço (12h30min).

Algo assim: 9h/ 09h30min /10h /10h30min /11h /11h30 min /12h. O horário da tarde recomeça no fim da hora de almoço (13h:30). A partir daí, continua-se a montar horários respeitando o intervalo de consulta (30 minutos) até o horário limite da última consulta.

A agenda completa ficaria assim: 09h / 09h30min /10h /10h30min /11h /11h30min /12h/13h30min /14h /14h30min /15h / 15h30min /16h /16h30min /17h /17h30min.

156


6 GENERALIZAÇÃO

Uma generalização de casos de uso é um relacionamento de um Caso de Uso filho com um Caso de Uso pai, especificando como um filho pode adotar todo o comportamento e as características descritas para o pai.

Um Caso de Uso pai pode ser especializado em um ou mais casos de uso filho que representam formas mais específicas do pai. Nem o pai, nem o filho, são necessariamente abstratos, embora o pai seja abstrato na maioria dos casos. Um filho herda a estrutura, o comportamento e os relacionamentos do pai. Todos os filhos do mesmo pai são especializações do pai. Essa é a maneira que a generalização se aplica aos Casos de Uso.

A generalização é usada quando você encontra dois ou mais casos de uso que têm comportamento, estrutura e finalidade comuns. Quando isso ocorre, você pode descrever as partes compartilhadas em um caso de uso novo, geralmente abstrato, que é especializado pelos casos de uso filho.

FIGURA 59 - GENERALIZAÇÃO

FONTE: Disponível em: <http://www.wthreex.com/rup/process/modguide/md_ucgen.htm>. Acesso em: 31 mar. 2016.

Bezerra (2015) resume as possibilidades de existência de relacionamentos entre os elementos do modelo de caso de uso na tabela a seguir:


157

TABELA 9 - POSSIBILIDADES DE EXISTÊNCIA DE RELACIONAMENTOS

Comunicação Extensão Inclusão GeneralizaçãoCaso de uso e caso

de uso X X X

Ator e ator XCaso de uso e ator X

FONTE: Adaptado de Bezerra (2015, p. 67)

Para reforçar o entendimento, vejamos o caso de uso proposto por Guedes (2011, p. 67), onde um cliente se dirige ao banco e solicita ao funcionário o encerramento da sua conta. Como sabemos, uma conta, para ser encerrada, precisa ter seu saldo zerado. Este caso de uso representa a funcionalidade de Encerrar Conta utilizada pelo funcionário, que pode eventualmente fazer a chamada do caso de uso Realizar Saque, caso tenha saldo, e caso o saldo seja negativo, deve Realizar Depósito para zerar a conta.

FIGURA 60 - EXEMPLO DE CASO DE USO ENCERRAR CONTA


158


• Um caso de uso é uma descrição de um conjunto de sequências de ações, incluindo variantes que um sistema realiza para produzir um resultado observável do valor de um ator.

• Um caso de uso deve representar um requisito funcional do sistema, e ele é composto por:

a) Casos de uso.

b) Atores.

c) Relacionamentos. d) Associação.

e) Generalização.

f) Dependência: Extensão e Inclusão.

RESUMO DO TÓPICO 3

159

AUTOATIVIDADE

Desenvolva o Diagrama de Caso de Uso para um sistema de controle de cinema, onde:

• Um cinema pode ter muitas salas, sendo necessário, portanto, registrar informações a respeito de cada uma, como sua capacidade, ou seja, o número de assentos disponíveis.

• O cinema apresenta muitos filmes. Um filme tem informações como título e duração. Assim, sempre que um filme for apresentado, deve-se registrá-lo também.

• Um mesmo filme pode ser apresentado em diferentes salas e em horários diferentes. Cada apresentação em uma determinada sala e horário é chamada Sessão. Um filme sendo apresentado em uma sessão tem um conjunto máximo de ingressos, determinado pela capacidade da sala.

• Os clientes do cinema podem comprar ou não ingressos para assistir a uma sessão. O funcionário deve intermediar a compra de ingresso. Um ingresso deve conter informações como o tipo de ingresso (meio ingresso ou ingresso inteiro). Além disso, um cliente só pode comprar ingressos para sessões ainda não encerradas.

161

TÓPICO 4

DIAGRAMA DE CLASSE

UNIDADE 3

1 INTRODUÇÃO

Considerado um dos diagramas mais importantes da UML e um dos mais utilizados, ele serve de apoio para a maioria dos outros diagramas. Como o próprio nome diz, o Diagrama de Classes define a estrutura das classes utilizadas pelo sistema, determinando os atributos e métodos possuídos por cada classe, além de estabelecer como as classes se relacionam e trocam informações entre si. Apresenta um modelo de como os dados serão criados no banco de dados.

2 DIAGRAMAS DE CLASSE

Os Diagramas de Classe são fundamentais para o processo de modelagem de objetos e modelam a estrutura estática de um sistema. A quantidade de diagramas utilizados vai depender da complexidade do sistema. Pode-se utilizar um único diagrama de classe para modelar um sistema inteiro ou vários diagramas de classe para modelar os componentes de um sistema. Eles são úteis em muitos estágios do design do sistema. No estágio de análise, um diagrama de classe pode ajudá-lo a compreender os requisitos do domínio do problema e a identificar seus componentes.

Durante a fase de execução de um ciclo de desenvolvimento de software é possível utilizar diagramas de classe para converter os modelos em código e converter o código em modelos. Você também pode utilizar diagramas de classe para visualizar, especificar e documentar recursos estruturais nos modelos. Por exemplo, durante as fases de análise e design do ciclo de desenvolvimento, é possível criar diagramas de classe para executar as seguintes funções, segundo IBM:

● Capturar e definir a estrutura das classes e outros classificadores.● Definir relacionamentos entre classes e classificadores.

Em um projeto de software orientado a objetos, os diagramas de classe criados durante os estágios iniciais do projeto contêm classes que normalmente são convertidas em classes e objetos de software reais quando você grava o código.

NOTA

162


● Ilustrar a estrutura de um modelo utilizando atributos, operações e sinais.● Mostrar as funções e responsabilidades comuns do classificador que definem o comportamento do sistema.● Mostrar as classes de implementação em um pacote.● Mostrar a estrutura e o comportamento de uma ou mais classes.● Mostrar uma hierarquia de herança entre classes e classificadores.● Mostrar os trabalhadores e entidades como modelos de objetos de negócios.

FONTE: Disponível em: <http://www.ibm.com/support/knowledgecenter/SS8PJ7_9.0.0/com.ibm.xtools.modeler.doc/topics/cclassd.html?lang=pt-br>. Acesso em 30 mar. 2016.

Podemos fazer uma associação entre as classes e o modelo entidade relacionamento (MER), que é muito utilizado para a modelagem estruturada de banco de dados.

FIGURA 61 - COMPARAÇÃO ENTRE CLASSES E MER

FONTE: Ferreira (2009, p. 83)

163

TÓPICO 4 | DIAGRAMA DE CLASSE

Para auxiliar o entendimento, e devido à sua importância, apresentaremos o exemplo a seguir, de Melo (2006, p. 28), referente ao controle de ligações telefônicas, onde deve-se identificar as classes, atributos e os métodos pertinentes a esse cenário:

Cenário: Bruna resolveu desenvolver uma aplicação para controlar as ligações telefônicas de sua casa, a fim de checar se o valor que paga mensalmente está correto. Assim, sempre que desejar, poderá listar as ligações efetuadas num determinado período, contabilizando o valor a pagar. Para que isso seja possível, toda ligação será feita pelo computador. A cada solicitação de ligação, a aplicação deverá registrar: a data da ligação, a hora da ligação, quantidade de minutos gastos (que deve ser registrado no momento em que a ligação for encerrada), o número de pulsos (que deve ser calculado pela aplicação) e o telefone para onde se discou. A aplicação permitirá o controle de uma agenda de telefones, com número do telefone e nome da pessoa de contato. O usuário poderá escolher, no momento da ligação, se deseja um dos registros da agenda ou se digitará diretamente o número do telefone.

A forma de cálculo dos pulsos considera os seguintes critérios:

• A ligação ao ser completada já conta um pulso. A partir daí, a cada quatro minutos de conversação concluída, cobra-se mais um pulso.

• Cada pulso custa R$ 0,08 para ligações locais. • Exemplo:a) Ligação de 2m -1 pulsob) Ligação de 4m30s - 2 pulsosc) Ligação de 8m - 3 pulsos

• Os finais de semana possuem uma promoção. Cada ligação contabiliza somente um pulso, independentemente do número de minutos de conversação.

A resolução apresentada pode ser feita da maneira definida por Melo (2006):

164


FIGURA 62 - SOLUÇÃO

FONTE: Melo (2006, p. 28)

A autora faz algumas considerações em relação ao modelo, Melo (2006, p.30).

a) O relacionamento da classe Ligação com a classe Agenda serve apenas para manter o controle do lugar para onde foi feita a ligação. Entretanto, a multiplicidade é de 0..*, pois no momento da ligação o usuário pode escolher de onde quer obter o telefone, podendo digitar um número sem querer registrá-lo na agenda. O telefone é replicado na classe Ligação, para se manter o histórico de ligações, já que o contato pode ter seu número de telefone alterado.b) O atributo tempoGasto da classe Ligação é derivado, pois seu valor é o resultado do método calcularTempo da classe RegraCalculo. c) O atributo numeroPulsos da classe Ligação é derivado, pois seu valor é o resultado do método calcularPulsos da classe RegraCalculo.d) O caso de uso cadastrarPulsos é responsável por solicitar o cálculo do tempo e baseado nessa informação, calcular o número de pulsos. Como as informações tempo gasto e número de pulsos não são persistidos, então o caso de uso Listar ligações de um período precisa fazer utilização do caso de uso cadastrarPulsos para apresentar o relatório.e) Como o único usuário dessa aplicação é a Bruna, o ator foi identificado como Pessoa.

165



ORIENTAÇÕES BÁSICAS NA ELABORAÇÃO DE UM DIAGRAMA DE CLASSES

por Douglas de Oliveira Tybel

CENÁRIO

Você trabalha para uma empresa de desenvolvimento como analista de sistemas. O responsável pelo setor em que você trabalha, em uma reunião, distribuiu tarefas para cada membro da equipe. Sua tarefa foi desenvolver um Diagrama de Classe para que seja iniciado o desenvolvimento de um novo software.

A empresa que nos contratou deseja adquirir o certificado ISO 9001 em qualidade, entretanto uma das normas repassadas foi que deve ser obrigatório controlar os pedidos de suporte/serviço que são feitos pelos clientes.

O ramo da empresa é Serviçe Desk. O fluxo do processo segue abaixo:

O cliente entra em contato com a central através do telefone;

Um atendente tem um prazo curto para registrar esta solicitação, informando os dados do cliente, o que foi solicitado, o nível de urgência, o grupo de atendimento, o técnico, um ou mais equipamentos envolvidos na manutenção. Anotar toda a interação realizada no equipamento, como, por exemplo: Se ele conectar remotamente ao equipamento, deve informar em um histórico e suponhamos que três segundos depois ele reinicie o equipamento, deverá informar no histórico também. Resumindo: Toda interação deve ser anotada no registro com data e hora.

Caso ele consiga resolver o que foi solicitado, o técnico do Service Desk irá salvar o registro com a situação de “Resolvido” encerrando o caso, contudo, deverá, em um local específico do registro, definir como ele resolveu o caso, informando que se tratava de um Incidente, Problema ou Solicitação. O registro deve ser categorizado, escolhendo dentre três classificações: Categoria >> Subcategoria >> Item da categoria, onde a categoria é uma lista de tipo de serviço, como, por exemplo: Se foi Hardware ou Software.

Para entender um pouco mais sobre esse diagrama, leia o resumo do artigo disponibilizado no material complementar, e para ler na íntegra acesse o site: Disponível em: <http://www.linhadecodigo.com.br/artigo/3219/orientacoes-basicas-na-elaboracao-de-um-diagrama-de-classes.aspx>. Acesso em: 29 fev. 2016.

DICAS

166


A Subcategoria está relacionada com a categoria, pois dependendo do que foi escolhido na primeira lista será mostrada na segunda que será uma Subcategoria, como, por exemplo: No caso da escolha de Hardware, seria informado na Subcategoria algum tipo de peça do equipamento que o técnico interagiu, tipo DVD/R. No caso de Categoria ser Software, a Subcategoria deveria ser qual software, tipo: Word, Excel e etc. E no item da categoria deveria ser escolhido o que foi realizado pelo técnico, no caso de Hardware >> DVD/R, poderia ser SUBSTITUÍDO, LIMPADO etc. No caso de Software >> Word >> INSTALADO,DESINSTALADO etc.

Caso o técnico do Service Desk não consiga resolver no seu prazo que será o mais curto, deverá enviar o registro para outro grupo de atendimento, onde existirão outros técnicos que poderão ir até o equipamento fisicamente para resolver o problema com um prazo mais extenso. Um grupo é composto por vários técnicos. No registro deve constar o grupo que atendeu e o técnico, pois cada registro conta como receita em reais para o grupo sendo apurado ao efetuar fechamento mensal. O pagamento para os grupos de atendimento é feito por quantidade de registros atendidos no prazo estipulado.

Se mesmo o grupo de atendimento físico tentar entrar em contato com o cliente, mas não obtiver sucesso, o técnico poderá deixar o registro agendado. Para realizar esta tarefa devem ser informadas no registro a data e a hora em que será retornado o atendimento do chamado e definir a situação do registro para “Pendente pelo cliente”, definir também a data e hora para o próximo contato. Esta situação de pendência significa que o técnico não está atendendo por culpa do cliente e o tempo em que o registro fica nesta situação será debitado ao final do apuramento, a fim de beneficiar o grupo que o atende, pois cada grupo tem um tempo para atender os registros e se ultrapassar este prazo recebe multa em cima do valor do chamado.

Ao final, caso o pedido tenha sido designado para outro grupo, ou esteja em andamento, pendente, cancelado ou resolvido, deve-se informar em um campo específico o que foi feito neste registro resumidamente. Se a situação do registro estiver definida como “Resolvido”, uma pesquisa de satisfação deverá ser enviada para o solicitante.

IDENTIFICAR OS OBJETOS TANGÍVEIS

Para identificarmos um objeto, precisamos antes entender como vê-lo, para isso basta ter como regra que: O objeto é algo tangível, que podemos percebê-lo à nossa frente, sendo possível encontrá-lo no mundo real ou virtual. Exemplos de objetos que podemos perceber ao ir a uma lanchonete: Mesa, Cadeira, Atendente, Lanche, Bebida e etc.

Vamos tentar encontrar os objetos do nosso cenário, observe o primeiro item abaixo:

O cliente entra em contato com a central através do telefone;

167


Nesta frase acima, podemos identificar como objetos: Cliente e Telefone.

Cliente é considerado um objeto, pois é tangível e existem vários outros iguais a ele com as mesmas características, assim como o telefone.

No segundo item do cenário identificamos:

• Atendente.• Solicitação.• Grupo.• Técnico.• Equipamento.• Histórico.

O único item acima que gera dúvida se é ou não um objeto seria histórico, pois não é normal vermos este objeto, entretanto ele existe, veja o exemplo deste objeto no mundo real: Na escola existe o histórico escolar ou na clínica existe histórico médico e etc.

No terceiro item do cenário identificamos: Categoria, Subcategoria e Item da categoria.

Observe que estes objetos acima são difíceis de identificarmos no mundo real, mas preste atenção no cenário de uma locadora de DVD. Veja que as placas com o gênero dos filmes são categorias, aquelas placas são objetos tangíveis representando categorias, que já seria sua classe-mãe.

Os itens quatro e cinco do cenário estão apenas explicando o processo, não identificamos nenhum objeto novo. No sexto e último item do cenário identificamos os seguintes objetos: Pedido e Pesquisa de satisfação.

IDENTIFICAR OS OBJETOS POR SEUS ATRIBUTOS

Após identificarmos os objetos que estavam visíveis no cenário, agora teremos que encontrá-los através de seus atributos, onde os atributos são características do objeto. Suponhamos que no cenário acima foi falado sobre algum objeto, contudo não foi pronunciado seu nome, dificultando assim sua localização. Para encontrarmos teremos que identificar atributos ou características, como, por exemplo: se no cenário dado acima tivéssemos o atributo CPF, poderíamos identificar que esta característica pertence ao cliente, identificando assim o objeto Cliente sem que seu nome houvesse sido pronunciado no cenário.

Você deve repassar todo cenário novamente em busca destas características sem objetos, abaixo seguem alguns que identifiquei:

• Data.• Hora.• Situação.

168


• Tipo de Serviço.• Prazo. Observe que os atributos Data, Hora, Situação, Tipo de Serviço e Prazo

são referentes ao pedido, sendo assim, para identificarmos novas classes a partir desses atributos, teremos que realizar a seguinte pergunta para cada um deles: “Eu preciso uma lista de: Atributo?”, onde no lugar de Atributo você substitui por atributos acima.

Veja os testes abaixo:

Eu preciso uma lista de Data? = NãoEu preciso uma lista de Hora? = NãoEu preciso uma lista de Situação? = SimEu preciso de uma lista de Tipo de Serviço? = SimEu preciso uma lista de Prazos? = Sim

As perguntas com resposta Sim serão novas classes, seguem abaixo as novas classes encontradas: Situações, Tipo de Serviços e Prazos.

LISTA COMPLETA COM TODOS OS OBJETOS ENCONTRADOS

Listaremos abaixo, para facilitar nossa visualização, todos os objetos encontrados após nossa abstração:

• Cliente.• Telefone.• Atendente.• Solicitação.• Grupo.• Técnico.• Equipamento.• Histórico.• Categoria.• Subcategoria.• Item da categoria.• Pedido.• Pesquisa satisfação.• Situações.• Tipo de Serviços.• Prazos.

AGRUPAR OS OBJETOS POR SEMELHANÇA

Nosso próximo passo é agrupar todos os objetos encontrados por características semelhantes, como, por exemplo: Mesa e Cadeira têm as mesmas características, sendo classificadas como Móveis. Assim devemos trabalhar os itens acima:

169


Cliente, Atendente e Técnico = PessoasSolicitação, Histórico, Pedido e Pesquisa de Satisfação = DocumentosTelefone = Equipamentos

Veja que alguns dos objetos acima não foram classificados, devido à não necessidade de tal processo, pois já está em sua classificação correta, devemos apenas usar o plural, pois normalmente uma classe está no plural devido sua origem em agrupar vários objetos.

ELIMINAR CLASSES DESNECESSÁRIAS OU REPETIDAS

Observe no item anterior que muitas classes são do mesmo gênero, fazendo com que esteja repetida no diagrama, e se uma classe se repete no banco de dados será uma tabela criada sem propósito nenhum.

Para eliminar, vejamos primeiro as classes que agrupamos por semelhança:

Observe que Pedido e Solicitação no cenário fazem referência a uma mesma coisa, assim pode-se então eliminar uma das duas, eu eliminei a solicitação. Veja que Telefone é um item de equipamentos, sendo assim podemos também eliminá-lo:

Abaixo a nova lista de classes:

• Pessoas.• Cliente.• Atendente.• Grupo.• Técnico.• Equipamento.• Histórico.• Categoria.• Subcategoria.• Item da categoria.• Pedido.• Pesquisa satisfação.• Situações.• Tipo de Serviços.• Prazos

MONTANDO O DIAGRAMA DE CLASSE

Para iniciarmos os primeiros passos de nosso diagrama de classe, desenhe em uma folha de papel um retângulo com três divisões para cada classe. Veja abaixo, na figura, como deve ficar:

170


DIAGRAMA DE CLASSE SEM LIGAÇÕES E CARDINALIDADE

REALIZANDO AS PRIMEIRAS LIGAÇÕES

Para efetuarmos a primeira ligação, faremos com os objetos que agrupamos por características semelhantes, como, por exemplo: Clientes, Atendentes e Técnicos se relacionam com pessoas, seguem abaixo as ligações:

-codPessoa-Pessoa

-codPessoa-numTecnico

-codGrupo-codFuncionario

-codCategoria-categoria

-codCategoria-subCategoria

-codItem-item

-codDoc-documento

-codSituação-situação

-codHistorico-codDoc

-codTipo

Pessoas

Clientes Atendentes

Pedidos

Documentos

Situação Histórico_de_AtendimentoEquipamentos

Grupos

Categorias

Sub_Categorias

Itens_da_Categoria

Tipos de Serviços

Técnicos

-codEquipamento

-codPessoa-numAtendente

-codOrdem-codDoc-codCliente-codFuncionario-codGrupo-codTipo-codCategoria-codsubCategoria-coditem

-codPessoa-numCliente+setCadastrar()+getConsultar()

171


EFETUANDO AS LIGAÇÕES ENTRE AS CLASSES

Este ponto é trabalhoso, pois devemos testar classe por classe em busca de ligações, veja abaixo como realizar esta tarefa:

Sabemos que o cliente entra em contato com o atendente que gera um pedido. Com esta informação observamos que um pedido foi gerado da interação entre cliente e atendente, onde um cliente pode solicitar vários pedidos para um atendente e um atendente atende a vários clientes. Sua cardinalidade será N para N, onde N quer dizer muitos, sendo: Muitos para Muitos. Quando ocorre esse tipo

Clientes Atendentes

Pedidos

Documentos

Pessoas

Técnicos

-codPessoa-numCliente

-codOrdem-codDoc-codCliente-codFuncionario-codGrupo-codTipo-codCategoria-codsubCategoria-codItem

-codPessoa-numAtendente

-codDoc-documento


-codPessoa-Pessoa

+setCadastrar()+getConsultar()

PARTE DO DIAGRAMA DE CLASSE ENVOLVENDO DOCUMENTOS

PARTE DO DIAGRAMA DE CLASSE ENVOLVENDO PESSOAS

172


de cardinalidade, nasce uma nova tabela ou classe, entre esses dois foi a classe pedidos, que já havíamos identificado antes. O importante sobre a N para N é que a classe que nasceu recebe os códigos da classe com que fez relação, ficando a classe “Pedido” com o código do cliente e o código da atendente.

Sabemos também que esse pedido será repassado para um técnico que o atenderá, sendo assim, um técnico pode atender a vários pedidos e um pedido pode ser atendido por um técnico, sendo representado por 1-N, lembrando que a classe que recebe o N herda o campo-chave da outra classe como chave estrangeira, sendo assim ficará a tabela de pedidos com mais um campo chamado: código do técnico.

Faça o processo para todas as classes, use sempre a pergunta dessa forma:

Um “Nome de um objeto da classe” pode “nome da ligação (verbo)” um ou vários “nomes da classe”.

Como ficaria entre Pedidos e situação:

Um pedido pode ter uma ou várias situações?

Resposta: Várias, pois ao abrir está em andamento, em outro ponto do tempo pode ficar pendente e ser concluída ao final do serviço.

173


FONTE: Disponível em: <http://www.linhadecodigo.com.br/artigo/3219/orientacoes-basicas-na-elaboracao-de-um-diagrama-de-classes.aspx>. Acesso em: 29 fev. 2016.

DIAGRAMA DE CLASSE COMPLETO

-codPessoa-Pessoa

-codPessoa-numCliente

-codPedido-codEquipamento


-codGrupo-codFuncionario

-codCategoria-categoria

-codCategoria-subCategoria

-codItem-Item-codTipo

-codHistórico-codDoc

-codSituação-codOrdem-tempoNaSituação

-codSituação-situação

+setCadastrar()+getConsultar()

-codPessoa-NumAtendente

-codEquipamento

Pessoas

Atendentes Técnicos

Grupos

Categorias

Sub_Categorias

Itens_da_Categoria

Clientes

Equipamentos

Pedido_Equipamentos

Tipos de Serviços

Situações

Pedido_Situações

Histório_de_Atendimento

-codOrdem-codDoc-codCliente-codFuncionario-codGrupo-codTipo-codCategoria-codsubCategoria-codItem

Pedidos

174


• A importância do Diagrama de Classes na modelagem de sistema.

• A associação entre as classes e o modelo entidade relacionamento (MER), que é muito utilizado para a modelagem estruturada de banco de dados.

• Um estudo de caso onde você pôde reforçar a aprendizagem.

RESUMO DO TÓPICO 4

175

AUTOATIVIDADE

Agora que você já desenvolveu o Caso de Uso, faça o Diagrama de Classe, continuaremos com o mesmo estudo de caso para um sistema de controle de cinema.





177

TÓPICO 5

DIAGRAMA DE SEQUÊNCIA

UNIDADE 3

1 INTRODUÇÃO

Eles detalham a sequência de um processo, representando os atores e objetos envolvidos em um cenário e qual é a sequência de troca de mensagens ao longo do tempo. Ele é baseado em Diagrama de Caso de Uso e ordena como as mensagens são trocadas entre os objetos de forma temporal.

A notação para uma mensagem em um Diagrama de Sequência é uma flecha (geralmente desenhada na horizontal) ligando uma linha de vida a outra. O objeto do qual parte a seta é aquele que está enviando a mensagem (objeto remetente). O objeto para o qual a seta aponta é aquele que está recebendo a mensagem (objeto receptor). O formato da ponta da seta indica o tipo de mensagem sendo enviada (síncrona ou assíncrona). O rótulo da mensagem é posicionado acima dessa seta.

Esse diagrama permite identificar os métodos e atributos de cada classe, assim como as responsabilidades de cada classe na realização de um caso de uso. Os elementos básicos desse Diagrama são (TACLA, 2010, pg. 36):

• Atores: São entidades externas que interagem com o sistema e que solicitam serviços. Normalmente, o ator primário é o responsável por enviar a mensagem inicial que inicia a interação entre os objetos.• Objetos: Representam as instâncias das classes representadas no processo.• Linha do tempo (uma para cada objeto e ator): As linhas de vida compõem a dimensão vertical. Uma linha de vida é composta de duas partes, a cabeça e a cauda. A cabeça é representada por um retângulo com dois compartimentos, no compartimento superior a identificação do objeto é exibida e no compartimento inferior (cuja utilização é opcional) aparecem valores para os atributos definidos na classe do objeto. A cauda corresponde a uma linha vertical tracejada.• Comunicação entre ator e objeto ou entre objetos• Interpretação das mensagens: por exemplo, evento do sistema operacional ou de uma interface, envio de mensagem ou chamada de método.

2 TIPOS DE MENSAGEM

As mensagens são parte importante do Diagrama de Sequência, e elas podem ser identificadas de várias formas, sendo as mais comuns (TACLA, 2010, p.44):

178


• Simples: quando o tipo de mensagem é irrelevante ou ainda não foi definido.• Síncrona: quando enviada, o emissor fica bloqueado aguardando a resposta.• Assíncrona: o emissor não bloqueia até que o receptor envie resposta para continuar seu processamento.• Retorno ou resposta: resposta à mensagem síncrona; pode ser omitida.

2.1 NOTAÇÃO DO DIAGRAMA DE SEQUÊNCIA

FIGURA 63 – NOTAÇÃO DO DIAGRAMA DE SEQUÊNCIA

FONTE: Disponível em: <http://www.dmo.fee.unicamp.br/henrique/cursoc++/diagrama.pdf>. Acesso em: 10 out. 2015.

Neste exemplo apresentado por Guedes (2011, p. 204) enfocamos o início do processo de encerramento de conta de um sistema bancário, onde o cliente solicita ao funcionário o encerramento de uma conta.

Após a solicitação do cliente ao funcionário para o encerramento, o funcionário verifica o saldo.

Vale ressaltar que para encerrar uma conta é necessário antes verificar o saldo dessa. Para que seja depositado o valor, caso o saldo seja negativo, ou sacado caso esteja com saldo positivo.

Neste passo devemos imaginar que o processo de Emitir Saldo já está modelado, e por esse motivo, só faremos sua chamada. A esse processo damos o nome de Usos de interação.

NOTA

TÓPICO 5 | DIAGRAMA DE SEQUÊNCIA

179

FIGURA 64 - ENCERRAR CONTA


Neste outro modelo proposto por Guedes (2014), temos o diagrama para a realização de depósito. Onde o cliente informa ao funcionário (neste caso, o ator funcionário poderia ser um caixa eletrônico) o número da conta que deverá receber o valor a ser depositado. O funcionário, em resposta, faz a verificação se a conta existe através da interface do sistema, esta repassará ao controlador o número da conta que, em resposta, disparará o método consultar_conta. Caso a resposta seja positiva, o funcionário solicitará ao cliente o valor a ser depositado. O funcionário então informará à interface do sistema a quantidade do valor a depositar. Esse valor será repassado ao controlador, que disparará o método depositar_valor. Se a operação for realizada com sucesso, o controlador pedirá à interface que apresente uma mensagem informando que a operação foi concluída.

Além desse processo, o sistema deverá registar também o movimento realizado sobre a conta em questão, e para isso ele faz referência ao processo de Registrar Movimento.

FIGURA 65 - EXEMPLO DE DIAGRAMA DE SEQUÊNCIA


180


Outro exemplo se baseia no caso de uso Enviar Carta. Onde alguém remete uma carta para outro país através de uma agência de correio. Primeiro, a carta é enviada para o país do destinatário. No país, a carta é enviada para uma cidade específica. A cidade, por sua vez, envia a carta para a residência do destinatário.

FIGURA 66 - EXEMPLO DE DIAGRAMA DE SEQUÊNCIA

FONTE: Disponível em: <http://www.wthreex.com/rup/portugues/process/modguide/md_seqdm.htm ->. Acesso em: 29 fev. 2016.


AVALIAÇÃO DE INTERFACES DE FERRAMENTAS CASE PARA ELABORAÇÃO DE DIAGRAMAS DA UML

RESUMO: Um dos benefícios oferecidos pelas ferramentas CASE é orientar e disciplinar o processo de modelagem durante da fase de desenvolvimento do projeto de um software. Porém, muitas vezes a ferramenta não é totalmente explorada do ponto de vista funcional, fundamentalmente pela relativa complexidade do assunto e mesmo por problemas de interfaces. Desta forma, o artigo visa analisar, através de heurísticas de usabilidade, a interface de algumas ferramentas CASE

Veja o artigo na íntegra sobre o comparativo ergonômico de três ferramentas de modelagem em UML. Disponível em: <http://www.atenas.edu.br/faculdade/arquivos/NucleoIniciacaoCiencia/REVISTAS/REVIST2011/4.pdf>. Acesso em: 01 mar. 2016.

DICAS


181

que são utilizadas para elaboração dos diagramas da UML, buscando verificar a contribuição desse aspecto na área de computação.

2.1 FERRAMENTAS CASE

As ferramentas CASE são utilizadas para apoiar a realização de atividades específicas, tais como planejamento e análise e especificação de requisitos (PRESSMAN, 2002). Apesar dos benefícios do uso de ferramentas CASE individuais, atualmente, o número e a variedade de ferramentas têm crescido a tal ponto que levou os engenheiros de software a pensarem não apenas em automatizar os seus processos, mas sim em trabalhar com diversas ferramentas que interajam entre si e forneçam suporte a todo ciclo de vida do desenvolvimento. As seções que seguem apresentam três ferramentas CASE que são utilizadas na elaboração de diagramas da UML

2.1.1 ArgoUML

Segundo Monteiro (2004), a ArgoUML é uma ferramenta CASE baseada na notação UML, que foi desenvolvida pela comunidade de desenvolvedores de código livre Tigris. Ele roda na maior parte das plataformas por ser implementado em Java. De acordo com Vieira (2004), a ferramenta ArgoUML é uma das principais ferramentas open source de modelagem UML e inclui suporte para todos os seguintes diagramas da UML: Diagrama de Classe, Diagrama de Estados, Diagrama de Atividades, Diagrama de Caso de Uso, Diagramas de Colaboração, Diagrama de Utilização/Componentes e Diagrama de Sequência. Segundo a revista Java Magazine (2006), o grande diferencial do ArgoUML em relação a outras ferramentas CASE são os recursos cognitivos embutidos no produto. Em vez de ser apenas um diagramador, documentador e gerador de código, o ArgoUML procura orientar e auxiliar o desenvolvedor na construção dos modelos. Esta ajuda provém de várias regras que são aplicadas continuamente, verificando inconsistências, erros comuns e sugerindo próximos passos.

2.1.2 JUDE

O JUDE é uma ferramenta IDE de desenvolvimento e modelagem de dados (UML), criada sobre a linguagem Java e de uso fácil e intuitivo. Com o JUDE é possível realizar uma modelagem de dados complexa, apresentando os dados para o usuário de clara e objetiva. Após feita toda a modelagem é possível exportar tudo para um arquivo Java, HTML ou exportar cada diagrama em forma de imagem.

Segundo o site da Jude (2011), o JUDE/Community é uma ferramenta de modelagem UML gratuita com funcionalidades básicas. Ele é rico em funcionalidade, oferecendo características como edição e impressão de diagramas UML 2.0, importa/exporta código-fonte Java, saída de gráficos e disposição automática. Ainda de acordo com o site da Jude (2011), os diagramas padrão da UML 1.4 e UML 2.0 que o JUDE/Community trabalha são: Diagrama de Classes, Diagrama de Caso de Uso, Diagrama de Estados, Diagrama de Atividades,

182


Diagrama de Sequência, Diagrama de Comunicação, Diagrama de Componentes e Diagrama de Estruturas Compostas.

Além de aprimoramentos adicionais, o JUDE/Profissional, segundo o site da Jude (2011), é uma ferramenta para projetar sistemas com todas as funcionalidades do JUDE/Community. É aprimorado para o desenvolvimento em negócios, grandes modelos e criação de documentos. Ele provê diagramas UML 2.0 e diagramas adicionais, funcionalidade de impressão melhorada, habilidade de fazer merge com outros projetos JUDE, especificações de caso de uso, input-output de modelos de/para arquivos XML, funções de copiar e colar copy em formato de vetor (EMF), e exportação de informações do projeto em formato CSV. O site Jude (2011) ainda diz que os diagramas padrão da UML 1.4 e UML 2.0 que o JUDE/Profissional trabalha são: Diagrama de Classes, Diagrama de Caso de Uso, Diagrama de Estados, Diagrama de Atividades, Diagrama de Sequência, Diagrama de Comunicação, Diagrama de Componentes, Diagrama de Implantação e Diagrama de Estruturas Compostas.

2.1.3 Microsoft Visio

O Microsoft Visio é um aplicativo gráfico e de desenho, que simplifica o processo de criação de diagramas e gestão de processo. É possível utilizar o Visio para transformar textos e tabelas complicadas e de difícil entendimento em diagramas que comunicam rapidamente as informações. São dezenas de ferramentas e templates prontos para serem utilizados.

O Visio fornece formas e modelos modernos para um conjunto diverso de necessidades de criação de diagramas, incluindo gerenciamento de TI, modelagem de processos, construção e arquitetura, design de interface do usuário, gestão de recursos humanos, gerenciamento de projetos e muito mais, podendo ser utilizado conjuntamente com o SharePoint para compartilhamento de seus diagramas com pessoas da mesma empresa.

Segundo o site Microsoft Office (2011), o Microsoft Visio fornece formas de inteligência predefinidas que representam os elementos na notação UML e oferecem suporte para a criação dos seguintes tipos de diagramas UML: Diagramas de Casos, Diagramas de Estruturas Estáticas, Diagramas de Pacote, Diagramas de Atividade, Diagramas de Gráfico de Estado, Diagramas de Sequência, Diagrama de Colaboração, Diagramas de Componentes e Diagramas de Implantação.

2.2 A IMPORTÂNCIA DA INTERAÇÃO HUMANO-COMPUTADOR E SUAS TÉCNICAS DE AVALIAÇÃO

Segundo a norma ISO 9241, usabilidade é a “capacidade que um sistema interativo oferece a seu usuário, em um determinado contexto de operação, para a realização de tarefas de maneira eficaz, eficiente e agradável”. Já segundo a norma ISO/IEC 9126, usabilidade é a “facilidade com que um usuário pode aprender a operar, preparar entradas para e interpretar as saídas de um sistema ou componente”. Simplificando, podemos dizer que a usabilidade está associada


183

a uma característica de qualidade de software que se refere à sua adequação à utilização pelos usuários. A usabilidade trata da qualidade da interação usuário-computador proporcionada pela interface de um sistema de computação. É importante salientar que a usabilidade está sempre associada a um contexto de utilização do produto; a adequação ao uso significa adequação ao tipo de tarefas ou atividades que se pretende realizar com o produto de software, ao tipo de usuários que tipicamente utilizam o produto e ao ambiente de utilização do produto.

Segundo Zambalde e Alves (2004), o cuidadoso estudo da comunidade de usuários e do conjunto de tarefas deve considerar cinco fatores imprescindíveis que são os principais objetivos do design de interface com o usuário:

a) produtividade do usuário: a interface deve permitir bom desempenho do usuário na realização de suas tarefas. Não se está falando de desempenho do software, que é um atributo de qualidade utilizado na engenharia de software, mas do desempenho do usuário em sua interação com um sistema de software;

b) facilidade de aprendizado: deve ser fácil para o usuário aprender a utilizar o software;

c) retenção do aprendizado com uso intermitente: a interface deve permitir que o usuário (esporádico) consiga utilizar o software adequadamente mesmo quando fica sem usá-lo por um período relativamente longo de tempo;

d) prevenção de erros do usuário: o sistema deve prevenir erros do usuário quando o utiliza em suas atividades. Cabe observar aqui também que não se está falando de erros no programa, mas sim de erros do usuário ao utilizar o sistema;

e) satisfação subjetiva: o usuário deve gostar de utilizar o sistema. Observem que a satisfação é um aspecto subjetivo, pessoal, mas ainda assim importante e que deve ser buscado no desenvolvimento de um produto de software.

A avaliação de interface é um passo muito importante no processo de design de software interativo. Nesse sentido, segundo Rocha e Baranauskas (2000), os testes de usabilidade têm o objetivo de medir quantitativamente o valor alcançado pela interação com o sistema em cada um dos fatores de usabilidade de interesse. Tais testes são classificados em: I) métodos de inspeção; e II) testes empíricos com usuários. Um dos métodos de inspeção é a avaliação heurística, ou seja, a avaliação de alguns princípios reconhecidos de usabilidade. Nielsen (1993) propõe um conjunto de heurísticas que, dispostas em uma tabela, permite, a adequada inspeção de usabilidade de uma interface.

3 METODOLOGIA

Uma das preocupações básicas dos pesquisadores relacionada com as questões metodológicas de suas pesquisas é a reflexão sobre as características específicas dos procedimentos adequados para a realização da pesquisa proposta. Sendo assim, nesse trabalho foi elaborada pelos autores uma tabela, adaptada de

184


Nielsen (1993) (Tabela 1) para análise de algumas ferramentas CASE utilizadas na elaboração de diagramas da UML. Para cada heurística devem ser informados os problemas relacionados e a nota do avaliador entre 0 (RUIM) e 10 (ÓTIMO). A interação do usuário com o sistema foi avaliada de acordo com tais heurísticas, permite assim obter um escore em porcentagem (10 heurísticas, cada uma com pontuação máxima 10) e, por conseguinte, a avaliação da interface, a qual será considerada satisfatória acima de 80%, razoável entre 79% a 50% e insatisfatória abaixo de 49%. A avaliação foi realizada por pesquisadores da área de Sistemas de Informação no mês de agosto de 2011.

1 AVALIAÇÃO DAS FERRAMENTAS CASE

Nesta seção apresenta-se a avaliação da interface de algumas ferramentas CASE utilizadas na elaboração de Diagramas da UML, realizada pelos autores do trabalho, com base nas heurísticas da Tabela 1. A saber:

Ferramenta ArgoUML:

• Ao escolher o tipo de diagrama, aparece o estado do sistema no alto da tela dando ao usuário uma facilidade maior ao criar os diagramas. Isso é importante, pois cada diagrama usa ferramentas diferentes.


185

• Há uma boa interação com o usuário, já que os botões são bem intuitivos e também há o uso de dicas (tooltips) para auxiliar as funções dos botões. O menu é bem completo e fácil de ser usado.

• O controle e liberdade do usuário é relativamente bom, pois pode criar e apagar, porém, deveria ter a função desfazer (undo) e a opção colar e copiar, que ficou a desejar.

• A ferramenta é bem consistente, possuindo uma organização entre as áreas da tela. Ao fechar o programa ou abrir outra aplicação pronta, o sistema pergunta se deseja salvar o trabalho atual, dando maior segurança e evitando perdas. Se há alguma ação que não pode ser executada, a ferramenta não executa tal ação. Por exemplo, se tentar inserir um <<extend>> ou <<include>> entre dois atores, a ferramenta não aceita tal comando e não executa.

• O menu está em português de fácil utilização. Os botões estão bem ilustrados e organizados de maneira que o usuário, mesmo sendo a primeira vez ao usar a ferramenta, não deverá ter grandes problemas ao criar os diagramas.

• Os diagramas podem ser salvos na pasta a critério do usuário, podendo der editados a qualquer momento sem nenhuma complicação ou restrição.

• O sistema possui uma boa interface, com desenhos bem simples de entender. E como possui o “tooltips”, dicas dos botões, se torna mais fácil o uso da ferramenta.

• Não há mensagens de erro ao criar os diagramas. Por exemplo, posso colocar um <<extend>> e um <<include>> na mesma relação do caso de uso que ele aceita.

• A ajuda é bem completa, porém está no idioma inglês, assim como o site oficial do sistema, que também está em inglês.

Ferramenta Jude:

• O JUDE não possui um apelo gráfico tão bom quanto o ArgoUML, ou tantas funcionalidades como Microsoft Visio;

• O sistema não interfere nas ações do usuário.

• Existem somente versões em inglês do sistema, porém a sua interface é amigável.

• Existe em seus menus a opção “Help”, um menu de ajuda que se encontra em inglês.

• A ferramenta Jude Community suporta apenas diagramas da UML 1.4 e UML 2.0.

186


• Existe pré-requisito para a ferramenta ser executada, ter o JRE instalado em seu computador.

• A interface do sistema, além de ser amigável, é intuitiva, facilitando o seu uso.

Ferramenta Microsoft Visio:

• Os diagramas da UML são fáceis de serem localizados na ferramenta.

• Em momento algum o sistema informa das ações que o usuário está fazendo se estão certas ou erradas, sendo assim, o usuário tem total liberdade de trabalhar.

• Existe uma versão da ferramenta em português, facilitando assim o entendimento de todas as funções.

• A ferramenta apresenta um menu de ajuda e um tutorial para facilitar o entendimento de todas as funções.

• Comando desfazer (undo) limitado - número de movimentos limitado.

• Quando um componente de um diagrama é deslocado, as setas de relacionamentos entre eles possuem um acompanhamento automático, evitando erros.

• Os estereótipos, que denotam o relacionamento representado pela seta, não podem ser arrastados separadamente - estão “presos” à seta.

• A ferramenta não possui todos os diagramas da UML.

• Em algumas situações a barra de ferramentas não possui todos os elementos necessários para construir do diagrama.

• A interface da ferramenta é muito simples de ser utilizada, sendo assim o usuário não fica perdido na localização de alguma funcionalidade.

5 COMPARAÇÃO ENTRE AS FERRAMENTAS

A Tabela 2 apresenta uma comparação entre as ferramentas estudadas em relação aos aspectos mais relevantes segundo heurísticas de usabilidade abordadas neste trabalho.


187

CONCLUSÃO

Este trabalho teve por objetivo fazer uma identificação e comparação de ferramentas CASE com suporte à elaboração de diagramas da UML, visando avaliar a usabilidade das ferramentas. Os resultados obtidos permitem identificar as ferramentas Microsoft Visio, com 83 pontos e ArgoUML com 84 pontos, como alcançadora dos resultados satisfatórios, uma vez que atende aos critérios propostos por Nielsen (1993) e às pontuações propostas pelos organizadores. Entretanto, a ferramenta Jude, com 78 pontos, foi classificada como razoável, conforme problemas apresentados na seção de avaliação. Na linha de raciocínio, a preocupação com a interface deve ser uma constante, tanto durante o desenvolvimento de produtos de software – para os desenvolvedores – quanto durante a escolha de uma ferramenta CASE que possa auxiliar as atividades de desenvolvimento. O presente trabalho valeu-se de um estudo exploratório sobre usabilidade em ferramentas CASE voltadas para a elaboração de diagramas da UML.

FONTE: Disponível em: <http://www.atenas.edu.br/faculdade/arquivos/NucleoIniciacaoCiencia/REVISTAS/REVIST2011/4.pdf>. Acesso em: 01 mar. 2016.

188


• Os elementos básicos:

a) Atores: São entidades externas que interagem com o sistema e que solicitam serviços. Normalmente, o ator primário é o responsável por enviar a mensagem inicial que inicia a interação entre os objetos.

b) Objetos: Representam as instâncias das classes representadas no processo.

c) Linha do tempo (uma para cada objeto e ator): As linhas de vida compõem a dimensão vertical.

d) Comunicação entre ator e objeto ou entre objetos.

e) Interpretação das mensagens: por exemplo, evento do sistema operacional ou de uma interface, envio de mensagem ou chamada de método.

• Apresentamos um estudo de caso onde você pôde reforçar a aprendizagem.

RESUMO DO TÓPICO 5

189

AUTOATIVIDADE

Com base no estudo da sala de cinema, continuaremos nossos exercícios, agora desenvolva o Diagrama de Sequência:





190

REFERÊNCIAS

AZEVEDO, S. Por que os projetos falham? Disponível em: http://www.mundopm.com.br/noticia.jsp?id=280>. Acesso em: 22 mar. 2016.

BEZERRA, E. Princípios de análise e projeto de sistemas com UML. Rio de Janeiro: Elsevier, 2015.

BOOCH, G.; RUMBAUGH, J.; JACOBSON, I. UML: guia do usuário. Rio de Janeiro: Elsevier, 2000.

BROOKS, F. P. The Mythical Man-Month: Essays on Software Engineering. Reading, MA: Addison-Wesley, 1975.

DIAS, N. K. B; ARAÚJO, M. A P. Boas práticas na engenharia de requisitos. Disponível em: <https://www.assembla.com/spaces/procsw/documents/bI66qA44Gr34-CeJe5cbLr/download/bI66qA44Gr34-CeJe5cbLr >. Acesso em: 07 fev. 2016.

ENGHOLM JUNIOR, H. Engenharia de software na prática. São Paulo: Novatec Editora, 2010.

FRANCO, C. R; PERINI, L. C; FABRIS, P. P. G. Modelagem de Sistemas Empresariais. Londrina: Editora e Distribuidora Educacional S.A., 2014.

GUEDES, G. T. A. UML2 Guia prático. São Paulo: Editora Novatec, 2014.

GUEDES, G.T.A. UML2 - Uma abordagem prática. 2. ed. São Paulo: Editora Novatec, 2011.

MACÊDO, A. B. L.; SPÍNOLA R. Ciclos De Vida Do Software. Disponível em:<http://www.devmedia.com.br/ciclos-de-vida-do-software-artigo-revista-engenharia-de-software-magazine-36/21099>. Acesso em: 22 mar. 2016.

MARTINS, J. C. C. Gerenciando projetos de desenvolvimento de software com PMI, RUP e UML (colaboração de Fabricio Ramirez) 5. ed. Rio de Janeiro: Brasport, 2010.

MELO, A. C. Exercitando modelagem em UML. Rio de janeiro: Brasport, 2006.PAGES-JONES, M. Fundamentos do desenho orientado a objetos. São Paulo: Makron Books, 2001.

MERIAT, V. Charge da Semana: Como ser um Arquiteto de Software. Disponível em: <http://www.vitormeriat.com.br/category/charges/>. Acesso em: 22 mar. 2016.

191

MORAES, J. B. D. Engenharia de Software 2: técnicas para levantamento de Requisitos. Disponível em: <http://www.devmedia.com.br/articles/viewcomp.asp?comp=9151 >. Acesso em: 22 mar. 2016.

PMI- PROJECT MANAGEMENT INSTITUTE. Um Guia do Conhecimento em Gerenciamento de Projetos (Guia PMBOK®) 5.ed. Newtown Square: Project Management Institute, 2013.

PRESSMAN, R. S. Engenharia de Software: uma abordagem profissional. 7. ed. Porto Alegre: AMGH, 2011.

REZENDE, D. A. Engenharia de Software Empresarial. Rio de Janeiro: Brasport, 1997.

SCRUM. Disponível em: < http://www.scrumguides.org/docs/scrumguide/v1/Scrum-Guide-Portuguese-BR.pdf >. Acesso em: 07 fev. 2016.

SILVA, N. P. Análise de Sistemas de Informação: conceitos, modelagem e aplicações. São Paulo: Érica, 2014.

SOMMERVILLE, I. Engenharia de Software. 9. ed. São Paulo: Pearson Prentice Hall, 2011.

STEFFEN, J. B. Scrum: basicamente scrum. Disponível em: <https://www.ibm.com/developerworks/community/blogs/rationalbrasil/entry/scrum_basicamente14?lang=en>. Acesso em: 11 abr. 2016.

TACLA, C. A. ANÁLISE E PROJETO OO E UML 2.0. Apostila: Departamento Acadêmico de Informática. Universidade Federal Tecnológica do Paraná, 2010.

TAVARES, A. P. A importância da arquitetura de software. Disponível em: <http://www.institutopangea.org/blog/15-a-importancia-da-arquitetura-de-software>. Acesso em: 22 mar. 2016.

VIANA, M. Conheça o Rational Unified Process (RUP). Disponível em: <http://www.linhadecodigo.com.br/artigo/79/conheca-o-rational-unified-process-rup.aspx#ixzz3ySiX8GyR >. Acesso em: 07 fev. 2016.

modelagem de sistemas empresariais - uniasselvi

Documents