Projeto de Software situa-se no núcleo técnico da Engenharia de Software e é aplicado independente do processo de desenvolvimento utilizado. Durante esta fase há uma ênfase na definição dos objetos de software, como eles colaboram para a satisfação dos requisitos e como se dará a persistência dos mesmos. Resumidamente esta fase tem por finalidade:
Fornecer a descrição lógica de como um sistema funcionará baseada no paradigma orientado a objetos;
Definir as relações entre os elementos estruturais do software, os padrões de projeto que podem ser usados para satisfazer os requisitos;
Identificar estruturas de dados necessárias para implementação do software;
Projetar casos de testes para validação do software;
Definir ambientes para desenvolvimento, homologação e produção;
Planejar contingência;
Como produto teremos a geração dos seguintes artefatos: Diagrama de Sequência (por cenário de Caso de Uso), Modelo de Projeto (Classes de Controle, Classes de Serviços e Classes de Persistência e Classes de Domínio), Modelo de Dados, Plano de Migração, Casos de Teste, Plano de Contingência.
Etapa:
Planejamento de Fase Projeto
Descrição:
Esta etapa consiste no planejamento (determinando atividades) da fase de projeto do subprojeto em questão(iteração).
Nesta etapa orienta-se também a realização de uma Reunião de Apresentação do Projeto para as pessoas que estão integrando a equipe de projeto, bem como, verificar ambiente local de desenvolvimento dos mesmos.
Convocar os colaboradores do projeto, que ainda não integram a equipe de trabalho, para uma reunião onde serão fornecidas as informações disponíveis até o momento sobre o projeto.
Entradas:
Documentos Gerados nas fases de Contratação e Análise:
Projeto Preliminar ;
Especificação de Casos de Uso;
Modelo de Caso de Uso;
Interface Gráfica;
Modelo de Domínio;
Plano de Teste;
Estimativa de Projeto revisada;
Plano de iterações (planejamento dos subprojetos com respectivo cronograma geral);
Deve solicitar que sua equipe verifique se suas estações de trabalho possuem o ambiente necessário, conforme padrão estabelecido na CELEPAR, para iniciar as atividades do projeto.
Também está incluída nesta atividade a liberação de direito de acesso no repositório do projeto no sistema de controle de versão, ferramenta indispensável para o desenvolvimento do projeto.
Entradas:
Não aplicável.
Saídas:
Ambiente Desktop verificado;
Direito de acesso ao Repositório do projeto criado.
Ferramentas:
Expresso - Solicitação de Serviço (OS) ao setor responsável.
Modelos:
Não aplicável.
Tarefas:
Solicitar verificação do ambiente das estações de trabalho;
Solicitar liberação de acesso ao repositório do projeto no sistema de controle de versão.
Acompanhar a execução da fase de Projeto e avaliar possíveis mudanças durante o processo.
No contexto do software Almirante as mudanças se manifestam através de Ocorrências e solicitações de replanejamento durante o processo de execução de tarefa.
Uma ocorrência, nesta fase, pode ser tratada através de replanejamentos que resultam em alterações no cronograma..
Entradas:
Dados fornecidos pelo software Almirante.
Saídas:
Ocorrências avaliadas e cronograma da fase refinado.
Uma realização de caso de uso descreve como um caso de uso é realizado no Modelo de Projeto, em termos de objetos que colaboram entre si para executar as tarefas requeridas.
Representa a conexão existente entre os requisitos expressos nos casos de uso e o projeto de objetos que atende a esses requisitos.
Entradas:
Modelo de Casos de Uso;
Especificação de Casos de Uso;
Interface Gráfica;
Classes de Tela;
Diagrama de Sequência (por cenário de caso de uso);
Modelo de Domínio.
Saídas:
Diagrama de Sequência (por cenário de caso de uso);
Complemento do Modelo de Domínio, acrescentando os métodos de negócio;
Modelo de Projeto (Classes de Controle, Classes de Serviços e Classes de Persistência e Classes de Domínio).
Ferramentas:
RSM - Rational Software Modeler;
Editor de Texto.
Modelos:
Não aplicável.
Tarefas:
Criar o Diagrama Sequência por cenário de caso de uso, vinculando aos elementos arquiteturais necessários para a realização do caso de uso.
Tem por finalidade a especificação das operações (corpo dos métodos) identificados nas classes de domínio, classes de persistência e classes de serviço necessários à realização dos casos de uso.
Entradas:
Modelo de Projeto (Classes de Controle, Classes de Serviços;
Classes de Persistência e Classes de Domínio).
Saídas:
Documentação Textual das operações, realizada na própria RSM - Rational Software Modeler.
Descrever o quê cada operação deve fazer, o corpo do método. Observação: Evitar a citação de nomes de outros métodos na propriedade documentação, a chamada de métodos deve estar sempre explícita no diagrama de Sequência. Desta forma, alterações na sua assinatura são efetivadas automaticamente em todos os diagramas do projeto.
Criar casos de teste para orientar a execução dos testes de validação. Observação: É importante salientar que neste momento o responsável está desempenhando o papel de Analista de Testes, conforme o Guia do Processo de Teste.
Têm por finalidade transformar o Modelo de Domínio nas estruturas de dados necessárias para implementar o software (Modelo de Dados), garantindo que os dados persistentes sejam armazenados com consistência e eficiência.
O modelo de dados descreve a representação lógica e física dos dados persistentes no sistema e abrange qualquer comportamento definido no banco de dados, como procedimentos armazenados, triggers, restrições etc.
Entradas:
Modelo de Domínio.
Saídas:
Modelo de Dados.
Ferramentas:
Software Power Architect.
Modelos:
Não aplicável.
Tarefas:
Mapear classes persistentes para o Modelo de Dados.
Tem por finalidade elaborar o mapeamento da migração de uma base de dados antiga para o modelo de dados atual, bem como a criação dos scripts necessários para a migração.
Entradas:
Modelo de Dados;
Modelo de Dados da base antiga ou o próprio banco antigo.
Esta etapa consiste em dar continuidade, visto que, a verificação de ambientes já iniciada na fase de contratação, no planejamento da implantação do subprojeto em questão. Ela contempla a verificação de ambientes para a construção e implantação da versão do software e a elaboração do plano de contingência.
As demais atividades (documentação do usuário, material de treinamento, etc...) serão executadas em fases subsequentes.
Confirmar se os ambientes servidor de desenvolvimento, homologação e produção estão disponíveis.
Caso não estejam, solicitar sua criação. Também é importante entrar em contato o setor responsável (GTI), na Diretoria de Tecnologia de Informação, e agendar reunião técnica para maiores esclarecimentos.
Esta atividade já foi iniciada na fase de contratação, conforme indicado pelo processo de desenvolvimento, entretanto, é necessário revisá-la na fase de projeto onde implicações e necessidades técnicas estarão mais elucidadas.
Além do preenchimento do OpenGOP (Gestão Operacional de Data Center) é necessário solicitar a criação dos ambientes via ordem de serviço (OS) e identificar as datas em que os ambientes precisam estar disponíveis.
Verificar ambientes servidor de desenvolvimento, homologação e produção;
Cadastrar o sistema no software Gestão Operacional de Data Center(OpenGOP);
Solicitar criação do ambiente de desenvolvimento, homologação e produção, se necessário, através de Solicitação de Serviço(OS);
Agendar reunião técnica, caso necessário, com o setor responsável, na Diretoria de Tecnologia de Informação, para esclarecimentos sobre os ambientes necessários;
Elaborar o plano de contingência para descrever as medidas que devem ser tomadas para assegurar a continuidade dos seus processos de negócio essenciais, no caso de falha do sistema automatizado.
Identificar e registrar mudanças de requisitos .
A identificação da mudança de requisitos inicia-se com uma percepção de uma alteração de mercado, de legislação (imposição), de alterações de fundos para o projeto (recursos financeiros ou de pessoal tanto interno da CELEPAR como do cliente), de disponibilização ou mudança de tecnologia, de algum outro ato ou necessidade percebida..
Avaliar Impactos e informar o líder de projeto e, este por sua vez, deverá avisar os respectivos líderes de fase para programarem as tarefas necessárias;
Documentar mudanças de requisitos;
Aprovar Mudanças de Requisitos e Replanejamento do Projeto.