APOSTILA - PROCESSOS DE SOFTWARE E DESCRIÇÃO DA EQUIPE DE DESENVOLVIMENTO

EQUIPE DE DESENVOLVIMENTO

Gerente de Projetos

Um bom gerente de desenvolvimento precisa, antes de tudo, entender do processo de desenvolvimento de software. Por mais que isso possa parecer óbvio, é impressionante o número de profissionais de nível gerencial da área de desenvolvimento de software que não possuem capacitação técnica (BRASIL, 2002).
Definindo melhor esta necessidade de conhecimento, poderíamos dizer que um bom gerente de software deveria ter entendimento e as seguintes habilidades:
• Ter uma experiência profissional equivalente ao cargo ocupado;
• Ter participado de algum projeto ou ter conhecimento em desenvolvimento de sistemas, ou seja, conhecer o papel de programador;
• Já ter participado de algum projeto de desenvolvimento de sistemas ou conhecimento do papel de analista de sistemas;
• Conhecer regras de negócio na área na qual esta sendo desenvolvido o software;
• Conhecer algumas ferramentas de desenvolvimento;
• Conhecimento de modelagem física (de bases de dados) e otimização de consultas;
• Capacidade de delegar tarefas e cobras os prazos para solução de um problema;
• Gostar de estudar, reciclando constantemente;
• Ler livros e revistas especializadas além de participar de congressos da área de tecnologia, gestão e Empreendedorismo;
• Participar de listas de discussão, especializadas em temas gerencais/técnicos, podendo assim resolver possíveis problemas com a experiência de outras pessoas.
• Dar maior atenção na aprendizagem dos seus próprios erros;
• Participar de cursos de atualização, pois esta é a forma mais rápida de um profissional conseguir estar atualizado, considerando que estes cursos geralmente são caros, há necessidade de uma escolha cuidadosa.
• Deve se flexível sem deixar de ser consistente;
• Saber lidar com a tensão sem abandonar o plano a ser seguido;
• Conseguir o comprometimento da equipe e poder utilizar para um maior dinamismo da mesma.

O Gerente é o responsável pelo primeiro contato com o Cliente onde serão dadas as primeiras idéias a respeito do que será desenvolvido (QUADROS 2002). Alem de ser responsável pelo artefato Plano de Desenvolvimento de Software (PDSw), o gerente é também responsável pelo cumprimento das fases de desenvolvimento para não ocorrer problemas com datas de entregas, sendo que para isso está em constante contato com a equipe para sua integração, ou seja, um elo que ligaria todos os membros, solicita medições periódicas e monitora os riscos intrínsecos ao projeto.
Durante um projeto o Gerente executaria as seguintes etapas.
• Visita ao Cliente, que deverá estar acompanhado de outra pessoa da empresa que esteja ciente do projeto, para uma análise inicial de levantamento dos requisitos sendo que não teriam as informações completas, pois até mesmo o cliente neste primeiro contato não saber realmente o que deseja. O fruto desta visita é a elaboração da Proposta de Especificação de Software (PESw) com todas as informações obtidas durante a reunião, sendo realizado uma estimado inicial de prazos e custos do produto/ serviço a ser desenvolvido e o planejamento para a próxima fase, caso o cliente aceite a PESw.
• Na fase de Elaboração é marcada uma visita, agora para mostrar uma análise mais completa unindo o que o Analista conseguiu absorver na primeira reunião mais algumas implementações pessoais para que o Cliente possa questionar e assim ter uma idéia mais pragmática a respeito do projeto.
• Na terceira reunião, o Gerente realizaria uma Reunião Fast (Facilitated Application Specification Techniques) (Pressman, 2001), com a participação de alguns membros da equipe de desenvolvimento e dos representantes da empresa que realmente irão utilizar o software, para que possa obter uma coesão ainda maior e verificar as necessidades de cada um que irá manusear o sistema. Esta atividade é geralmente sugeria quando o produto será manuseado por um grupo acima de 10 pessoas, sendo convidado representantes das áreas que utilizarão a solução para participarem da reunião.
• Sendo confeccionado o artefato Especificação de Requisitos de Software (ERSw) com todas as informações obtidas durante as três reuniões.

