Baixe o app para aproveitar ainda mais
Prévia do material em texto
Modelos de Processo de Software Antonio Arias Silva Oliveira 1 1Departamento de Informática – Universidade Federal do Pará (UFPA) Rua Augusto Corrêa, 01 – 66.075-110 – Belém – PA – Brazil {arias,antonio.arias}@globo.com Abstract. We will show the parade of presentations done by several teams of the Piracy of Specialization in it Manages of Projects of Software, in the discipline "Model of Process of Software", supplied by the teacher and master Paulo Bastos. They were 10 models presented by the teams among the days 19/04 to 24/05/2007 in the Federal University of Pará. It was a singular experience, to see those works cousins of the Engineering of Software to be shown and discussed for about 36 students, giving their opinions, asking what nobody had asked. The lesson was reviewed masterfully. We don't know which is the best, but now we are great aware in the transport and orientation of a development team, our role as Managers of Projects of Software. Resumo. Vamos mostrar o desfile de apresentações feito por várias equipes do Corso de Especialização em Gerencia de Projetos de Software, na disciplina “Modelo de Processo de Software”, ministrada pelo professor e mestre Paulo Bastos. Foram 10 modelos apresentados pelas equipes entre os dias 19/04 a 24/05/2007 na Universidade Federal do Pará. Foi uma experiência singular, ver essas obras primas da Engenharia de Software ser mostradas e discutidas por cerca de 36 alunos, dando suas opiniões, perguntando o que ninguém havia perguntado. A lição foi magistralmente repassada. Não sabemos qual é o melhor, mas agora temos grande consciência na condução e orientação de uma equipe de desenvolvimento, nosso papel como Gerentes de Projetos de Software. 1. Introdução Podemos dizer com uma grande dose de certeza que “Modelos de Projeto de Software” é o veículo que conduz qualquer projeto de software rumo ao sucesso e qualidade. Bom, mas qualidade é algo abstrato, difícil de ser definido. Portanto vamos recorrer a um pouco de história da qualidade para podermos entender melhor esse conceito. A história da qualidade está repleta de exemplos de resultados extraordinários: os grandes templos construídos na Grécia e Roma antigas, os feitos de navegação do século XVI, as catedrais medievais. Em todas essas realizações, não se dispunha de instrumentos de precisão ou técnicas sofisticadas. Na França, os construtores de catedrais utilizavam simples compassos e cordas com nós a intervalos regulares para desenhar e construir edifícios [Koscianski 2006]. Na década de 1920 surgiu o controle estatístico de produção. Nas fábricas que produziam grande quantidade de itens tornou-se impossível garantir a qualidade individual de cada peça, ao contrário do que se fazia (e ainda faz) no trabalho artezanal. Dessa forma foi preciso desenvolver mecanismos diferentes e a resposta veio da estatística. Um dos pioneiros trabalhos associados ao assunto é o livro publicado por Walter Shewhart em 1931, Economic Control of Quality of Manufactured Producto. Shewhart, dos Bell Laboratories, teria introduzido os diagramas de controle (control charts ou Shewhart chart). [Koscianski - 2006]. Na década de 1940 foi fundado a ABNT (Associação Brasileira de Normas Técnicas) e a ISO (International Standardization Organization). Também o Japão destacou-se como um importante pólo no assunto e contribuiu com diversas novas ferramentas: o método de Taguchi para projeto experimental, a metodologia 5S ou, ainda, os diagramas de causa e efeito de Ishikawa, também conhecidos como diagrama espinha de peixe. [Koscianski - 2006] Estas citações nos mostram claramente que a qualidade de um programa de computador segue as mesmas especificações de um produto qualquer da indústria tradicional. 2. Os Modelos de Desenvolvimento Vamos então nos focar nos modelos, como eles surgiram e evoluirão. Nas décadas 1960 e 1970 ocorreram mudanças tecnológicas importantes que afetaram a construção dos computadores e, em conseqüência, a de software. O período é conhecido como “crise de software” e as repercussões são sentidas até hoje [Pressman, 2002]. A maior causa da crise de software é que as máquinas tornaram-se várias ordens de magnitude mais potentes! Em termos diretos, enquanto não havia máquinas, programar não era um problema; quando tivemos computadores fracos isso se tornou um problema pequeno e agora que temos computadores gigantescos, programar tornou- se um problema gigantesco. [Koscianski, 2006] 2.01. Modelo em Cascata No dia 19 de abril de 2007, na disciplina “modelos de processos de software”, do curso de Especialização em Gerencia de Projetos de Software, foi dado inicio a um desfile de apresentações, feitas pelos alunos. O primeiro o “Modelo em Cascata”. Dos modelos prescritivos, o cascata é, sem dúvidas, o mais referenciados e discutidos em estudos e trabalhos acadêmicos e aplicações. Quando os requisitos de um problema são razoavelmente bem compreendidos, o trabalho flui da comunicação de um modo razoavelmente linear, recomenda-se o cascata. O modelo em cascata é o paradigma mais antigo da engenharia de software, entretanto nas últimas décadas esse modelo tem sofrido muitos questionamentos. Talvez por essa razão ele seja o modelo mais evidente. Podemos citar três problemas em que o cascata é aplicado: 1) Projetos reais raramente seguem fluxos seqüenciais que o modelo propõe. Apesar de o modelo linear poder acomodar iterações, ele o faz indiretamente. Como resultado, as modificações podem causar confusão à medida que a equipe de projeto prossegue. 2) Em geral, é difícil para o Cliente estabelecer todos os requisitos explicitamente. O modelo em cascata exige isso e tem dificuldade de acomodar a incerteza natural que existe no começo de muitos projetos. 3) O Cliente precisa ter paciência. Uma versão executável do(s) programa(s) não vai ficar disponível até o período final do intervalo de tempo do projeto. Um erro grosseiro pode ser desastroso se não for detectado até que o programa executável seja revisto. [Pressman, 2005] 2.02. Modelo de Desenvolvimento Evolucionário Este modelo busca o desenvolvimento de software evoluindo a partir de protótipo inicial. Todos os conceitos e idéias vão sendo materializado em requisitos a medida que o protótipo evolui, até atingir o produto idealizado. O objetivo é trabalhar com o Cliente em toda a fase do desenvolvimento, a partir das especificações iniciais. Entretanto os requisitos devem ser bem compreendidos. O modelo evolucionário pode trazer diversas vantagens, tais como antecipar o produto final para avaliação do Cliente, manter uma comunicação entre os desenvolvedores e usuários para solucionar problemas técnicos e antecipar o treinamento dos usuários. 2.03. Modelo de Desenvolvimento Rápido (RAD) Aqui o objetivo principal é a velocidade do desenvolvimento. O termo Rapid Application Development (RAD) se aplica a projetos que tem prazos curtos e que geralmente usa prototipagem e ferramentas de desenvolvimento de alto nível. A orientação é a construção de componentes e que os requisitos e o escopo sejam bem conhecidos por diferentes equipes, conforme figura 1. Figura 1 – Modelo de processo RAD Modelagem do Negócio: O fluxo de informação entre os módulos de função d negócio são modeladas para que possa responder: • Qual a informação que dirige o processo do negócio? • Qual a informação gerada? • Quem processa? • Quem gera a informação? • Para onde vai a informação? Modelagem dos dados: O fluxo definido na modelagem do negócio é refinado em um conjunto de objetos de dados necessários para dar suporte ao negócio; Aqui são identificadas as características e seus relacionamentos para cadaobjeto. Modelagem do Processo: Os objetos de dados são transformados para obter uma função de negócio. Geração da Aplicação: De posse dos componentes a aplicação é gerada. São utilizados ferramentas automatizadas tal como o GeneXus. 2.04. Modelo Formal Este modelo requer Clientes tecnicamente bem preparados, engenheiros de software com conhecimento profundo do negócio em questão. E as especificações devem ser bem consistentes, claras sem qualquer ambigüidade. Utiliza fortemente os modelos matemáticos nas especificações. Portanto recomendado para aplicação extremamente crítica Os métodos formais têm um potencial tremendo para melhorar a clareza e a precisão da especificação dos requisitos e de encontrar erros importantes e sutis. O método é formal tem uma sólida base matemática, dada tipicamente por uma linguagem formal de especificação. Essa base fornece um meio para definir precisamente noções como consistência e completeza, e mais relevantemente, especificação, implementação e correção. 2.05. Modelo de Desenvolvimento Orientado a Reuso A reutilização sempre foi utilizada por outras engenharias. Apenas nos últimos anos é que a engenharia de software começou adotar o reuso como uma abordagem prática no desenvolvimento de software. A reutilização é o processo de incorporar em um novo produto: • Código; • Plano de Teste; • Conhecimento Geral; • Especificações de requisitos e projetos. 2.06. Modelo de Desenvolvimento Incremental O modelo incremental combina diversos elementos do Modelo em Cascata, dividindo os requisitos em incrementos, de maneira a garantir um melhor entendimento e uma maior participação do Cliente. Usa bem o conhecimento adquirido em projetos anteriores. É um modelo que objetiva minimizar os riscos do projeto, dando maior importância aos requisitos mais importantes. Veja figura 2. Figura 2 – Modelo de processo Incremental Podemos dizer que este modelo é de fácil gerenciamento. Possibilita o aumento da qualidade do software, facilitando a integração e reduzindo as falhas. E o projeto pode ser tocado com pouca mão-de-obra. Entretanto trata-se de um modelo, cujo software desenvolvido é de difícil modularização. Também não permite alterações nos requisitos durante os incrementos. 2.07. Modelo de Desenvolvimento em Espiral Este modelo surgiu com o objetivo de resolver os seguintes problemas: - Os projetos raramente seguem o fluxo seqüencial que o modelo Cascata propõe - No início do projeto é difícil para o cliente especificar os requisitos explicitamente - Na Prototipagem o cliente vê o que parece ser uma versão executável do software, ignorando que o protótipo apenas consegue funcionar precariamente. Para tanto é esperado que os requisitos básicos estejam bem entendidos, muito embora os detalhes ainda precisem ser definidos. O produto evoluirá com o tempo, gerando versões cada vez mais completas. 2.08. Modelo do Processo Unificado O RUP é uma abordagem de desenvolvimento de software de forma iterativa, baseada na arquitetura e dirigida por casos de uso, que são levantamentos de requisitos baseados na visão do usuário. Também pode ser definido como um processo de engenharia de software bem definido e bem estruturado. Definindo de forma clara e precisa quem é responsável, como e quando será feito. É composto por cinco elementos principais: papéis, atividades, artefatos, fluxos de trabalho e disciplinas, conforme figura 3. Figura 3 – Fases e disciplinas do modelo RUP Após atingir o consenso dos envolvidos, dentro da fase conhecida como concepção, inicia-se a meta dominante. O objetivo da fase concepção é estabelecer o escopo do sistema, fazer um esboço da arquitetura, identificar os riscos, estimar tempo/custo e a viabilidade do sistema. E na seqüência as atividades básicas, com o planejamento e preparação do caso de negócio, formular o escopo, sintetizar a arquitetura e preparar o ambiente. Depois as fases de Elaboração, Construção e Transição, onde o software já pode ser disponibilizado para o usuário final. 2.09. Modelo Paxis Este modelo tem o foco principal no processo educacional da engenharia de software. Orientado a objetos e baseado em paradigmas de grande difusão: UML, SW- CMM, UP e IEEE. Pode ser bem adaptado a uso individual ou para pequenas equipes. Indicado para organizações em vias de melhoria de processos. Segue fortemente o Processo Unificado e as fases são compostas por uma ou mais iterações. Os fluxos são divididos em uma ou mais atividades, sendo essas iterações e atividades exemplos de passos. As fases são: Concepção, Elaboração, Construção e Transição. E os fluxos técnicos são: Requisitos, Análise, Desenho, Implementação, Testes e Engenharia de Sistemas. E os fluxos gerenciais são: Gestão de Projetos, Gestão de Qualidade e Engenharia de Processos. 2.10. XP (eXtreme Programming) Quando Kent Beck e outros 16 notáveis desenvolvedores, produtores e consultores, em 2001, assinaram o “Manifesto Agil”, estavam buscando valorizar: - Indivíduos e interações em vez de processos e ferramentas. - Software funcionando em vez de documentação abrangente - Colaboração do cliente em vez de negociação de contratos - Resposta a modificações em vez de seguir plano Data a dificuldade de predizer quais requisitos serão mantidos e quais vão mudar, bem como quais prioridades mudarão. Da mesma forma é muito difícil precisar quando um projeto estará pronto para começar. Assim projeto e implementação são feitos juntos. O eXtreme Programming busca melhorar a comunicação entre o Cliente e a Equipe de desenvolvimento e entre a própria Equipe. É o olho - no - olho. Simplicidade para fazer o necessário e respeito ao ser humano. Baseado em princípios e nas práticas para trabalhar lado a lado, Equipe e Cliente. Decidindo fazer o que realmente é importante fazer em reuniões, normalmente em pé, dando assim maior agilidade as decisões. [Astels 2002] O XP é normalmente recomendado para projetos sujeitos a mudanças, com equipes pequenas e Clientes com domínio do negócio. 3. Conclusão Com este desfile de modelos é possível compreender que toda a dificuldade de se construir software pode, com simples adoção de um ou mais modelos, assegurar grande controle da situação do processo de software. Como em outras engenharias, os processos são bem definidos e normalizados para que perdure por todo o ciclo de desenvolvimento do produto. E caso aja possível melhoria a ser feita no modelo, é providenciado para uma próxima instancia do referido modelo. Na engenharia de software também deve ser assim. E mesmo com as dificuldades naturais de se fazer algo pouco tangível, devemos buscar adequar um modelo a ser seguido. Qual deles? Isso é importante mas, nem tanto. O mais importante é adotar um e segui-lo o mais fielmente possível para que os benefícios possam ser colhidos. Deve ser dado tempo suficiente para as tarefas advindas dos modelos, preencher os documentos preparar os artefatos, seguir o script à risca. As adaptações são necessárias e devem ser feitas mas, sem reinventar a roda, se ela já está disponível use-a. 4. References Astels, David; Granville Miller e Miroslov Novak, eXtreme Programming – Guia Prático, 2002 Koscianski, André. Qualidade de software, 2006
Compartilhar