2. QUESTÕES DE GERENCIAMENTO DE PROJETO DE SOFTWARE

Transcrição

1 1. IDENTIFICAÇÃO DO SISTEMA Sistema: EPSI - Event Programming System Interface Descrição: Sistema computacional cujo objetivo é o gerenciamento de eventos. 2. QUESTÕES DE GERENCIAMENTO DE PROJETO DE SOFTWARE 2.1 Descreva e ilustre, a metodologia que vocês estão utilizando. Considere as práticas, as etapas e/ou fases, os artefatos e os recursos. (João) Descrição do RUP Visão Geral Técnica Primeiramente, o RUP é uma metodologia conhecida pela sua formalidade, garantindo assim uma boa formalização da modelagem do projeto. Uma documentação apropriada é essencial para qualquer grande projeto; note que o RUP descreve como documentar a funcionalidade, restrições de sistema, restrições de projeto e requisitos de negócio (Gestão dos Requisitos). O RUP ajuda no planejamento do controle da qualidade e cuida da sua construção em todo processo, envolvendo todos os membros da equipe. Nenhuma tarefa é especificamente direcionada para a qualidade; o RUP assume que cada membro da equipe é responsável pela qualidade durante todo o processo. O processo foca na descoberta do nível de qualidade esperado e provê testes nos processos para medir este nível. Em todos os projetos de software, mudanças são inevitáveis. RUP define métodos para controlar, rastrear e monitorar estas mudanças. O RUP foca na produção da arquitetura básica nas primeiras iterações. Esta arquitetura do sistema então se torna um protótipo nos ciclos iniciais de desenvolvimento. A arquitetura desenvolve-se em cada iteração para se tornar a arquitetura final do sistema. O RUP trabalha com modelagem visual, garantindo um entendimento sobre "O que deve ser feito", baseando-se em diagramas com base na UML. O RUP provê uma solução disciplinada de como assinalar tarefas e responsabilidades dentro de uma organização de desenvolvimento de software. Como o RUP prevê uma boa documentação e divisão do trabalho em tarefas, é uma metodologia ideal para se trabalhar em ambientes distribuídos de desenvolvimento. Com o RUP, tem uma grande facilidade de passar informações sobre o projeto, sem ter que sentar e explicar todos detalhes a uma pessoa, assim temos a facilidade de

2 treinar e inserir novos colaboradores ao projeto, já em andamento. Com o RUP, temos uma maneira de desenvolvimento de software que é iterativa, centrada à arquitetura e guiada por casos de uso. O RUP possui cinco elementos principais: papéis, atividades, artefatos, fluxos de trabalho e disciplinas. PAPEIS define o comportamento e as responsabilidades de um determinado indivíduo ou grupo de indivíduos trabalhando como uma equipe. Papéis não são indivíduos e nem títulos de trabalho. Um indivíduo pode assumir vários papéis (analista, projetista...); ARTEFATOS é um pedaço de informação que é produzido, modificado ou utilizado em um processo. Os artefatos são os produtos de um projeto. São as coisas produzidas durante o desenvolvimento do projeto; FLUXOS DE TRABALHO (WORKFLOWS): É uma sequencia das atividades que produzem um resultado de valor observável. O RUP utiliza três tipos de fluxos de trabalho: Fluxos de trabalho principais, associados com cada disciplina; Fluxos de trabalho de detalhe, para detalhar cada fluxo de trabalho principal; Planos de iteração, que mostram como a iteração deverá ser executada. DISCIPLINAS É uma coleção de atividades relacionadas que fazem parte de um contexto comum em um projeto. No RUP temos 9 disciplinas: divididas em disciplinas do processo e de suporte. As disciplinas de processo são: modelagem de negócios, requisitos, análise e projeto, implementação, teste e distribuição. As de suporte são: configuração e gerenciamento de mudanças, gerenciamento de projeto, e ambiente. ATIVIDADES Uma atividade é uma unidade de trabalho que um indivíduo executa quando está exercendo um determinado papel. Cada atividade pode ser dividida em passos. CICLO DE VIDA: Possui quatro fases: iniciação, elaboração, construção e transição. Cada uma é concluída por um marco, ou seja, cada fase é basicamente um intervalo de tempo entre dois marcos. Concepção (define o escopo do projeto); Elaboração (detalha os requisitos e a arquitetura);