Após este levantamento o Gerente fica encarregado de elaborar uma segunda reunião, agora com sua equipe para mostrar resultados dos levantamentos de requisitos.
Depois deste último contato o Gerente faria um programa de treinamento e aquisição de materiais, se necessário, para que assim possa cobrar a execução de procedimentos descritos no processo de desenvolvimento de software e assim posicionar o cliente com relação ao seu produto. É de responsabilidade do gerente a montagem do PDSw (Plano de desenvolvimento de software) onde é descrito o custo, as pessoas e suas responsabilidades.

Analista de Sistema

O Analista é o ponto principal de toda a equipe de desenvolvimento. E a função desse profissional pode variar de empresa para empresa, principalmente no que tange ao Analista de Sistemas efetivamente participar da codificação (programação) ou apenas da modelagem.
O Analista de Sistemas, em geral, está envolvido com as seguintes atividades:
• Levantamento de requisitos junto aos usuários, função que, em algumas empresas é executado por um profissional específico, o Analista de Negócio;
• Modelagem em alto nível do sistema, com uso de linguagens como a UML
• Implementação do modelo (programação);
• Manutenção do código-fonte, corrigindo erros ou implementando melhorias
• O perfil deve ser predominantemente técnico, com boa capacidade de trabalho em equipe, um bom nível de raciocínio lógico e a facilidade de lidar com situações de pressão, muitas vezes encontradas nos ambientes de desenvolvimento.
• Facilidade de lidar com o público e uma boa habilidade de redação uma vez que, em boa parte do tempo, ele estará desenvolvendo um trabalho de documentação e organização dos dados coletados em entrevistas.
• Capacidade para compreender conceitos abstratos, reorganizar esses conceitos em divisões lógicas e sintetizar "soluções" baseado em cada divisão.
• Capacidade de absorver fatos pertinentes a partir de fontes conflitantes ou confusas.
• Capacidade de se comunicar bem de forma escrita e verbal.
• Capacidade de "ver a floresta ao invés das árvores”.

O Analista tem como responsabilidade à elaboração do projeto do sistema, precisando conhecer no mínimo uma linguagem de programação que servirá para elaboração de protótipos ilustrativos, uma linguagem de modelagem UML, ferramentas de modelagem de processos, técnicas de analises de sistemas e técnicas de projetos de sistemas.
Trabalhará com ajuda dos Administradores de Banco de Dados, reduzindo assim alguns erros que podem ser cometidos pelo analista na fase de análise, por isso a presença do Administrador de banco de dados no Levantamento dos Requisitos. O analista é responsável em elaborar os artefatos de Especificação de Requisitos de Software (ERSw), Modelo de Análise de Software (MASw) e Descrição do Projeto de Software DPSw.
Estes documentos contem os diagramas previstos na UML que representem a facilidade de entendimento e absorção de idéias não só pelo desenvolvedor, mas também principalmente pelo cliente.
O Analista pode, se necessário, usar até duas ferramentas UML: 1) uma bastante leve e de fácil instalação para que seja demonstrado no próprio cliente como será o andamento do projeto; 2) outra para utilização interna que possibilite uma maior integração com outras ferramentas de desenvolvimento para assim reduzir custos com relação a tempo e esforço de programação, compatibilidade de arquivos.

Programador

O programador é o profissional responsável pela codificação dos sistemas. Seu trabalho esta intimamente ligado a utilização das ferramentas de desenvolvimento (geralmente linguagens de Programação) para implementar os modelos que foram definidos pelos Analistas de Sistemas.
Os programadores em geral, estão envolvidos com as seguintes atividades.

• Desenvolvimento de programas a partir de uma modelagem definida pelos Analistas de Sistemas;
• Manutenção do código-fonte, corrigindo erros ou implementando melhorias;

