Beruflich Dokumente
Kultur Dokumente
1. Introduo
Qualificar um produto muito bom para que tenhamos certeza de que h seriedade e preocupao com a satisfao em t-lo, mas, qualificar o processo de produo mais importante para obter um produto melhor. Ambas as qualificaes (da produo e do produto) so largamente utilizados na produo de muitos produtos inclusive no desenvolvimento de softwares. Hoje, temos normas da ISO 9003 que certificam o processo de produo de software bem como o software pronto. Tais normas exigem cada vez mais qualidade no gerenciamento do projeto e tais exigncias so convertidas em benefcios para os usurios e desenvolvedores. Todo desenvolvimento de um software caracterizado por fases que quando colocados em seqncia obtm-se um Ciclo de Vida do Sistema e este ciclo de vida que deve ter qualidade. Conforme observaes feitas durante os ltimos 20 anos, em centenas de organizaes que variam de tamanho de algumas at milhares de pessoas, com uma faixa de 1 at 1000 projetos simultaneamente a caminho. Como pode ser esperado, as menores firmas costumam ser relativamente informais: os projetos so iniciados como resultado de uma discusso verbal entre o usurio e o gerente do projeto, e o projeto prossegue da anlise de sistemas at o projeto e implementao sem muita algazarra. Em grandes organizaes, no entanto, as coisas so feitas em uma base muito mais formal. As vrias comunicaes entre os usurios gerncia e equipe do projeto costumam ser documentados por escrito, e todos entendem que o projeto passar por diversas fases antes que seja terminado. Ainda assim existe grandes diferenas entre o modo com que dois gerentes de projetos na mesma organizao conduzem seus respectivos projetos. Normalmente fica a cargo do gerente de projeto determinar de que fases e atividades o seu projeto consistir e como essa fases sero conduzidas. 1.1. Definio de um ciclo de vida Recentemente, no entanto, o mtodo assumido para o desenvolvimento de sistemas comeou a mudar. Mais e mais grandes e pequenas organizaes esto adotando um nico e uniforme ciclo de vida do projeto, ou simplesmente "o modo com que fazemos as coisas por aqui". Normalmente contido em um livro to exuberante quanto o manual de padres que se encontra (fechado) a mesa de cada programador, o ciclo de vida documentado do projeto fornece uma forma comum para que todos na organizao passem a entender como pode ser desenvolvido um sistema de computador. O mtodo pode ser caseiro, ou alternativamente, a organizao pode decidir comprar um pacote de gerenciamento de projeto e depois mold-lo s necessidades da companhia. Deve ser aparente que, alm de fornecer emprego para as pessoas que criam manuais de ciclo de vida de projetos, a metodologia de projeto desejvel. Qual, ento, a finalidade de se ter um ciclo de vida de projeto? H trs objetivos principais:
Engenharia de Software 1. Ciclo de Vida de Software - 1
1. Definir as atividades a serem executadas em um projeto. 2. Introduzir a coerncia entre muitos projetos na mesma organizao 3. Fornece pontos de checagem para controle de gerncia e pontos de checagem para a deciso "ir / no ir". O primeiro objetivo particularmente importante numa grande organizao em que novas pessoas esto constantemente, entretanto nas fileiras da gerncia de projeto. O gerente de projeto inexperiente pode no examinar ou subestimar a significncia de importantes fases do projeto se seguir apenas sua prpria intuio. Na verdade, pode acontecer que os programadores e analistas de sistemas jnior no entendam onde e como os seus esforos se encaixam no projeto de um modo geral, a menos que tenham recebido uma descrio apropriada de todas as fases do projeto. O segundo objetivo importante em uma grande organizao. Para os nveis mais altos de gerncia, pode ser extremamente desconcertante tentar supervisionar 100 projetos diferentes, cada um deles sendo executado de uma forma diferente. O terceiro objetivo de um ciclo de vida padro do projeto refere-se necessidade de gerncia em controlar um projeto. Em projetos triviais, o nico ponto de checagem provavelmente o fim do projeto: ele foi terminado dentro do prazo e com o oramento previsto? Mas, para grandes projetos, a gerncia deve ter uma srie de pontos de checagem intermedirios, gerando oportunidade para determinar se o projeto est atrasado e se precisam ser obtidos recursos adicionais. Alm disso, um usurio inteligente tambm pedir pontos de checagem em diversos estgios no projeto, de modo que possa determinar se quer continuar prorrogando o prazo! Apesar de tudo isto o ciclo de vida no ir fazer o projeto, mais ele ajudar a organizar as atividades, tornando mais provvel que voc atinja os problemas exatos na hora exata. 1.2. Escolha do Ciclo de Vida No existe uma regra ou um ciclo de vida padro para desenvolvimento de sistema. Voc pode usar um ciclo pr-definido por um determinado autor, pode usar o ciclo de um autor e mold-lo conforme seu trabalho ou ainda criar seu prprio ciclo. Porm, a escolha deve ser feita analisando os fatores: ? Caractersticas do fornecedor (equipe de desenvolvimento) ? Habilidade - Analisar os conhecimentos tcnicos da equipe. ? Viso - A equipe deve ter conhecimento do domnio do problema a ser informatizado. ? Recursos - Equipamentos e material humano ? Tempo - Tempo disponvel para o desenvolvimento ? Caractersticas do cliente (usurio) ? Viso - Conhecimento de suas necessidades ? Tempo - Aceitvel para a implantao ? Recurso financeiro - Ter disponibilidade financeira para o investimento em software e hardware ? Insegurana - Confiabilidade nos resultados a serem gerados pelo sistema Mesmo adotando um modelo de desenvolvimento, se os itens acima no forem bem avaliados, a qualidade do produto final poder no ser satisfatrio. Tanto modelagem estrutural quanto na modelagem orientada existem muitos ciclos. A seguir sero apresentados os mais usuais.
O modelo cascata apropriado para sistemas transacionais onde as rotinas e procedimentos a serem automatizados so altamente estruturados. A principal desvantagem desta abordagem o alto custo de correo das especificaes quando nas fases de Teste e Implantao. Nesse ciclo, nenhum tipo de modelo criado, no so utilizadas tcnicas de estruturao e quase no existe oportunidade para o usurio realizar alguma alterao em pontos dos requisitos congelados. As atividades so realizadas em seqncia e no existem retornos entre as atividades e toda a documentao produzida aps o trmino do projeto. Assim, fica evidente que os projetos realizados com este ciclo de vida se
Engenharia de Software 1. Ciclo de Vida de Software - 3
caracterizam pela alta incidncia de manuteno, pois esto sujeitos a poucas alteraes durante o desenvolvimento.
Globalizao
Procedimentos possuem esta caracterstica de volatilidade, pois sofrem constantes alteraes, seja por fatores pessoais, quando existe troca de pessoas e mtodos, por decises governamentais e legislativas, por fatores de calamidade, e outros, externos s atividades normais da empresa. Para que uma empresa mude seus dados, toma-se necessrio que a mesma mude sua atividade-fim, por exemplo: em uma indstria metalrgica, seus dados somente iro mudar quando a mesma se transformar em uma empresa agrcola ou fechar e abrir como ferro-velho. Conclui-se que os dados, so imutveis durante o ciclo de vida de uma empresa, mudando somente os valores presentes nos dados, mas no o conceito do dado em si. Quando se adota uma metodologia baseada em modelo de dados, com trabalhos iniciais e extensos de modelagem, consegui-se obter um domnio do negcio da empresa, temos uma fotografia global da mesma. Isto d algum ganho no processo de desenvolvimento? se considerar que esses ganhos so uma relao direta entre tempo, qualidade e custo, toma-se bvio que a anlise de um sistema com tcnicas que permitam conhecimento perfeito e compreenso ampla do negcio em um espao de tempo reduzido, permitir desenvolver e obter qualidade na aplicao, principalmente sobre a informao, e consequentemente um retorno positivo na relao de custo x beneficio para o projeto de desenvolvimento do si
6. Modelo Incremental
Modelo que divide o desenvolvimento do sistema em partes (mdulos), cada uma das quais desenvolvida seguindo as fases do modelo waterfall. Tem como caractersticas liberar pores de cdigo mais cedo, porm requer cuidadoso planejamento. O desenvolvimento incremental parece ser uma opo melhor para sistemas grandes, pois proporciona liberao por partes, exibindo resultados teis j nos primeiros momentos do projeto. Na prtica, funciona como se o sistema fosse dividido em subsistemas, e para cada subsistema houvesse a aplicao de um ciclo em cascata. Portanto, em vez de fazer anlise de todo o sistema, feita a anlise de apenas parte do sistema; porm, esta anlise precisa estar concluda para que seja iniciado o projeto. Outra questo que o custo de integrao dos subsistemas pode ser alto, ou at mesmo invivel em alguns dos casos, onde subsistemas so desenvolvidos em paralelo por equipes diferentes. Este problema se agrava quando o grau de complexidade do sistema elevado o que tem sido muito comum nos dias de hoje. O processo evolutivo compe-se de duas fases, um perodo de explorao seguido de um perodo de desenvolvimento evolutivo. O perodo de explorao determina os requisitos que o sistema dever atender, e o desenvolvimento evolutivo corresponde a uma srie de etapas, cada qual destinada a produzir determinadas funcionalidades do sistema.
Fase Exploratria
Requisitos Funcionais Principais Classes de Negcio Arquitetura do Sistema Ambiente Tecnolgico
Especificao
Fase Evolutiva
Especificao Especificao Especificao Especificao
Projeto
Projeto
Projeto
Projeto
Projeto
Construo
Construo
Construo
Construo
Construo
Teste
Teste
Teste
Teste
Teste
Generalizao
Genera lizao
Generalizao
Generalizao
Generalizao
Durante a fase exploratria, o desenvolvedor dedica-se a compreender aquelas reas mais desconhecidas para ele. Para tanto, esta fase inclui: ? Identificao dos requisitos funcionais ? Elaborao de um esboo do modelo do domnio da aplicao ? Elaborao de um esboo da arquitetura tecnolgica ? Planejamento da fase evolutiva Segue-se ento a fase evolutiva, onde as diversas etapas planejadas daro origem ao sistema. As etapas podem ser executadas em seqncia ou em paralelo, dependendo da equipe disponvel e respeitando as relaes de precedncia que algumas etapas possam apresentar.
Especificao
Especificao Projeto
Projeto
Construo
Construo
Teste
Teste Generalizao
Generalizao
a) O cliente v o que parece ser uma verso trabalhando do software, sem perceber que na pressa de oferecer algo trabalhando, no foram considerados aspectos de qualidade e de manuteno. Quando informado de que o produto deve ser reconstrudo, o cliente "implora" para no mude. b) O desenvolvedor muitas vezes assume um compromisso de implementao para obter um prottipo trabalhando rapidamente. Um sistema operacional ou linguagem de programao inadequados podem ser usados simplesmente porque esto disponveis e so conhecidos.
Com cada iterao ao redor da espiral (comeando no centro e trabalhando para fora), verses progressivamente mais completas do software so construdas. Durante o primeiro circuito ao redor da espiral, os objetivos, alternativas e restries so definidas e riscos so identificados e analisados. Se a anlise de risco indica que existem dvidas nos requisitos, a prototipao pode ser usada no quadrante de engenharia para assistir tanto o desenvolvedor como o cliente. Simulaes e outros modelos podem ser usados depois para definir o problema e refinar os requisitos. O cliente avalia o trabalho de engenharia (quadrante de avaliao do cliente) e faz sugestes para modificaes. Com base nas entradas do cliente, ocorre a prxima fase do planejamento e anlise de risco. A cada loop ao redor da espiral, o ponto culminante da anlise de risco resulta na deciso "continuar ou no". Se os riscos forem muito altos, o projeto pode ser encerrado. No entanto, em muitos casos, o fluxo ao redor da espiral continua, com cada caminho movendo os desenvolvedores para fora em direo a um modelo mais completo do sistema e, ultimamente, o modelo operacional. Todo circuito ao redor da espiral requer engenharia (o quadrante inferior) que pode ser executado usando a abordagem de prototipao ou o modelo clssico de ciclo de vida. O modelo espiral para engenharia de software pode ser considerado como o modelo mais realista para o desenvolvimento de sistemas grandes. Ele usa uma abordagem
Engenharia de Software 1. Ciclo de Vida de Software - 10
"evolucionria" para engenharia de software habilitando o desenvolvedor e o cliente a entender e a reagir aos riscos na evoluo de cada nvel. Usa o mecanismo de prototipao como um mecanismo de reduo, mas mais importante, habilita o desenvolvedor a aplicar a prototipao em qualquer estgio na evoluo do produto. Mantm tambm a abordagem por etapas do modelo clssico, mas incorpora uma estrutura interativa que reflete de forma mais realista o mundo real. O modelo espiral demanda uma considerao direta dos riscos tcnicos em todos os estgios do projeto, e se propriamente aplicado, reduziria os riscos antes que eles se tornem problemticos.
9. NORMA ISO/IEC 12207 A Engenharia de software ganhou muita importncia ultimamente, devido a grande demanda do uso de softwares, que so usados por muitos produtos. S que o desenvolvimento e a manuteno do software uma tarefa nova, e por no ter uma produo com regras bem definidas ou normalizadas como as demais engenharias, deixa muito a desejar seja por parte dos usurios que muitas vezes no vem seus anseios totalmente ou parcialmente atingidos, alm de terem gastos, ou por parte das entidades desenvolvedoras que tambm no conseguem alcanar uma produtividade e lucros satisfatrios. Por isso a comunidade mundial envolvida com desenvolvimento de software vem criando normas para regular e orientar a produo do software. Uma dessas normas a ISO/IEC 12207 sob o ttulo de Information technology Software Life Cycle Process ( tecnologia da informao - Processos de Ciclo de Vida de Software), que foi criada para estabelecer uma estrutura comum de processos, para ser utilizada como referncia em negcios relacionados a produtos de software, e tambm considera que o desenvolvimento e manuteno do software devem ser conduzidos de forma semelhante a engenharia. Esta norma agrupa os processos de ciclo de vida do software em trs classes, que representam a sua natureza. Cada Processo definido pelas suas atividades, e cada atividade adicionalmente definida pelas suas tarefas, sendo que cada atividade subordinada a um processo um conjunto de tarefas intimamente ligadas. Uma tarefa um requisito, uma declarao prpria, uma recomendao ou uma ao permissvel, ou seja tarefa o que o processo deve fazer. A norma tambm escreve o processo de adaptao que contm as atividades bsicas para adaptar a norma a uma organizao ou projeto especfico. A norma possui 74 atividades e 224 tarefas, conforme infogrfico , que apresenta o desdobramento dos processos, atividades e tarefas da norma: DESDOBRAMENTOS DOS PROCESSOS DA NORMA ISO/IEC 12207 CLASSE PROCESSO ATIVIDADES TAREFAS S Fundamental 5 35 136 Apoio 8 25 61 Organizacional 4 14 27 Total 17 74 224
Engenharia de Software 1. Ciclo de Vida de Software - 11
A norma possui uma guia ISO/IEC/JTC1/SC7/WG7 N94 Information Technology Guide for ISO/IEC 12207, que orienta as organizaes em seus projetos de acordo com : Tecnologias envolvidas podendo ser utilizada por qualquer mtodo ou tcnica de engenharia de software, bem como para qualquer linguagem de programao. Arquitetura do ciclo de vida - Estabelece uma arquitetura de alto nvel do ciclo de vida de software, que tem como princpios : Modularidade e responsabilidade. Aplicaes em organizaes : A norma forma um conjunto abrangente de processos para suprir vrios tipos de organizaes. Aplicao em projetos : A norma foi escrita para ser usada em complexos projetos de software. Contudo ela foi planejada para ser adaptvel a um projeto de software de qualquer tipo, tamanho e complexidade, ou quando o software for uma entidade isolada, uma parte embutida ou integral de um sistema total. Implementao de princpios de gerncia de qualidade : Implementa os princpios de gerncia de qualidade, e os executa em trs passos bsicos : Integrao da qualidade no Ciclo de vida, Processo de garantia da qualidade e Processo de melhoria em nvel de organizao e corporao, para gerenciamento da qualidade de seus prprios processos estabelecidos. Os 17 processos da norma so agrupados em trs classes gerais : Fundamentais , Apoio e Organizacional 9.1. PROCESSOS FUNDAMENTAIS Atendem o incio e a execuo do desenvolvimento, operao ou manuteno de produtos de software. 1- Processo de Aquisio : Define as atividades do adquirente, organizao que adquire um sistema ou produto de software, inclui tambm emisso de pedido de proposta, seleo de fornecedor e gerncia do processo de aquisio. 2- Processo de Fornecimento : Define as atividades do fornecedor, organizao que prov o produto de software ao adquirente, determina os procedimentos e recursos necessrios para gerenciar e garantir o projeto, o desenvolvimento e a execuo dos planos de projeto at a entrega do sistema, ou software para o adquirente. 3- Processo de Desenvolvimento : Define as atividades do desenvolvedor, organizao que define e desenvolve o produto, contm as atividades para anlise de requisitos, projeto, codificao integrao, testes, instalao e aceitao relativo ao software. 4- Processo de Operao : Define as atividades do operador, organizao que prov servio de operao de um sistema computacional no seu ambiente para seus usurios, cobre tambm o suporte operacional. 5- Processo de Manuteno : Define as atividades do mantenedor, organizao que prov os servios de manuteno do software, ou seja os servios de manuteno para deixar o software atualizado. Seu objetivo modificar um produto de software existente, preservando a sua integridade. 9.2. PROCESSOS DE APOIO Auxiliam um outro processo e contribuem para o sucesso e qualidade do projeto de software, empregado e executado, quando necessrio por outro processo. 1. Processo de documentao : Define as atividades para registro das informaes geradas por um processo ou atividade do ciclo de vida.
2. Processo de Gerncia de Configurao : Define as atividades para a aplicao de procedimentos administrativos e tcnicos, por toda a vida do software, identifica e define os itens de software em um sistema, bem como estabelece suas linhas bsicas. 3. Processo de Garantia da Qualidade : Define as atividades para fornecer a garantia adequada para que o software esteja de acordo com seus requisitos especificados. 4. Processo de Verificao : Define as atividades para verificao se os produtos de software atendem completamente os requisitos impostos a ele. 5. Processo de Validao : Define se os requisitos do produto final atende o uso especifico proposto. 6. Processo de Reviso Conjunta : Define as atividades para avaliar a situao e produtos de uma atividade de um projeto, se apropriado, executado tanto no nvel de gerenciamento quanto no nvel tcnico. 7. Processo de Auditoria : Define as atividades para determinar adequao aos requisitos, planos e contrato, quando for apropriado. 8. Processo de Resoluo de Problema : Define um processo para analisar e resolver os problemas, que so descobertos durante a execuo do desenvolvimento, operao , manuteno ou outros processos. 9.3. PROCESSOS ORGANIZACIONAIS So utilizados com o intuito de melhorar continuamente a estrutura e os processos do Ciclo de vida do Software. 1. Processo de Gerncia : Define as atividades do responsvel pelo gerenciamento do produto, do projeto e das respectivas tarefas, como aquisio, fornecimento, desenvolvimento, operao, manuteno ou processos de apoio. 2. Processo de Infra-estrutura : Define as atividades para estabelecer e manter a infra-estrutura necessria para qualquer processo, como hardware, software, ferramentas, para desenvolvimento e manuteno. 3. Processo de Melhoria : Define as atividades bsicas para o estabelecimento, avaliao, medio, controle e melhoria do ciclo de vida de software. 4. Processo de Treinamento : Define as atividades para o treinamento do pessoal que vai utilizar o software. Podemos concluir que para a rea de tecnologia da informao, a ISO/IEC 12207 a norma mais significativa desde o surgimento da famlia de normas ISO 9000, pois a primeira norma internacional que prov um conjunto completo de processos, atividades e tarefas que podem ser aplicados durante a aquisio de um sistema que contm software, de um produto de software independente ou de um servio de software, e durante o fornecimento, desenvolvimento, operao e manuteno de produtos de software, provendo tambm processos que podem ser utilizados para definir, controlar e melhorar os processos de ciclo de vida de software. 9.4. PERGUNTAS RELATIVAS AO TEMA : 1. Cite o principal objetivo da norma internacional ISO/IEC 12207, e suas caractersticas? R - O principal objetivo da norma ISO/IEC 12207, o estabelecimento de uma estrutura comum de processos, para ser utilizada como referncia em negcios
Engenharia de Software 1. Ciclo de Vida de Software - 13
relacionados a produtos e servios de software. Alm disso, a norma considera que o desenvolvimento e a manuteno de software deveriam ser conduzidos da mesma forma disciplicada que a engenharia. A estrutura descrita na norma utiliza-se de uma terminologia bem definida, composta de processos, atividades e tarefas a serem aplicados em operaes que envolvam, de alguma forma, o software, seja atravs da aquisio, fornacimento, desenvolvimento, operao ou manuteno. Essa estrutura tambm permite estabelecer ligaes claras com o ambiente de engenharia de sistemas, ou seja, aquele que inclui software, hardware, pessoal e prticas de negcios. Caractersticas : A norma possui um guia que orienta as organizaes na utilizao e adaptao da norma em seus projetos de acordo com os seguintes tpicos : Tecnologias envolvidas, arquitetura do ciclo de vida, aplicao em organizaes, aplicao em projetos, e implementao de princpios de gerncia de qualidade. 2. Explique de forma resumida as trs classes em que so agrupados os 17 processos da norma ISO/IEC 12207 , e mostre para cada classe os seus respectivos processos. R. Processos Fundamentais : Atendem o incio e a execuo do desenvolvimento, operao ou manuteno de produtos de software durante o ciclo de vida de software. 1. Processo de Aquisio 2. Processo de fornecimento 3. Processo de Desenvolvimento 4. Processo de Operao 5. Processo de Manuteno. Processos de Apoio : Auxiliam um outro processo e contribuem para o sucesso e qualidade do projeto de software. 1. Processo de documentao 2. Processo de gerncia de configurao 3. Processo de garantia da Qualidade 4. Processo de Verificao 5. Processo de Validao 6. Processo de Reviso Conjunta 7. Processo de Auditoria 8. Processo de resoluo de Problemas. Processos Organizacionais : So empregados por uma organizao para estabelecer e implementar uma estrutura constituda de processos de ciclo de vida e pessoal associados, melhorando continuamente a estrutura e os processos. 1. Processo de gerncia 2. Processo de Infra-estrutura 3. Processo de Melhoria 4. Processo de treinamento.