3 Construção (desenvolve o sistema); Transição (implanta o sistema). FASES: Indicam a ênfase que é dada no projeto em um dado instante. Para capturar a tempo concepção elaboração construção transição dimensão do tempo de um projeto Descrição do RUP no EPSI Após discutido os conceitos técnicos do RUP, vamos apresentar como esta metodologia é aplicada na construção do EPSI. Sabemos que o RUP prevê quatro fases básicas na construção de sistemas. Sendo assim, ilustramos estas fases da seguinte forma: Na figura acima, descrevemos as fases da metodologia, os artefatos que deverão

4 ser construídos em cada fase do projeto. O projeto se iniciou na fase de concepção e caminha no sentido das setas, no sentido horário. Na transição de casa fase, é previsto uma revisão, cujo objetivo é realizar uma homologação do que foi realizado anteriormente. Se os artefatos construídos passarem na homologação, o projeto caminha para a próxima fase, se for reprovado, o artefato gerado, na fase em homologação, é analisado e refeito ou modificado, conforme for o caso. Os testes realizados em cada transição de fase, também é importante para o gerenciamento de recursos. Principalmente no que diz respeito a reusabilidade. Construir artefatos que sejam reutilizáveis é um desejo inquestionável. É bem melhor especificar cedo as exigências de recursos de recursos de software. Dessa forma, a avaliação técnica das alternativas poderá ser realizada e a aquisição poderá ocorrer em tempo oportuno. 1 Durante a transição de fase, é importante também, realizar um levantamento dos recursos necessários para se realizar a construção da próxima fase, e fazer uma analise dos recursos utilizados na construção da fase anterior. Tal medida ajuda no controle de aspectos como tempo, recursos humanos, financeiros e tecnológicos. Isso evitará que o projeto seja abandonado antes de sua conclusão por falta de recursos. Nota-se também, que entre os artefatos descritos na figura acima, em cada fase do projeto, nem todos correspondem aos artefatos descritos originalmente na metodologia RUP. Tais artefatos foram inseridos com o objetivo principal de melhor adaptar o RUP à organização (fabrica de software). Isso também ajuda a obter mais qualidade no processo, pois sabemos que o bom entendimento e controle do processo de desenvolvimento de software ajuda a obter qualidade no processo. O RUP não cobre todos os aspectos de gerência de projetos de software, como: recursos humanos, custo e orçamento, subcontratação e etc. Porém para os aspectos relacionados ao produto de software, o RUP descreve algumas das atividades e técnicas desempenhadas pelo gerente de projeto. 2 Como a citação acima diz, o RUP não cobre todos os aspetos da gerencia de 1 PRESSMAN, Roger S. Engenharia de Software: Pearson Makron Books, Pág

5 software. Para isso colocamos artefatos que não fazem parte do RUP original, afim de cobrir as necessidades que nossa fábrica deseja. Abaixo citamos alguns artefatos extras ao RUP, e a devida justificativa por utilizar tal artefato. Custo: O RUP não prevê disciplina para tal atividade. Colocamos na fase de Concepção, a disciplina que gera um artefato de custo: Estimativa de custo e tempo. Aquisição: O RUP também não contempla esta atividade. No nosso projeto, durante o monitoramento das atividades e no planejamento do projeto, entraremos em contato com fornecedores de recursos, afim de ter uma estimativa financeira para o projeto. Recursos Humanos: Também não há mapeamento no RUP. Como alternativa, quando fazemos a distribuição dos use cases a serem construídos, analisamos os recursos humanos necessários. 2.2 Ilustre e comente com o seu sistema como tal metodologia provê suporte gerencial efetivo para os stakeholders (Helton) A fase de Concepção contém os workflows necessários para que as partes interessadas (stakeholders) concordem com os objetivos, arquitetura e o planejamento do projeto. Se as partes interessadas tiverem bons conhecimentos, então, pouca análise será requerida. Caso contrário, uma análise maior será requerida. Como cita o RUP, o ideal é que sejam feitas iterações. Porém estas devem ser bem definidas quanto a sua quantidade e objetivos. 3 A partir da concepção do EPSI, já nos preocupamos com os stakeholders. Afinal o sistema vai ser usado e construído por pessoas. Quando se faz um Diagrama de Caso de Uso (baseado nos requisitos) apare os atores. Atores estes que são de inteira importância para a elaboração do projeto e de tomadas gerenciais efetivas. Terminada a construção do Diagrama de Caso de Uso, passamos então para a distribuição das tarefas. Análise de gerenciamento de recursos, principalmente humanos, são fundamentais nesta fase do projeto. Um Diagrama de Caso de Uso, descreve as funcionalidades que o sistema vai possuir. A partir destas funcionalidades, podemos gerenciar uma equipe de trabalho, dividir as atividades, realizar planos e metas de construção para o software, entre outras 3