Em virtude de seu trabalho envolver apenas a codificação de sistemas, sem a necessidade de qualquer tipo de modelagem (diferentemente dos Analistas de Sistemas), os Programadores podem ser recrutados dentre profissionais recém formados ou em formação (PROGRAMADOR 2004).
O programador é um profissional com perfil predominantemente técnico, com facilidade de lidar com detalhes e persistente. Apresentando também características como criatividade e um bom raciocínio lógico também estão presentes em seu perfil.
Regra geral, o Programador de Sistemas começa por listar ou ler as especificações de programas, organizadas pelo analista de sistemas, onde se especificam todos os passos a seguir. No prosseguimento das suas funções, cabe-lhe analisar todos os problemas detectados, procurando solucioná-los da melhor forma, o que pode implicar a otimização do desempenho dos equipamentos e das respectivas aplicações. Elabora esquemas que mostrem a seqüência de procedimentos adotados pelo computador, o que implica a codificação de mensagens do respectivo equipamento.
É também responsável pela construção do programa utilizando maneira intensiva os artefatos ERSw, DDSw e o MDSw. Com isso fornece os artefatos Manual do Usuário (MUSw) e Relatório de Acompanhamento do Plano de Software (RAPSw) (PAULA FILHO, 2003).
O programado também entrega as versões dos executáveis primeiro para teste e procura de possíveis erros que possam ainda estar, e esse primeiro teste será chamado de teste Alfa.
O MUSw será o guia que servirá para navegação no sistema pelos clientes usuários que estará mostrando as funcionalidades e as formas de se obter o máximo de desempenho do software.
E por último o RAPSw, que será o relatório que servira para compor a documentação e para interação dos Programadores com o Gerente para que o mesmo tenha noção do que esta sendo feito e em que parte do projeto esta para poder cobrar fases do projeto.

DBA = Desenvolvedor de Banco de Dados

Em geral, o DBA deve ser um profissional com perfil extremamente técnico. A facilidade em lidar com situações de pressões é muito importante, uma vez que ele trabalhará com uma parte vital do sistema de informação, com requerimentos de operação muitas vezes, ininterrupta.
A organização pessoal também é muito importante, pois o trabalho de DBA envolve também uma capacidade de planejamento (trabalho preventivo) bastante elaborado.
Deve fornecer subsídios técnicos para escolha do servidor de banco de dados tanto no ambiente de desenvolvimento quanto de produção. Essa escolha se desdobra também na especificação das plataformas de hardware e software que abrigaram o servidor de banco de dados.
Planejar políticas de backup em banco de dados, garantindo a recuperação em caso de falhas (lógicas ou físicas) no servidor.
Operacionalizar planos de contingência no caso de falhas, sendo capaz de prever com antecedência o tempo necessário de recuperação nesses casos.
Acompanhar o crescimento do banco de dados de forma atuar preventivamente e corretivamente para corrigir o esgotamento de recursos físico, notadamente o espaço em disco, além de sugerir medidas que impeçam a queda da performance das aplicações com o aumento do volume de dados.
Além de possuir as características de autocontrole, capacidade de análise, capacidade de comunicação, capacidade de decisão, capacidade de liderança, capacidade de organização, capacidade de resolver problemas práticos; dinamismo; facilidade para matemática; habilidade para trabalhar em equipe; interesse por computadores; interesse por novas técnicas e tecnologia.
O administrador do banco de dados é a autoridade máxima para gerenciar um sistema de banco de dados. Ele possui uma conta privilegiada no SGBD, a qual permite que o administrador tenha direitos que não estão disponíveis para usuários comuns. No PLDS é também responsável pelo desenvolvimento do Banco de dados, sua especificação e implementação no ambiente do cliente.
Participa juntamente com o analista e o Gerente da elaboração do ERSw e o MASw.

Testador

Responsável em realizar os testes oficiais procurando os erros que podem existir no software, registrando como aconteceram os defeitos de tal forma que possibilite a repetição dos mesmos por parte dos programadores, sendo também o responsável pela validação e liberação do software. Utiliza intensivamente os artefatos ERSw, elaborando os artefatos relatório de testes de software (RTSw), relatório de testes de software dos testes alfa (RTSwAtv), relatório de testes de software dos testes beta (RTswBet) e colaborando no relatório de acompanhamento da qualidade do software qualidade (RAQSw).

