Conteúdo:
• Ciclo de vida de Um Projeto.
• Método Engenharia de Software.
• Análises de Risco
• Requisitos Funcionais e Não funcionais de um
sistema
• GanttProject(Trello)
• UML
Ciclo de vida de Um Software
• A norma NBR ISO/IEC 12207:1998 define de maneira oficial o que é o ciclo de vida de um software: “Estrutura contendo processos, atividades e tarefas envolvidas no desenvolvimento, operação e manutenção de um produto de software, abrangendo a vida do sistema, desde a definição de seus requisitos até o término de seu uso.”
• O ciclo de vida de um projeto é a divisão da Gestão do Projeto em fases pelas quais ele deve passar do início ao término. A cada período que corresponda a uma fase, o projeto pode sofrer incrementos e alterações significativas que ditarão o ritmo das atividades que devem ser desenvolvidas.
• A depender da complexidade e do escopo do projeto, cada fase pode ser dividida em subunidades, de modo a conferir uma melhor organização ao trabalho desenvolvido. Esse é um ponto-chave para que as equipes saibam se situar à medida que as etapas avançam.
• No contexto de cada fase, as atividades estão relacionadas de maneira lógica, sendo que a conclusão de cada uma delas está associada a uma entrega. Ao mesmo tempo, essa estrutura de fases permite que o controle seja segmentado em subconjuntos lógicos para facilitar o gerenciamento, o planejamento e o controle.
Fases do ciclo de vida em projetos
As fases do ciclo de vida de projetos são definidas pela organização ou pelo gerente de projetos — conforme aspectos específicos da organização, do setor ou da tecnologia empregada.
Inicio do Projeto
• É o momento em que ocorre o planejamento do projeto, são levantados os requisitos mínimos, estuda a viabilidade do
software e definido qual modelo de ciclo de vida será usado.
• Documentos necessários:
– Elabora o termo de abertura;
– Elabora os requisitos funcionais e não funcionais – Define o ciclo de vida:
• Estruturado: Incremental, interativo, Cascata, espiral, modelo v e prototipagem
Organização e preparo
• A etapa de organização e preparação envolve a definição
de uma metodologia de gestão de projetos a ser
utilizada. Na prática, isso significa escolher as melhores
estratégias tendo em vista os recursos mobilizados e os
objetivos que devem ser perseguidos.
• Dessa maneira, é importante realizar os seguintes
encaminhamentos:
– previsão de recursos;
– dimensionamento de custos;
– quadro de pessoal disponibilizado para o projeto;
– definição de competências;
Execução do Trabalho
• A essa altura, todo o planejamento das etapas anteriores é colocado em prática. Com isso, qualquer equívoco no momento de planejar as ações ficará exposto — o que demanda um constante esforço de
monitoramento.
• Também é importante destacar que a maior parte dos recursos mobilizados — orçamento, quadro de pessoal e esforços empregados por atividade — será consumida aqui.
• Colocar em pratica a programação da interface, banco de dados. • Realizar os testes e correções
Encerramento do Projeto
• No ciclo de vida de um projeto, cada uma dessas entregas — as quais representam o encerramento de uma fase — precisa ser
aceita e avaliada pelo cliente ou por quem dará continuidade aos trabalhos no momento seguinte.
Método Engenharia de Software.
• O termo metodologia é bastante controverso nas ciências em geral e na Engenharia de Software em particular. Muitos autores parecem tratar metodologia e método como sinônimos, porém seria mais adequado dizer que uma metodologia envolve princípios filosóficos que guiam uma gama de métodos que utilizam ferramentas e práticas diferenciadas para realizar algo.
• Segue abaixo as principais Metodologias e Métodos correspondentes no desenvolvimento de software:
• Metodologia Estruturada – Análise Estruturada
– Programação Estruturada
– DFD – Diagrama de Fluxo de Dados
– MER – Modelo de Entidades e Relacionamentos • Metodologia Orientada a Objetos
– Orientação a Objetos
– Rational Unified Process ( RUP ) • Desenvolvimento ágil de software
– Feature Driven Development ( FDD ) – Scrum (Scrum)
Análises de Risco
• Atualmente, a área que trata riscos na Engenharia de Software evoluiu, passando de uma análise dentro das fases do modelo de desenvolvimento de software para se tornar uma gerência que permeia todos os processos do ciclo de vida do software (o ciclo de vida do software vai desde a concepção de ideias até a descontinuidade do produto de software).
Risco de software pode ser caracterizado como [PMI 2004]:
• Riscos de Projeto de Software. Define os parâmetros operacionais, organizacionais e contratuais do desenvolvimento de software. Inclui limites de recursos, interfaces, relacionamentos com fornecedores ou restrições de contratos.
• Riscos de Processo de Software. Relacionam-se os problemas técnicos e de gerenciamento. Nos procedimentos de gerência podem-se encontrar riscos em atividades como: planejamento, definição e contratação de equipe de trabalho, garantia de segurança e configuração de gerência. Nos procedimentos técnicos, podem-se encontrar riscos nas atividades: análise de requisitos, projeto, codificação e testes, por exemplo.
• Riscos de Produto de Software. Contém as características intermediárias e finais do produto. Estes tipos de riscos têm origens nos requisitos de estabilidade do produto, desempenho, complexidade de codificação e especificação de testes.
Requisitos Funcionais
Não funcionais de um sistema
• Requisito Funcional
– estamos nos referindo à requisição de uma função que um software deverá atender/realizar. Ou seja, exigência, solicitação, desejo, necessidade, que um software deverá materializar
• Requisitos Não Funcionais
– Requisitos não funcionais são relacionados ao uso da aplicação em termos de desempenho, usabilidade, confiabilidade, disponibilidade, segurança e tecnologias envolvidas. Muitas vezes, os requisitos não funcionais acabam gerando restrições aos funcionais.
GranttProject ( Trello)
• A tarefa de gerenciar o tempo do projeto engloba, além do minucioso processo para a criação e monitoramento do cronograma, a adaptabilidade do projeto em relação a mudanças ou necessidades criadas no mesmo, e ainda, o gerenciamento dessas mudanças.
• Um projeto que envolva o desenvolvimento de software inclui as dificuldades em se manter os requisitos levantados no início do projeto até o término dele, nisso está a importância, associada ao gerenciamento do tempo das atividades, de uma boa coleta de requisitos inicial.
• Pois, é com base no detalhamento do escopo do projeto que o cronograma será criado. Logo, um cuidadoso Gerenciamento do Tempo e do Escopo é a parte substancial do desenvolvimento de um projeto que envolva a construção de software.
• Segundo o Guia de conhecimento PMBOK, são sete os elementos necessários para o Gerenciamento do Tempo de um projeto. São eles:
– o plano de gerenciamento do cronograma; – a definição das atividades;
– o sequenciamento das atividades;
– a estimativa dos recursos das atividades; – a estimativa das durações das atividades;
– o desenvolvimento do cronograma do projeto; – e o controle dele.
UML
• UML é um acrônimo para a expressão Unified Modeling Language. Pela definição de seu nome, vemos que a UML é uma linguagem que define uma série de artefatos que nos ajuda na tarefa de modelar e documentar os sistemas orientados a objetos que desenvolvemos.
• Diagramas utilizados:
– Diagrama de caso de Uso – Diagrama de Classe
– Diagrama de Sequência – Diagrama de Atividade
Diagrama de Caso de Uso
• Esse diagrama documenta o que o sistema faz do ponto de vista do
usuário. Em outras palavras, ele descreve as principais funcionalidades do
sistema e a interação dessas funcionalidades com os usuários do mesmo sistema. Nesse diagrama não nos aprofundamos em detalhes técnicos que dizem como o sistema faz.
• Este artefato é comumente derivado da especificação de requisitos, que por sua vez não faz parte da UML. Pode ser utilizado também para criar o documento de requisitos.
• Diagramas de Casos de Uso são compostos basicamente por quatro partes:
– Cenário: Sequência de eventos que acontecem quando um usuário interage com o sistema.
– Ator: Usuário do sistema, ou melhor, um tipo de usuário.
– Use Case: É uma tarefa ou uma funcionalidade realizada pelo ator (usuário) – Comunicação: é o que liga um ator com um caso de uso
Exemplo
AssociaçãoGeneralização
Include
Um relacionamento include de um caso de uso A para um caso de uso B indica que B é essência
Extend
Um relacionamento extend de um caso de uso B para um caso de uso A indica que o caso de uso B pode ser acrescentado para descrever o comportamento de A (não é essencial). A extensão é inserida em um ponto de extensão do caso de
Diagrama de Classe
Descrever os vários tipos de objetos no sistema e o relacionamento entre eles.
Perspectivas
Um diagrama de classes pode oferecer três perspectivas, cada uma para um tipo de observador diferente. São elas:
•Conceitual
•Representa os conceitos do domínio em estudo. •Perspectiva destinada ao cliente.
•Especificação
•Tem foco nas principais interfaces da arquitetura, nos principais métodos, e não como eles irão ser implementados.
•Perspectiva destinada as pessoas que não precisam saber detalhes de desenvolvimento, tais como gerentes de projeto.
•Implementação - a mais utilizada de todas
•Aborda vários detalhes de implementação, tais como navegabilidade, tipo dos atributos, etc.
• Classe Concreta
– Uma classe é representada na forma de um retângulo, contendo duas linhas que separam 3 partes. A primeira contém no nome da classe, a segunda os atributos da classe e a última os métodos da mesma.
• Relacionamento
– Associação : Define um relacionamento entre duas entidades conceituais do sistema.
– Herança ou Generalização: Considera que B é um subtipo ou um tipo especial de A. O que é válido para A, também é válido para B.
– Agregação: é uma associação em que um objeto é parte de outro, de tal forma que a parte pode existir sem o todo.
– Composição:O todo contém as partes (e não referências para as partes). Quando o todo desaparece, todas as partes também desaparecem
Diagrama de Sequencia
Consiste em um diagrama que tem o objetivo de mostrar como as mensagens entre os objetos são trocadas no decorrer do tempo para a realização de uma operação.
Em um diagrama de sequência, os seguintes elementos podem ser encontrados: • Linhas verticais representando o tempo de vida de um objeto (lifeline);
• Estas linhas verticais são preenchidas por barras verticais que indicam exatamente quando um objeto passou a existir. Quando um objeto desaparece, existe um "X" na parte inferior da barra;
• Linhas horizontais ou diagonais representando mensagens trocadas entre objetos. Estas linhas são acompanhadas de um rótulo que contém o nome da mensagem e, opcionalmente, os parâmetros da mesma. Observe que também podem existir mensagens enviadas para o mesmo objeto, representando uma iteração;
• Uma condição é representada por uma mensagem cujo rótulo é envolvido por colchetes;
• Mensagens de retorno são representadas por linhas horizontais tracejadas. Este tipo de mensagem não é frequentemente representada nos diagramas, muitas vezes porque sua utilização leva a um grande número de setas no diagrama, atrapalhando o entendimento do mesmo. Este tipo de mensagem só deve ser mostrada quando for fundamental para a clareza do diagrama.
Diagrama de Atividade
• O objetivo do diagrama de atividades é mostrar o fluxo de atividades em um único processo. O diagrama mostra como um atividade depende uma da outra.
• Um diagrama de atividade pode ser regiões denominadas swimlanes. Estas regiões estão associadas a um objeto do modelo. Desta forma, dentro de cada região, encontram-se as atividades relativas ao objeto da região.
• As atividades são conectadas através de arcos (transições), que mostram as dependências entre elas.