6 atividades gerenciais. Exemplo, vejamos o Diagrama de Caso de Uso de Negócios do EPSI: Com base no Diagrama, podemos distribuir as tarefas, e montar nossa equipe de trabalho. Como temos três membros para trabalhar no projeto, com um tempo razoável, e não podemos contratar mais mão de obra, podemos montar uma equipe e distribuir as tarefas da seguinte forma: RESPONSÁVEL CASO DE USO / ATIVIDADE Helton M. Adigneri Gerenciar Evento, Realizar Cadastro, Alterar Cadastro. João C. Peres Simular Catraca,Cadastrar Gestor, Verificar Informativo, Realizar Inscrição. Leandro C. Manso Gerenciar Evento, Realizar Consulta, Imprimir Boleto. Distribuímos e controlamos as responsabilidades de cada integrante da equipe no projeto EPSI. Também é interessante salientar que a partir deste ponto, no projeto, é possível (e desejável) gerenciar os seguinte stakeholders: Atores: Podemos entender e manter um fluxo de informações sobre as pessoas que irão atuar diretamente no sistema que será construído. Esse processo irá se estender durante todo a execução do projeto. Isso é fundamental para a construção da arquitetura do EPSI. Clientes: Foco principal, manteremos um contato permanente durante o projeto com o cliente. Deste o inicio do levantamento do EPSI, o cliente sempre mereceu

7 atenção especial, respeitando a individualidade de cada cliente em si. Colaboradores: É a equipe de trabalho em si. Será gerenciada durante o processo todo. Será monitorada seu desempenho, através de uso de ferramentas cases, relatórios e principalmente através da ferramente DotProject, que faz o controle das atividades que serão desenvolvidas e atribuídas a cada pessoa presente no projeto. Órgãos governamentais: Pouco é lembrado em projetos de software, mas a fábrica de software tem que respeitar regras governamentais de seu país. Tributos, leis trabalhistas e de direitos autorais, etc... devem ser gerenciados e merecem atenção na organização do projeto. Isso tudo representa gasto financeiro. Concorrentes: Fazer estrategias para prestar um bom serviço com produto de qualidade é fundamental para se manter uma organização no mercado. Modelar soluções de software inovadores é um o objetivo visado. 2.3 Elabore documentos, para ilustrar como uma aplicação da metodologia viabiliza e economiza recursos no processo de construção do seu sistema. Vocês não vão se esquecer do 5W2H. Está pática facilita o entendimento dos stakeholders. (Leandro) Pretendemos com o RUP obter economia de recursos: Humanos; Tecnológicos (hardware e software) Financeiros. Sendo assim, elaboramos duas planilhas, uma para recursos humanos e outra para recursos financeiros. Recursos Tecnológicos tem impacto direto nos recursos financeiros. **Planilha anexada no final do trabalho. 2.4 Como pode ser definida e caracterizada a Qualidade de um software. Quais são os seus atributos. Defina, comente e ilustre como ela pode ser implementada, considerando os aspectos (Garantia de qualidade, Controle da qualidade e Padrões de qualidade) (João) Existem várias definições na literatura do que é qualidade de Software. Mas segundo Pressman, qualidade de Software é: Conformidade a requisitos funcionais e de desempenho explicitamente declarados, a padrões de desenvolvimento claramente documentados e a características implícitas que

8 são esperadas de todo software profissionalmente desenvolvido. 4 Também segundo a NBR isso 9000:2005, qualidade é o grau no qual um conjunto de características inerentes satisfaz aos requisitos. Concluímos que Qualidade de Software, apesar de suas varias definições, é intensificamente influenciada pelos requisitos. Por isso, primeiramente, para termos um software de qualidade, necessitamos ter um documento de requisitos bem claro e conciso. O segundo ponto da qualidade de um Software, temos que seguir os padrões especificados, que definem um conjunto de critérios de desenvolvimento que orientam a maneira seguindo a qual o sistema passa pelo trabalho de engenharia. Um outro ponto fundamental, são os requisitos implícitos. São requisitos que não são mencionados na documentação de requisitos. O analista deverá estar atendo a estes tipos de requisitos e procurar atende-los para obter qualidade no sistema. Segundo McCall, os atributos de qualidade são: Corretitude: é quando o sistema satisfaz e cumpre sua especificação, viados pelo cliente; Confiabilidade: é a medida que se pode esperar que o sistema realize sua tarefa com uma precisão desejada. Eficiência: é a quantidade de recursos de computação e de código exigida para que um programa execute sua função. Integridade: é a medida que o acesso ao sistema ou a dados por pessoas nãoautorizadas pode ser controlado. Usabilidade: é o esforça de aprender, operar, preparar a entrada e interpretar a saída de um programa. Manutenibilidade: é a capacidade de localizar e corrigir erros. Flexibilidade: é a capacidade de modificar o sistema. Testabilidade: é o esforço empregado para testar um sistema a fim de garantir a execução pretendida. Portabilidade: é o esforça para garantir que o sistema seja independente de hardware e/ou software. Reusabilidade: capacidade de reutilizar o sistema ou partes dele em outras aplicações. Interoperabilidade: é a capacidade de acoplar um sistema a outro. 4 PRESSMAN, Roger S. Engenharia de Software: Pearson Makron Books, Pág. 724.