Cliente

O cliente é o indivíduo, ou grupo de indivíduos, para o qual o sistema é construído, pode-se distinguir dois tipos de clientes: o cliente usuário e o cliente contratante. No PIDS possui papel fundamental na construção dos artefatos PESw e ERSw, sendo consultado periodicamente para reavaliar os módulos desenvolvidos. Algumas vezes são desenvolvidos produtos para atender a uma demanda do mercado, neste caso, são necessários que sejam realizadas pesquisas de mercado, sendo assim, a equipe de marketing funciona como o cliente para a equipe de desenvolvimento. Participa inicialmente da formação do primeiro documento do processo, PESw - Proposta de Especificação de Software, que é utilizado para iniciar as atividades de desenvolvimento de uma solução baseada em computado. É entrevistado pelo analista de sistemas e o gerente de projetos para elaboração do artefato PESw, caso haja necessidade, posteriormente são utilizados outras técnicas de levantamento de requisitos, como por exemplo REUNIÂO FAST (Facilitated application specification techniques), para montagem do segundo documento ERSw que conterá cerca de 90% das atividades a serem desenvolvidas no produto/serviço. Deve ter participar ativamente na elaboração do documento ERSw, formalizando seu aceite na conclusão do artefato, indicando que está de acordo com a solução apresentada pela equipe de desenvolvimento.

FIGURA DE PROCESSO PDSw

FIGURA DO FLUXO DO PRODUTO

1. Formulário

Este artefato é desenvolvido pelo gerente e analista para analisar o FACS que foi enviado, o mesmo deverá marcar uma reunião inicial que deve seguir como base a sequência de perguntas.

2. Ativação

Define os passos iniciais para o desenvolvimento do produto, sendo estimado o custo e o prazo baseado na metodologia NESMA (Netherlands Software Metrics Users Association). A associação de Métricas da Holanda foi fundada em maio de 1989, inicialmente com o nome NEFPUG - Netherlands Function Point Software Users Grup. Esta atividade permite avaliar, junto com o cliente, a viabilidade de prossegui ou não com os trabalhos de realização do Serviço/Produto, as estimativas possuem uma margem de erro de aproximadamente 40% e precisam ser refinadas, após uma análise mais detalhada do problema em questão.

3. PESw = Proposta de Especificação de Software

Proposta de Especificação de Requisitos de Software corresponde ao documento que ativa todo o processo de desenvolvimento do produto. O cliente deve realizar um pedido formal, solicitando que seja feito um orçamento para desenvolver uma solução baseada em computador. Esta solicitação inicialmente deve ser encaminhada ao Gerente Técnico do Lacen- GTL, conforme PC CLC 020. Caso o GTL necessite de uma orientação da área técnica, encaminha a solicitação ao líder do processo correspondente, que retornará seu parecer através do documento PESw. Este documento é gerado em comum acordo com o cliente, sendo regido por uma Solicitação de Serviço que tem suas despesas arcadas pelo Lacen, caso seja confirmado o início do Serviço/Produto deve ser formalizado um contrato prevendo a próxima etapa do processo, Fase de Elaboração, seguindo planejamento descrito no documento PESw, onde neste caso, a origem dos recursos passam a seguir a definição do contrato.

4. Levantamento de requisitos

