AULAS 02 e 03: Noções sobre processo de desenvolvimento de software e Papéis e Responsabilidades em Projetos de Software SUMÁRIO PÁGINA Análise e Projeto de Software 1 Implementação, testes e implantação 13 Papéis e responsabilidades em projetos de software 19 Metodologias ágeis 24 Exercícios 32 Gabarito 40 Exercícios Comentados 41 Simulado 54 ANÁLISE E PROJETO DE SOFTWARE O levantamento de requisitos, a análise de requisitos e o projeto do software não são fases isoladas entre si. Ao elaborar diagramas e confeccionar documentos para buscar a melhor compreensão e entendimento dos requisitos de um sistema, já começa ali a fase de análise de requisitos. Tal imiscuidade entre fases também ocorrerá entre a análise e o projeto. O modelo de requisitos: entre a descrição do sistema e o projeto. Fonte: Pressman, 2011. 1 de 55
ANÁLISE A fase de análise de requisitos, no contexto do desenvolvimento de um sistema, é aquela na qual são construídos modelos para representar o sistema a ser construído. Esta fase tem como característica não levar com conta o ambiente tecnológico a ser utilizado. Nesta atividade, o foco de interesse é tentar construir uma estratégia de solução sem se preocupar com a maneira como essa estratégia será realizada. Em resumo, a prioridade é saber o que o sistema proposto deve fazer, para, posteriormente (no projeto), definir como o sistema irá fazê-lo. A modelagem de requisitos possui duas visões clássicas: a análise estruturada e a análise orientada a objetos. A análise estruturada considera os dados e os processos que transformam os dados em entidades separadas. Esta técnica descreve o fluxo de informação e transformações que são aplicadas à medida que os dados se movimentam da entrada para a saída. O diagrama que melhor ilustra a análise estruturada é o Diagrama de Fluxo de Dados (DFD), que será visto adiante. A análise orientada a objetos, por sua vez, lança mão da abstração para representar coisas do mundo real, sob a forma de objetos. Os objetos podem ser uma entidade externa, uma coisa, uma ocorrência, um evento, uma unidade organizacional, um local, enfim, qualquer elemento que possa ser representado por um conjunto de atributos. Por exemplo, uma pessoa pode ser definida por um nome, endereço, telefone, número de CPF. Um pedido, por sua vez, pode ser definido pelo seu número, comprador, produtos, quantidade e preço total. Objetos serão exemplificados no diagrama de classes, visto adiante. PRINCIPAIS DIAGRAMAS DA FASE DE ANÁLISE Modelos baseados em cenários São os casos de usos e histórias de usuários, já detalhados na Engenharia de Requisitos. 2 de 55
Modelos de Fluxo A modelagem orientada a fluxos considera os dados e os processos que os transformam entidades distintas. É a representação da análise estruturada, e seu principal diagrama é o Diagrama de Fluxo de Dados, ou DFD. Em um DFD, representam-se entidades externas por caixas, processos (ou tarefas) por circunferências (também podem ser elipses ou elipses achatadas), o fluxo dos dados por setas e depósitos de dados por traços duplos. Veja abaixo: Diagrama de Fluxo de Dados: meramente ilustrativo. Diagrama de Fluxos de Dados: meramente ilustrativo. 3 de 55
Modelos de Comportamento Os modelos comportamentais indicam como o software irá responder a estímulos ou eventos externos. Os diagramas de estado e de sequência representam este tipo de modelo. Diagrama de estados: um exemplo. Diagrama de sequência: um exemplo. 4 de 55
Modelos de classe A modelagem baseada em classes representa os objetos que o sistema irá manipular, as operações (também denominada métodos ou serviços) que serão aplicados aos objetos para efetuar a manipulação, alguns relacionamentos entre os objetos e as colaborações que ocorrem entre as classes definidas. Os elementos de um modelo baseado em classes são: classes e objetos, atributos, operações, modelos CRC (classe-responsabilidade-colaborador), diagramas de colaboração e pacotes. Diagrama de classes: exemplo Como dito anteriormente, não existe uma fronteira clara entre o término da fase de análise e o início da fase de projeto. Teoricamente, ao término da análise, os requisitos estão suficientemente detalhados para que modelagens mais refinadas possam ser empregadas. 5 de 55
PROJETO O foco principal da análise são os aspectos lógicos e independentes de implementação de um sistema, ou seja, os requisitos. Na fase de projeto, determina-se o como o sistema funcionará, para atender aos requisitos. Os modelos de requisitos, apresentados por elementos baseados em cenários, baseados em classes, orientado a fluxos e comportamentais, alimentam a tarefa de projeto. A atividade de projeto engloba o conjunto de princípios, conceitos e práticas que conduzem ao desenvolvimento de um sistema ou produto com alta qualidade. Lembro que, lato sensu, este também é o objetivo de todo o processo de desenvolvimento de software. Para buscar a qualidade do software, o projeto deve possuir algumas características: O projeto deve implementar todos os requisitos explícitos contidos no modelo de requisitos e deve acomodar todos os requisitos implícitos desejados pelos interessados; O projeto deve ser um guia legível, compreensível para aqueles que geram código e para aqueles que testam, e, subsequentemente, dão suporte ao software; O projeto deve dar uma visão completa do software, trabalhando os domínios de dados, funcional e comportamental sob a perspectiva de implementação. Ainda, cabe destacar alguns conceitos que devem ser ponderados quando da elaboração de um projeto: Abstração: À medida que o nível de abstração migra de um nível mais alto para um nível mais baixo, a solução deixa de ser expressa na linguagem do domínio do problema para ser expressa em uma terminologia técnica. Arquitetura: Uma meta do projeto de software é derivar um quadro da arquitetura de um sistema, que representará a organização a partir da qual atividades mais detalhadas do projeto são conduzidas. 6 de 55
Padrões: Os padrões de projeto são soluções comprovadamente eficazes que podem ser aproveitados em projetos de problemática recorrente. Por exemplo, um sistema de vendas online provavelmente possuirá um padrão de projeto consolidado. P.S.: não confundir o aproveitamento de um padrão de projeto com o aproveitamento de código (reuso de software). Separação por interesses (por afinidades): Esse conceito afirma que qualquer problema complexo pode ser tratado mais facilmente se decomposto em trechos a ser resolvidos e ou otimizados independentemente. Esse conceito aparece em outros conceitos, como modularidade, aspectos, independência funcional e refinamento. Modularidade: Dividir um software em poucos módulos o torna fácil de integrar, mas difícil de desenvolver e manutenir. Dividir demais o torna difícil de integrar, embora o custo do módulo seja baixo. O desafio do projeto é modularizar o problema da melhor forma possível, minimizando custos. Diagrama de classes ilustrando a modularidade. Modularizar na medida certa traz uma série de benefícios ao projeto e ao software. Encapsulamento de informações: O princípio do encapsulamento diz que os módulos devem ser capazes de ocultar suas características uns dos outros, disponibilizando apenas os itens que interessam aos outros módulos. Independência funcional: A independência funcional é atingida desenvolvendo-se módulos com função única e que pouco interagem com outros módulos. É medida qualitativamente pela coesão e pelo acoplamento. Um 7 de 55
módulo coeso realiza poucas tarefas, interagindo o mínimo necessário com outros módulos. Quanto ao acoplamento, é desejável que ele seja fraco, ou seja, que cada módulo se comunique o mínimo possível com os demais. Refinamento: O refinamento gradual é uma estratégia top-down. Um programa é desenvolvido refinando-se níveis procedurais sucessivamente. Refatoração: Técnica de reorganização que simplifica o projeto ou código, sem mudar sua função ou comportamento. Em projetos de refabricação de software, deve-se examinar o projeto antigo, eliminar redundâncias, corrigir algoritmos eficientes ou desnecessários. Refatoração: um exemplo. Um atributo que estava mal esclarecido, nome2, agora passa a se chamar mae, explicitando a sua funcionalidade. Usando a notação, princípios e métodos adequados, o projeto produz um projeto de dados/classes, um projeto de arquitetura, um projeto de interfaces e um projeto de componentes. 8 de 55
Projeto de dados/classes O projeto de dados/classes transforma os modelos de classes em realizações de classes de projeto e nas estruturas de dados dos requisitos necessários para implementar o software. Projeto de dados: um exemplo. 9 de 55
Projeto de arquitetura O projeto arquitetural define os relacionamentos entre os principais elementos estruturais do software, os estilos arquiteturais e os padrões de projeto que podem ser usados para satisfazer os requisitos definidos para o sistema e as restrições que o afetam. Diagramas de implantação podem mostrar os componentes físicos de um sistema, assim como diagramas de componentes pode mostrar os principais componentes de um software. Diagrama de Implantação, materializando a arquitetura de um sistema Diagrama de Componentes, materializando a arquitetura de um sistema 10 de 55
Projeto de componentes O projeto de componentes destrincha elementos estruturais da arquitetura, em uma descrição procedural dos componentes de software. Diagrama de classes, detalhando cada componente de um software Projeto de interface de usuário Conjunto de desenhos detalhados que representa fluxos de informação que entram em saem do sistema, como o sistema de comunica com sistemas externos e com as pessoas que o utilizam. Devem ser buscadas algumas características como: Familiaridade usar termos e conceitos obtidos da experiência de pessoas que farão uso do sistema. Consistência sempre que possível, operações similares devem ser ativadas da mesma maneira. 11 de 55
Surpresa mínima os usuários nunca devem ser surpreendidos pelo comportamento de um sistema. Deixar o usuário no comando o usuário deve ser capaz de interromper o que está fazendo para fazer outra coisa, sem perder o trabalho já feito. Reduzir a memória do usuário o sistema deve ser capaz de guiar o usuário, não precisando ele armazenar procedimentos na memória. Projeto de interface com o usuário: um exemplo. Em resumo, o projeto de interface com o usuário será a proposta de tela, ou telas, por meio das quais os usuários do sistema realização sua interação com o mesmo. Inevitavelmente o projeto de interface com o usuário será submetido à aprovação do cliente, podendo sofrer modificações antes da codificação. 12 de 55
IMPLEMENTAÇÃO, TESTES E IMPLANTAÇÃO IMPLEMENTAÇÃO Na 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. Código de programa: ilustração Ao codificar um software, um programador poderá escrever código novo, ou reaproveitar código já existente. Esse reaproveitamento de código é chamado de reuso de software. O reuso de software pode trazer vários benefícios, como ganho de tempo (o código já está escrito), confiança, redução de risco (o código já foi utilizado com sucesso anteriormente), dentre outros fatores. Por fim, é interessante destacar que a maioria das bibliografias prevê que o teste de unidade acontece na etapa da implementação. O teste de unidade é o teste pontual, realizado pelo programador, que verifica que aquele componente 13 de 55
ou módulo que ele desenvolveu realmente faz o que deveria fazer, atendendo às especificações do projeto. Uma vez que o sistema esteja codificado (e com seus módulos testados, a nível unidade), os códigos desenvolvidos pelos diversos programadores é integrado, e poderá ser submetido a uma bateria maior e mais complexa de testes. TESTES Teste de software é uma atividade realizada para descobrir erros que foram produzidos inadvertidamente no momento em que o software foi projetado e construído. Pode ser planejado antecipadamente e conduzido sistematicamente. Ainda, podem ser testes de baixo nível, no qual são verificados se pequenos segmentos de código-fonte foram corretamente implementados, bem como testes de alto nível, que validam as principais funções do sistema com base nos requisitos do cliente. Estratégias de teste de software As estratégias de teste de software fornecem um roteiro que descreve os passos a serem executados como parte do teste. Em um contexto macro, o teste de software é um elemento de um aspecto mais amplo, que é frequentemente referido como Verificação e Validação (V&V). Verificação se refere ao conjunto de atividades que garante que o software implementa corretamente uma função específica (estamos construindo o produto corretamente?), enquanto a Validação se certifica que o software construído corresponde aos requisitos do cliente (estamos construindo o produto certo?). O teste proporciona o último elemento a partir do qual a qualidade pode ser estimada, e, mais pragmaticamente, os erros podem ser descobertos. Conforme afirmado desde o início, a qualidade é incorporada ao software ao longo do processo de engenharia de software. Portanto, a motivação, por trás do teste, é a confirmação da qualidade. Se a qualidade não estiver lá antes do teste, não estará lá após a realização dele. 14 de 55
Quanto à responsabilidade pela execução dos testes, cabe aos próprios desenvolvedores a realização dos testes de unidade e, em muitos casos, também os testes de integração. Os mais complexos, por sua vez, serão realizados por um grupo independente de teste. Este grupo também faz parte da equipe de desenvolvimento do software. Quanto à estratégia em si, a espiral da figura abaixo ilustra o processo. Estratégia de teste de software. Fonte: Pressman, 2011. Teste de unidade se concentra em cada unidade: componente, classe ou módulo. Usa intensamente técnicas de teste com caminhos distintos, com o objetivo de descobrir erros dentro do módulo testado. Teste de integração técnica sistemática para construir a arquitetura do software ao mesmo tempo que conduz testes para descobrir erros associados com as interfaces (comunicação entre os módulos, não confundir com interface com o usuário). A integração pode ocorrer de forma descendente (top-down) ou ascendente (bottom-up). Integração de módulos. No exemplo, M4 e M7 serão incorporados à arquitetura, e o sistema deverá ser testado com a presença desses dois novos módulos. 15 de 55
Teste de validação a validação de software é conseguida por meio de uma série de testes que demonstram conformidade com os requisitos. Um plano de testes poderá definir casos de teste específicos que atestem que os requisitos funcionais sejam satisfeitos, que os requisitos de desempenho sejam atendidos, que a documentação esteja correta, dentre outros. Desvios ou erros descobertos nesse estágio raramente podem ser corrigidos antes do prazo de entrega programado. Se um software é desenvolvido como um produto para ser usado por muitos clientes, é impraticável que todos eles realizem testes formais de aceitação. Muitos construtores de software, então, usam um processo chamado de teste alfa e beta para descobrir erros que apenas o usuário final é capaz de encontrar. O teste alfa é conduzido na instalação do desenvolvedor por um grupo representativo de usuários finais. Nele, o desenvolvedor monitora os usuários, registrando os erros e os problemas de uso. O teste beta é conduzido nas instalações dos usuários finais. Via de regra, o desenvolvedor não está presente, e os erros e problemas encontrados são reportados pelos usuários. Teste de sistema o teste de sistema extrapola os limites da engenharia de software. Uma vez validado, o software deverá ser combinado com outros elementos do sistemas (como hardware, pessoas, base de dados). Ele verifica se todos os elementos se combinam corretamente e se a função/desempenho global do sistema é conseguida. Podem ser: Teste de recuperação: força o sistema a falhar de várias formas e verifica se a recuperação é executada corretamente; Teste de segurança: verifica se os mecanismos de proteção incorporados ao sistema protegem contra acesso indevido; Teste de esforço: coloca o programa em condições anormais. Até onde podemos forçar o sistema até que ele falhe? Teste de desempenho: testar o desempenho, em tempo de execução, do software em um contexto de sistema integrado. Pode ser feito em conjunto com testes de esforço; Teste de disponibilização: exercitar o software em cada ambiente no qual ele deve operar, como em vários sistemas operacionais, vários navegadores web, ou várias plataformas (PC, smartphone...). Depuração Quando um erro é encontrado, o código deverá ser futucado para encontrar o pedaço de código que está escrito de maneira incorreta, para então ser corrigido. A esta etapa é dada o nome de depuração. Depurar o código não é testar o código, mas são processos que se relacionam. 16 de 55
Técnicas de teste de software Realizar testes em software é um paradoxo de raciocínio. Os desenvolvedores devem deixar de construir o software e passar a trabalhar em casos de teste para quebrá-lo. O objetivo do teste é encontrar erros, e um bom este é aquele que tem alta probabilidade de encontrar um erro. Os testes devem ter uma série de características que permitam atingir o objetivo de encontrar o maior número de erros com um mínimo de esforço. São atributos desejáveis em um teste: Alta probabilidade de encontrar erros; Não ser redundante; O melhor de uma categoria (o mais completo de um grupo similar de testes);e Nem muito simples, nem muito complexo. Vejamos algumas técnicas de teste: Caixa-Branca - Também chamada de teste estrutural ou orientado à lógica, a técnica de caixa-branca avalia o comportamento interno do componente de software. Essa técnica trabalha diretamente sobre o código fonte do componente de software para avaliar aspectos tais como: teste de condição, teste de fluxo de dados, teste de caminho básico, teste de ciclos, teste de caminhos lógicos, códigos nunca executados, teste de estrutura de controle. Os aspectos avaliados nesta técnica de teste dependerão da complexidade e da tecnologia que determinarem a construção do componente de software, cabendo portanto avaliação de mais aspectos que os citados anteriormente. O testador tem acesso ao código fonte da aplicação e pode construir códigos para efetuar a ligação de bibliotecas e componentes. Este tipo de teste é desenvolvido analisando o código fonte e elaborando casos de teste que cubram todas as possibilidades do componente de software. Dessa maneira, todas as variações relevantes originadas por estruturas de condições são testadas. A técnica de teste de caixa-branca é recomendada para as fases de teste de unidade e teste de integração, cuja responsabilidade principal fica a cargo dos desenvolvedores do software, que por sua vez conhecem bem o código fonte produzido. Caixa-Preta - Também chamada de teste funcional, teste comportamental, orientado a dado ou orientado a entrada e saída, a técnica de caixa-preta avalia o comportamento externo do componente de software, sem se considerar o comportamento interno do mesmo. Dados de entrada são fornecidos, o teste é executado e o resultado obtido é comparado a um resultado 17 de 55
esperado previamente conhecido. Como detalhes de implementação não são considerados, os casos de teste são todos derivados da especificação. Quanto mais entradas são fornecidas, mais rico será o teste. Numa situação ideal todas as entradas possíveis seriam testadas, mas na ampla maioria dos casos isso é impossível. Outro problema é que a especificação pode estar ambígua em relação ao sistema produzido, e como resultado as entradas especificadas podem não ser as mesmas aceitas para o teste. Uma abordagem mais realista para o teste de caixa-preta é escolher um subconjunto de entradas que maximize a riqueza do teste. Pode-se agrupar subconjuntos de entradas possíveis que são processadas similarmente, de forma que testar somente um elemento desse subconjunto serve para averiguar a qualidade de todo o subconjunto. Por exemplo, em um sistema que aceita um inteiro como entrada, testar todos os casos possíveis pode gerar pelo menos dezenas de milhares de casos de testes distintos. Entretanto, a partir da especificação do sistema, podese encontrar um subconjunto de inteiros que maximizem a qualidade do teste. Depende do propósito do sistema, mas casos possíveis incluem inteiros pares, inteiros ímpares, zero, inteiros positivos, inteiros negativos, o maior inteiro, o menor inteiro. A aplicação de técnicas de teste leva o testador a produzir um conjunto de casos de teste (ou situações de teste). A aplicação combinada de outra técnica técnica de particionamento de equivalência (ou uso de classes de equivalência) permite avaliar se a quantidade de casos de teste produzida é coerente. A partir das classes de equivalência identificadas, o testador construirá casos de teste que atuem nos limites superiores e inferiores destas classes, de forma que um número mínimo de casos de teste permita a maior cobertura de teste possível. Uma outra variação é a Análise do Valor Limite na qual são testados valores nas fronteiras de um domínio. Por exemplo: se determinado campo só permite o preenchimento com números de 1 a 100, aplicam-se nos testes os valores 0,1,100 e 101. As técnicas caixa-preta podem ser aplicadas em todos as etapas de teste, embora mais apropriadas a partir dos testes de integração até a implantação. IMPLANTAÇÃO Na implantação, o sistema é empacotado, distribuído e instalado no ambiente do usuário. Os manuais do sistema são escritos, os arquivos são carregados, os dados são importados para o sistema, e os usuários são treinados para utilizar o sistema corretamente. Dependendo da situação, pode ocorrer também a migração de sistemas de do software e de dados preexistentes. 18 de 55
PAPÉIS E RESPONSABILIDADES EM PROJETOS DE SOFTWARE Como você deve ter observado, o estudo do processo de desenvolvimento de software é orientado a processos, ou seja, preocupa-se com o avançar do processo em si. Para avaliar os papéis e responsabilidades em projetos de software é necessário realizar um estudo transversal, extraindo as participações dos diversos personagens ao longo do projeto de software. Vejamos: Patrocinador O patrocinador do projeto, via de regra, é alguém do alto escalão de uma organização, que compra a idéia do software. Em virtude de sua posição, é capaz de atribuir recursos e dinheiro ao projeto. Entretanto, além de financiar o projeto, os patrocinadores têm outras funções muito importantes para o sucesso dos projetos. Durante o ciclo de vida do projeto, o patrocinador atua como um decisor acima do gerente de projeto, podendo tomar decisões fora da alçada do gerente do projeto. Além disso, o patrocinador funciona como um ponto focal para a alta administração e também para outros stakeholders, eventualmente. À primeira vista, pode parecer que o patrocinador do projeto duplica os esforços do gerente de projeto. No entanto, um patrocinador do projeto experiente pode melhorar a comunicação e coordenação em questões além das responsabilidades do gerente de projeto. O papel do patrocinador está diretamente ligado à gerência sênior e inclui, mas não se limita a: Participar na seleção de projetos, categorização e priorização; Participar no estabelecimento de prioridades e alocação de recursos; Estabelecer objetivos estratégicos para o projeto; Alinhar os objetivos do projeto aos objetivos de negócio; Realizar acompanhamento e relatórios sobre o andamento do projeto para a alta administração; Auxilia a fixação da autoridade do gerente de projeto; Participa do comitê de controle de mudanças. 19 de 55
Em geral, patrocinadores devem ter sólidos conhecimentos de negócio e boa capacidade de comunicação. Ele irá atuar mais como um líder visionário para o projeto, enquanto o gerente de projeto irá desempenhar funções de gestão e técnica a maioria dos o tempo. Especialmente em projetos complexos de grande porte, os gerentes de projetos precisam de muita ajuda de executivos de nível sênior. Sem patrocínio, a chance de fracasso é muito grande. Sendo o patrocinador um gerente sênior, ele possui autoridade e poder para tomar decisões que trazem grande agilidade e flexibilidade aos projetos, permitindo responder a riscos mais rapidamente e controlar mudanças. Desta forma, o patrocinador assegura, de uma maneira indireta, que a alta administração apoia o projeto. Um bom patrocinador é a ligação entre o gerente de projeto e gerentes seniores e executa diferentes funções durante o ciclo de vida do projeto, promover e proteger o projeto. Durante o início de um projeto, o patrocinador deve ser responsável pelo Termo de Abertura do Projeto e seu Business Case, alinhando os objetivos do projeto à estratégia corporativa. O patrocinador irá designar um gerente para o projeto, que pode ajudar neste planejamento inicial. O planejamento do projeto será responsabilidade do gerente de projeto designado e sua equipe, mas o patrocinador deve tomar conhecimento e aprovar planos de projeto. Ao longo da execução, o patrocinador irá monitorar o progresso e status do projeto, informando à gerência sênior. O patrocinador deve ter reuniões regulares com o gerente do projeto para reforçar a confiança e obter informações atualizadas. Finalmente, é o patrocinador o responsável pelo projeto perante a organização e à alta administração. Ele deve assegurar que os benefícios do projeto estão sendo entregues. Gerente de Projetos O gerente de projetos é o responsável pela gerência ou coordenação das atividades necessárias à construção do sistema. Deve fazer o orçamento do projeto de desenvolvimento, estimar o tempo necessário para o desenvolvimento do sistema, definir qual o processo de desenvolvimento, o cronograma de execução das atividades, a equipe de desenvolvimento, os recursos de hardware e software, etc. 20 de 55
O monitoramento e controle das atividades realizadas também é de responsabilidade do gerente do projeto, bem como a realização dos ajustes necessários para a adequação dos recursos e gastos. O gerente deverá ser meticuloso em seus estudos, quando realizar o estudo de viabilidade, escolher a equipe de desenvolvimento e o processo de desenvolvimento de software. O gerente de projeto, por sua vez, presta contas ao patrocinador do projeto. Segundo Pressman, o gerente de projeto, ao gerenciar efetivamente o projeto de software, deve focar em 4Ps, e nessa sequência: Pessoas, Produto, Processo e Projeto. Pessoas O gerente de projeto deve ater-se a algumas práticas-chaves, como: formar a equipe, liderar sua equipe, estabelecer boa comunicação com a equipe e com os interessados no projeto. Produto O gerente de projeto também deve analisar detalhadamente os requisitos (junto com os analistas de requisitos), para estabelecer e delimitar o escopo, de modo a poder estimar recursos e prazo. Processo A equipe de software deve ser flexível ao escolher o processo de software mais adequado ao projeto e às tarefas de engenharia de software que fazem parte do modelo selecionado. Projeto É a abordagem de cuidar do projeto como um projeto em si, entendendo fatores críticos de sucesso, planejando, monitorando e controlando o projeto, por meio de métricas e ferramentas. 21 de 55
Área de Negócio A área de negócio é o conjunto de stakeholders que será o principal beneficiado pelo projeto de software. Cabe a ela colaborar com a elicitação de requisitos, participar dos testes finais do software, e fornecer o feedback após a sua implantação. Pode-se destacar um personagem nesse contexto, o Especialista de Domínio. O especialista do domínio interage com o analista de requisitos para levantar os requisitos do sistema. Analista de Requisitos O analista de requisitos é o profissional que precisa ter conhecimento do domínio do negócio. Ele precisa compreender tal domínio para definir os requisitos do sistema a ser desenvolvido. Analistas devem estar aptos a se comunicar com especialistas do domínio para obter conhecimento acerca dos problemas e das necessidades envolvidas na empresa que necessita do sistema. Se, por um lado, ele não precisa ser um especialista, por outro, deve ter suficiente domínio do vocabulário da área de conhecimento na qual o sistema será implantado. Preferencialmente, este nível de domínio deve ser suficiente para que o especialista de domínio não precise, a todo momento, explicar conceitos básicos da área. O analista de requisitos precisará captar as necessidades dos clientes e repassar esse entendimento aos demais desenvolvedores do sistema, fazendo uma ponte entre os profissionais da computação e os profissionais do negócio. Em suma, os analistas de requisitos realizam o levantamento e a análise de requisitos. Inclusive, enxerga-se como uma progressão natural na carreira dos analistas de requisitos a gerência de projetos, uma vez que os analistas de requisitos adquirem experiência com a participação em diversos projetos. Equipe de desenvolvimento A equipe de desenvolvimento é fortemente atuante nas fases de projeto e implementação da solução de software. Destaque para: Projetistas: avaliam as alternativas de solução do problema resultante da análise e geram a especificação de uma solução computacional detalhada. Podem ser especializados em interface, redes, bancos de dados, etc; 22 de 55
Arquitetos de software: especialista em elaborar a arquitetura do sistema como um todo; Programadores: codificação do sistema e testes; Equipe de sustentação A sustentação consiste no suporte e atendimento ao cliente, responsável por manter o produto. Logo, a equipe de sustentação é aquela responsável pela manutenção do sistema após a sua entrega. Via de regra, equipes de desenvolvimento de software são montadas sob medida, em virtude do talento de seus integrantes, e desfeitas após o término do projeto. Inclusive, pode ocorrer, por questões contratuais, que uma empresa diferente da que desenvolveu o sistema seja responsável por sua manutenção. A equipe de sustentação pode realizar suporte técnico e prestar consultoria aos cliente, se for o caso. A manutenção prestada por essa equipe pode ser corretiva, aquela que corrige defeitos no sistema, adaptativa, adaptando alguns aspectos do sistema, como hardware, plataforma de sistema operacional, etc, desde que não sejam muito complexas, ou evolutiva, que adiciona novas funcionalidades ao software. Destaco, ainda, que esse acréscimo de funcionalidade é pontual. Evolução significativa de software é tratada à parte, como um outro projeto de software. Dentre os integrantes da equipe de sustentação, destaca-se o analista de suporte, profissional capaz de interpretar a solicitação do cliente e analisar se o problema relatado é um defeito a ser corrigido no sistema ou não. 23 de 55