9 A implementação de um programa para se obter qualidade no software, pode-se dar em várias maneiras, através de ferramentas destinadas para tal fim, seguindo metodologias distintas, estabelecimento de regras para elaboração de relatórios. Uma abordagem interessante, é a abordagem feita pelo PMBOK. Vejam a figura abaixo. Pela figura acima, notamos que é possível trabalhar no gerenciamento de qualidade de software com os três aspectos principais de qualidade: Garantia da qualidade, Controle da qualidade e os Padrões de qualidade. Durante este processo é definido politicas de qualidade, auditorias, gráficos de controle, planos de gerencia de qualidade, entre outras atividades, para realizar o gerenciamento da qualidade. Com isso os três principais processos do gerenciamento são realizados. Planejamento da Qualidade: Identificação dos padrões de qualidades relevantes para o projeto e determinação de como satisfazê-los. Garantia de Qualidade: Aplicação das atividades planejadas e sistemáticas para garantir que o projeto emprega todos os padrões relevantes de qualidade e identificação de maneiras de eliminar as causas de um desempenho insatisfatório.

10 Controle de Qualidade: Monitoramento de resultados específicos do projeto a fim de determinar se eles estão de acordo com os padrões relevantes de qualidade e identificação de maneiras de eliminar as causas de um desempenho indesejável. 2.5 Ilustre e comente com o seu sistema como a metodologia que vocês estão utilizando pode produzir um software de alta qualidade e que possa ser efetiva para os stakeholders. (Leandro) Para entender melhor como o RUP pode produzir um software de qualidade e que possa ser efetiva para os stakeholders, podemos ilustrar nossa metodologia com um Diagrama de Atividades. Vejamos:

11

12 Com este diagrama podemos observar as fases que o RUP define. Em cada fase da metodologia trás os artefatos que deverão ser feito. Na parte superior do diagrama, é representado o responsável pela atividade naquele momento. Os papeis são bem definidos. Todos sabem o que fazer e em qual momento. Com isso é possível mapear características de qualidade desejável em cada fase do projeto. É possível elaborar relatórios gerenciais para alcançar a qualidade desejada. Observando o diagrama acima, podemos identificar os padrões de qualidade relevantes para o projeto, fazer um planejamento com isso, e realizar um documento, ou ferramenta para realizar o controle da qualidade durante a evolução do processo. O controle de qualidade do processo pode ser feito em cada fase do projeto. Assim, é possível realizar no final de cada processo uma homologação que analisa os padrões de qualidade. Se aprovado e se a fase da metodologia atingiu um padrão mínimo de qualidade, então podemos passar para a próxima fase, se não, olhamos o que está errado, e tentamos consertar afim de chegarmos ao final do processo com a qualidade almejada. É interessante destacar também, que utilizando o diagrama acima, podemos elaborar uma ferramenta ou planilha para calcular os fatores e métricas de qualidade. 2.6 Elabore um documento, uma ferramenta baseada na sua metodologia, com planilhas, para ilustrar como pode ser realizada a Avaliação da Qualidade de um Software. Ilustre a aplicação com o seu sistema. Vocês não vão se esquecer dos atributos da qualidade, né? Esta prática facilita o entendimento pelos stakeholders. (Helton) Construímos uma planilha baseada na ISO/IEC 9126(NBR13596), que tem como objetivo servir de referencia básica na avaliação de produto de software. A planilha tem o seguinte funcionamento: Atribuímos o valor 0 quando a característica esta ausente ou ocorre em um número desprezível de vezes. Atribuímos o valor 1 quando a característica esta presente ou sua ocorrência é significativa.