Nesta fase, os membros da equipe técnica de desenvolvimento de software trabalham com o cliente e os usuários finais do sistema para descobrir mais informações sobre o domínio da aplicação, por exemplo: que serviços o sistema tem que fornecer? Qual o desempenho exigido pelo sistema? As restrições de hardware e assim por diante.
O levantamento de requisitos pode envolver diversas pessoas de diferentes áreas da empresa contratante.
O analista e o gerente, com a participação do administrador de banco de dados, estarão envolvidos nas atividades de levantamento de requisitos, que constitui na realização de atividades de reunião e entrevista com o cliente. Nesta fase são empregadas técnicas de elucidação de requisitos, com o intuito de aumentar o comprometimento do cliente e desenvolvedores com a solução que se deseja construir. É muito importante que os requisitos sejam extraídos da maneira correta e objetiva. Caso o sistema seja utilizado por uma grande quantidade de pessoas, é recomendado que as entrevistas sejam feitas com presença de um conjunto de representantes do cliente (dependendo da complexidade do sistema) divididos por áreas de atuação e outros especialistas das áreas de interesse.
Com as revisões dos requisitos feitas na fase de Concepção, uma nova revisão será feita envolvendo pessoas que irão interagir com o sistema, cliente, além de outras pessoas de fora do projeto.
A equipe de revisão deve verificar cada requisito, em termos de existir consistência, e checar os mesmos como um todo.
O Levantamento dos Requisitos funcionais (TELES, 2004) são descritos em casos de uso, identificando as principais funções do sistema e suas interações, ou seja, quem irá interagir com o mesmo, para facilitar a visão do cliente e do analista de sistemas. A ferramenta de modelagem será de grande importância neste momento.

5. ERSw = Especificação de Requisitos de Software

O documento de ERSw é a declaração oficial do que é solicitado pelo cliente. Ele deverá conter diversos fatores como, funcionalidade, escopo do produto, perspectiva do produto interfaces externas, descrição das interfaces, restrições gerais, descrição dos casos de uso em alto nível que ajudarão a equipe a entender o que o cliente deseja que seja desenvolvido. Uma especificação detalhada dos requisitos de sistema é feita.
É um documento completo que envolve todos os usuários que utilizarão o sistema e assim como a PESw, deve ser formalmente aceito pelo cliente e desenvolvedores.

6. ARSw = Analise de Requisitos de Software

Modelagem conceitual dos elementos relevantes do domínio do problema e uso desse modelo para validação dos requisitos e planejamento detalhado da fase de Construção. Tem como pre-requisito o artefatos ERSw - Especificação de Requisitos de Software, elaborado na iteração Levantamento de Requisitos. Busca responder O QUE FAZER com a visão do analista.

6.1 PDSw = Plano de Desenvolvimento de Software

Documento que descreve, de forma detalhada, os compromissos que o fornecedor assume em relação ao projeto, quanto a recursos, custos, prazos, riscos e outros aspectos gerenciais.
O documento deve conter a visão geral do projeto e do documento, onde as informações básicas e informações necessárias para a negociação do projeto com o cliente, serão descritas.
O cronograma das atividades de entrega, como foi disponibilizado pelo cliente devem conter as datas para entrega dos códigos-fonte, o Manual do usuário de Software - MUSw, assim como uma proposta de treinamentos.
É importante descrever todas as siglas que farão parte do projeto sendo listadas e definidas juntamente com os termos, pois serão de grande entendimento para o cliente e funcionários.
O modelo do processo deve ser descrito com seus objetivos e fases do processo de desenvolvimento de software. A Estrutura Organizacional é importante para mostrar de que forma está organizada a equipe do projeto assim como as responsabilidades de cada membro da equipe e quais são suas principais funções e atividades.
Na parte do Processo Gerencial serão descritas informações relativas às atividades e objetivos com maior prioridade de interesse do cliente, no entanto deve-se priorizar as atividades de maior risco, sendo adotado o procedimento a seguir (BEZERRA, 2002)

• Maior risco maior interesse do cliente.
• Maior risco menor interesse do cliente.
• Menor risco menor interesse do cliente.
• Menor risco menor interesse do cliente.

Na Gestão de Riscos serão listados os prováveis riscos que ocorrerão e também suas medidas preventivas.
Em Mecanismos de Monitoração e Controle serão descritos todos os procedimentos e acontecimentos feitos em cada fase para garantir o cumprimento das atividades assim como revisão de auditoria, e outras técnicas e ferramentas a serem usadas para monitorar e controlar a aderência ao PDSw. É importante, pois garante a qualidade do produto que se deseja alcançar.
Na parte do Processo Técnico, serão descritos todos os procedimentos técnicos que serão feitos. Como no item Métodos, ferramentas e técnicas, onde serão descritos os ambientes operacionais que serão utilizados, as metodologias que serão utilizadas, as linguagens de programação que serão utilizadas, as ferramentas que serão utilizadas em cada momento do ciclo de desenvolvimento. Listar também os documentos que serão produzidos no projeto com suas respectivas siglas.
Em Programação e Orçamento as principais informações que devem constar neste item estão relacionadas ao orçamento onde será detalhado o gasto de recursos no decorrer do projeto e agenda, onde deve constar através das atividades, as pessoas envolvidas (quantos componentes), início e fim e duração todas estas atividades são realizadas utilizando uma planilha de cálculos de PF disponibilizadas o site. Finalmente em Componentes Adicionais, as informações que constatarão serão sobre treinamento, conversão de dados, transição do sistema e manutenção do produto.

6.2 PQSw = Plano de Qualidade de Software

O Plano de Qualidade de Software é o documento que descreve, de forma detalhada, os procedimentos de garantia da qualidade que serão adotados no projeto. Deve fornecer a base para o acompanhamento e controle de qualidade no projeto, até a colocação de seus resultados em operação. Este documento deve começar a ser escrito no início do projeto, pelo menos parcialmente.
Ele deve conter os elementos essenciais para garantir a qualidade nas fases de Construção e Transição. É de responsabilidade do Gestor de Qualidade, o preenchimento deste documento. Recomendamos que o Gerente assuma esta atividade, junto com o professor e monitores.
Deverá descrever o objetivo específico e o escopo deste Plano de Qualidade de Software, listando os nomes das atividades e dos resultados intermediários do projeto, cobertos por este plano, e explicando em que se pretende usar o produto.
A estrutura organizacional deve ser descrita, pois informará qual a influencia e quem controla a qualidade do software. Assim como a ordem das responsabilidades de cada pessoa envolvida no projeto.
As descrições de todos os documentos que serão produzidos no decorrer do projeto devem indicar os termos e siglas que fazem parte do respectivo documento.
As normas, práticas e métricas que serão adotadas no projeto, devem indicar as atividades a que se aplicam. As práticas abrangem metodologias de desenvolvimento utilizadas, quando diferentes das previstas no processo padrão; Manual de estilo específico para as interfaces de usuário desse tipo de produto. Os padrões específicos da área de aplicação do produto. As métricas abrangem tais como, número de defeitos injetados e removidos em cada fase; Métricas do tamanho do produto, como linhas de código e pontos de função; Métricas de usabilidade do produto, tais como velocidade de desempenho dos usuários, taxa de erros etc., e para mecanismo de garantia da qualidade serão adotadas as revisões formais (PAULA FILHO, 2003).
As revisões descrevem as revisões formais que serão usadas como mecanismos de Garantia da Qualidade.
Os testes serão usados para análise nas auditorias do Gestor de Qualidade. Os testes devem ser agendados e a execução fica por conta da própria equipe.
A política de encaminhamento de problemas e de ações corretivas descreve os procedimentos a serem seguidos para relatar e encaminhar os problemas da qualidade detectados no projeto até sua total resolução.
As ferramentas e técnicas de Garantia da Qualidade irão constar informações das ferramentas e técnicas que serão usadas no decorrer do processo para se alcançar a Garantia da Qualidade (PAULA FILHO, 2003).
O controle de código descreve os componentes físicos (módulos de código fonte e componentes adquiridos) que deverão ser incluídos nas linhas de base do projeto.
Todas as atividades de coletas, manutenção e retenção de registros das atividades de Garantia da Qualidade, caso haja atividades adicionais em relação às previstas na política de garantia da qualidade de software devem ser informadas.
Os treinamentos que a equipe do projeto estão fazendo para nivelar as atividades de Garantia da Qualidade também devem ser informados neste documento.
Descreve as atividades de garantia da qualidade para a gestão dos riscos descritos no PDSw.

6.3 MASw = Modelo de Analise de Software

Modelo que detalha os conceitos do domínio do problema a resolver, que sejam relevantes para a validação dos requisitos. Documenta a visão do analista montando um artefato que contém diagramas que modelam de forma técnica O QUE FAZER utilizando uma visão do sistema (PAULA FILHO, 2003).

De responsabilidade do analista com a participação do administrador de banco de dados, tem como principal objetivo descrever o modelo classe domínio do sistema, para isso, inicialmente estuda quais casos de uso deverão estar na primeira versão do sistema, então, realiza a expansão no formato essencial dos diagramas de casos de uso.
Após a conclusão da descrição dos Diagramas de Caso de Uso, é realizada uma análise narrativa dos textos, sendo destacados os subjetivos que tem características importantes para o sistema [Pressman 2002], posteriormente são elaborados os cartões CRC de cada possível classe, sendo escolhida apenas as classes em potencial verificado na análise dos CRC. Ao final desta seção é desenvolvido o modelo Classe Domínio montando uma configuração em três camadas (Camada de Fronteira, Camada de Controle e Camada de Entidade) para o caso de uso em questão.

Este procedimento se repete até que todo o sistema tenha sido analisado e obtido o modelo Classe domínio para cada caso de uso e, caso seja necessário, finalmente constrói-se o modelo Classe Domínio geral do sistema.

7. Liberação

Liberações das versões do produto - Implementação de um subconjunto de funções do produto que será avaliado pelos usuários, tem como produção os artefatos: CFSw, CESw e MUSw.

8. RAPSW = Relatório de Acompanhamento de Software

Relatórios de Acompanhamento do Projeto do Software- Relatório que descreve esforços, custos, prazos e riscos do projeto, até a data corrente. Tem como principal responsável o gerente de projeto, que deve procurar colher informações junto a equipe para conseguir montar este documento. As atividades que foram entregues à linha base são consideradas como ponto de medição para registrar as etapas concluídas do projeto.

9. CFSw = Código Fonte do Software

Conjunto dos códigos fontes produzidos - Documento que descreve, de forma detalhada, os planos e especificações dos testes que serão executados.

10. CESw = Código Executável do Software

Códigos Executáveis do Software - Conjunto dos códigos executáveis produzidos e deve ser entregue em um CD, bem identificado e encapsulado de forma apresentável. Deve ser fornecido pelo programador, sendo apoiado pelo resto da equipe de desenvolvimento e com o parecer do gerente. Deve ser fornecido junto como manual do Usuário de Software (MUSw) ao responsável pela guarda dos produtos, onde deve ser identificado e armazenado de modo a facilitar a busca do mesmo quando necessário. Uma cópia deve ser entregue à Biblioteca da Eletronorte.

10.1 MUSw = Manual do Usuário de Software

Manual do Usuário do Software- Documento que serve de referência para uso do produto. É sugerido que seja acrescentado ao modelo apresentado na pagina do Praxis, as figuras correspondentes as telas ligadas às funções descritas no manual do Usuário. Deve ser elaborado pelo programador com o apoio do testador e deve ser baseado, principalmente, na ERSw.

11. DDSw = Descrição do Desenho do Software

Deve ser descritos os procedimentos detalhados que deveram ser utilizados como instrumento de orientação e consulta para a montagem do artefato Descrição do Desenho de Software.

Esta IT aplica-se a elaboração de uma Descrição de Desenho de Software , definindo em linhas gerais o que o devera ser desenvolvido da forma que cliente deseja nas especificações.

De acordo com (PADUA, 2001) a descrição de desenho de software resulta do fluxo de Desenho, que faz parte do Processo Práxis. Esse fluxo tem como insumo a Especificação de Requisitos de Software, que descreve, de forma detalhada, um conjunto de requisitos que define uma solução implementável para um problema. Esta descrição estabelece a estrutura com que o produto deverá ser implementado para satisfazer aos requisitos.

12. TesteAlfa

Testes Alfa - Realização dos testes de aceitação, no ambiente dos desenvolvedores, juntamente com elaboração da documentação de usuário e possíveis planos de Transição. Tem como responsável o testador e utilizará o apoio do programador para montar seus documentos.

DESENVOLVIDO POR

FRANKLIN THIAGO NEVES KAWABATA

GRADUAÇÃO EM ANALISE E DESENVOLVIMENTO DE SISTEMA

BLOGGER PESSOAL

http://video-aulas-informatica.blogspot.com/