RESUMO ENGENHARIA DE SOFTWARE

Documentao de Software extremamente necessria e auxilia na reduo de horas preciosas na correo de problemas. Stakeholder qualquer pessoa ou organizao que tenha interesse, ou seja, que seja afetado pelo projeto. Levantamento de Requisitos: feito por meio de entrevistas e questionrios. BrainStorm mais que uma tcnica de dinmica em grupo, uma atividade desenvolvida para explorar a potencialidade criativa do ser humano. Documentao: A documentao de um software composta por vrias partes diferentes que abrangem todo o sistema e pode ser dividida em dois grandes grupos: documentao tcnica e documentao de uso. Tcnica: voltada ao desenvolvedor ou pessoa de TI e compreendem principalmente dicionrios e modelos de dados, fluxogramas de processos e regras de negcios, dicionrios de funes e comentrios de cdigo. De uso: voltada tanto para o usurio final quanto para administrador do sistema, formada por apostilas ou manuais que apresentam como o software deve ser usado, o que esperar dele e como receber as informaes que se deseja. Uso da Documentao: Meio de comunicao entre os membros de um grupo de desenvolvimento; Informaes gerncia de modo a ajudar a planejar, fazer o oramento e o cronograma; Informaes para ensinar aos usurios como utilizar e administrar o sistema. Informaes para as pessoas que venham a fazer manuteno no sistema; Documentao do Processo o produzida para que o processo de desenvolvimento do software seja administrvel; o Registram os processos de desenvolvimento e manuteno do software. o Categorias: Planos, estimativas e cronogramas; Relatrios; 1

Tipo de Documentao:

Padres; Memorandos, comunicaes, mensagens eletrnicas; Documentos tcnicos de trabalho.

Documentao do produto o Descreve o software que est sendo desenvolvido; o muito utilizada depois que o sistema implementado, mas essencial tambm para a administrao do processo de desenvolvimento. o Divide-se em: Documentao do Sistema Descreve a implementao do sistema desde a especificao dos requisitos at o plano de testes. Documentao do cdigo.

Documentao do Usurio Deve levar em conta os diversos tipos de usurios, exemplo, usurios finais e administradores do sistema. Descrio funcional do sistema, ou seja, os requisitos gerais do sistema e dos servios oferecidos por ele; Categoria: o Manual de introduo; o Manual de referncia; o Documento de Instalao; o Manual do administrador do sistema; o Manual de referncia rpida do sistema; o Ajuda on-line.

Qualidade dos documentos: to importante quanto qualidade do cdigo. o Aspectos importantes para se conseguir produzir bons documentos incluem: Planejamento (ou projeto) dos documentos; A existncia de padres a serem seguidos; Procedimentos de garantia de qualidade

Qualidade da documentao depende de: o Planejamento; 2

o Padronizao; o Medidas de qualidade; o Estilo de escrita.

Planejamento de Projeto Um processo de software bem definido e documentado, utilizado para integrar pessoas, tarefas, ferramentas e mtodos, pode prover a base essencial para garantira qualidade do produto final. Um processo de software gerenciado propicia segurana frente s variaes que o produto possa sofrer em relao s suas especificaes iniciais. CMM (Capability Maturity Model): definido como sendo uma soma de "melhores prticas" para diagnstico e avaliao de maturidade do desenvolvimento de softwares em uma organizao. Descreve os principais elementos de um processo de desenvolvimento de software. Descreve tambm os estgios de maturidade por que passam as organizaes enquanto evolui no seu ciclo de desenvolvimento de software, definido por cinco nveis de maturidade: Inicial, Repetvel, Definido, Gerenciado e Otimizado. Por que planejar? O desenvolvimento de software possui vrios ciclos, que podem ser repetidos diversas vezes, at que se obtenha um produto que satisfaa aos requisitos do cliente. O planejamento essencial para: o Decidir se o projeto continuar ou no; o Servir de base para o gerenciamento de projeto; o Determinar o alcance do trabalho a ser realizado: funo, desempenho, interface e segurana; o Estimar recursos necessrios ao desenvolvimento do software: recursos humanos, de hardware e de software; o Identificar tarefas a serem efetuadas; o Elaborar cronogramas. Como medir o tamanho de um software: Contagem de Linhas de Cdigo (LOC) ou Contagem por Pontos de Funo (PF). Como estimar esforo e tempo: Conhecendo o tamanho possvel estimar esforo e tempo, alm do custo. Podendo para isso ser utilizado o Modelo COCOMO. 3

Gerenciamento de Riscos: Risco um problema em potencial pode ou no acontecer. importante: identific-lo, avaliar sua probabilidade de ocorrncia, estimar seu impacto e estabelecer um plano de contingncia para o caso dele efetivamente ocorrer. Cronograma: tem como objetivo apresentar graficamente as datas de incio e trmino de cada atividade, uma vez que os recursos, duraes e as interdependncias j esto estabelecidas. O cronograma do projeto pode ser apresentado de diferentes formas: Tabelas com listas de atividades, Grficos de Gantt, Grficos de marcas ou etapas, etc. Recursos do Projeto: Recursos Humanos: o Projetos Pequenos: uma nica pessoa; o Projetos Grandes: participao varia atravs do ciclo de vida; Recursos de Hardware: o Hardware de desenvolvimento: usado durante o desenvolvimento (pode ser mais robusto); o Mquina alvo: hardware em que o sistema vai rodar depois de pronto; o Outros elementos: hardware que interage com o novo sistema; Organizao da Equipe: Deve ser considerado o fator humano em seus aspectos psicolgicos, individuais e grupais e o reflexo deles no desempenho da equipe o Principais estruturas de equipe: Equipe Convencional composta pelo pessoal disponvel, onde designado um gerente de desenvolvimento. O trabalho divido pelos componentes da equipe e cada um responsvel pelo projeto e implementao da sua parte, dando um sentimento de posse. o Equipe No Egocntrica Organizado em estilo democrtico e descentralizado, h as relaes e comunicaes informais, a liderana no exercida por uma determinada pessoa permanentemente, ela fica com o indivduo que tiver mais maior capacitao para resolver o problema em pauta e todos os programas so examinados por outros programadores. o Equipe de Programador Chefe H um pequeno nmero de componentes e as comunicaes centralizada no programador chefe. As decises so tomadas nos

nveis mais elevados e o programador chefe que ser muito experiente e capacitado para a funo. o Equipe Hierrquica uma proposta de estrutura intermediria, um lder de projeto dirige programadores experientes que por sua vez dirigem um grupo de programadores descentralizado superiores. Gerencia de Projetos: Novas tecnologias surgem a todo momento, a dependncia da TI cada vez maior, com isso os clientes se tornam mais exigentes, sempre necessrio mudanas frequentes nos sistemas para atender a demanda de negocio, e estes negcios exigem um tempo de resposta mais rpido em relao as mudanas. PMI (Project Management Institute): Organizao de servio voluntrio, presente em 263 cidades de 125 pases, possui mais de 170 mil profissionais de gerenciamento de projetos no mundo. Oferece uma certificao (PMP Project Management Professional), e um guia o PMBoK (Project Management Body of Knowledge Guide), onde divulga conhecimento e prtica de gerenciamento de projetos e valorizao profissional. O PMBoK um documento que contem tcnicas, mtodos e processos relativos a Gerncia de Projetos. Projeto: um empreendimento temporrio tendo seu inicio e fim definido em uma sequencia clara e lgica de eventos, sendo conduzido por pessoas dentro dos paramentos prdefinidos de prazo, custo, recursos envolvidos e qualidade. Simplificando, um projeto um empreendimento temporrio com o objetivo de criar um produto ou servio nico. Habilidades Gerenciais: Liderar: Nem sempre o lder ser o gerente, mas necessrio ter os dois perfis. A gerencia consiste em atender os stakeholders, e liderar consiste em alinhas as pessoas para alcanar um objetivo, ou seja, direcionando o pessoal, dando motivao e inspirao. Comunicar: transmitir as informaes de forma clara e objetiva, determinar como, quando, de que forma, e para quem informar, independente da forma (escrita, oral, escutada, falada, interna, externa, formal, informal, vertical ou horizontal). Negociar: Chegar em acordo a diversos fatores, e ela necessria no s por inicio e ocorre nos vrios nveis de projeto. Solucionar Problemas: Definir (causa e sintoma) do problema e tomada de deciso. Estes problemas podem ser: internos, externos, tcnicos, gerenciais e interpessoais. menos nos experientes. e A comunicao nos subgrupos centralizadas nveis

 Influenciar a negociao: o fazer acontecer, por isso, necessrio conhecer a estrutura formal e informal das organizaes envolvidas, habilidade de influenciar o comportamento, entre outras. Processos da Gerncia de Projeto: Inicializao: Reconhecer que um projeto ou fase deve comear e se comprometer com sua execuo; Planejamento: Planejar e manter um esquema de trabalho vivel para atingir aqueles objetivos de negocio que determinaram a existncia do projeto. Execuo: Coordenar pessoas e outros recursos para realizar o que foi planejado. Controle: Assegurar que os objetivos do projeto esto sendo atingidos, atravs da monitorao e de avaliao do seu progresso, tomando aes corretivas quando necessrias; Finalizao: Formalizar a aceitao do projeto ou fase e fazer seu encerramento de forma organizada. Engenharia de Requisitos: De acordo com o IEEE, o processo de aquisio, refinamento e verificao das necessidades do usurio. A E.R. busca desenvolver uma especificao completa, consistente e no ambgua, servindo de base para um acordo entre todas as partes envolvidas e descrevendo o qu o produto de software ir fazer ou executar, mas no como ele ser feito. Requisito: uma condio ou capacidade que deve ser satisfeita ou possuda por um sistema ou componente do sistema para satisfazer um contrato, um padro ou uma especificao (IEEE). Requisito de Usurio: Declaraes em linguagem natural mais diagramas de servios que o sistema fornece e suas restries operacionais. Escritos para os usurios. Requisito de Sistema: Um documento estruturado estabelecendo descries detalhadas das funes, servios e restries operacionais do sistema. Define o que deve ser implementado e assim, pode ser parte de um contrato entre o cliente e o desenvolvedor. Requisitos Funcionais: Declaraes de servios que o sistema deve fornecer, como o sistema deve reagir a entradas especficas e como o sistema deve se comportar em determinadas situaes. Requisitos no Funcionais: Restries sobre servios ou funes oferecidos pelo sistema tais como restries de timing, restries sobre o processo de desenvolvimento, padres, etc. 6

 Requisitos de Domnio: Requisitos que vm do domnio de aplicao do sistema e que refletem as caractersticas desse domnio. Especificao: uma descrio rigorosa e minuciosa das caractersticas que um material, uma obra ou servio devero apresentar. A Engenharia de Requisitos dividida em quatro fases: Estudo de viabilidade: entendimento do negcio e como o sistema pretende apoiar os processos de negcio Elicitao e anlise de requisitos Validao dos requisitos Gerenciamento dos Requisitos Resultado: DOCUMENTO DE REQUISITOS. Estudo de Viabilidade: um estudo de viabilidade que decide se vale a pena ou no gastar tempo e esforo com sistema proposto. Proposto em quatro etapas: Estudo de viabilidade Elicitao e anlise de requisitos: reunir informaes sobre o sistema proposto e os existentes o Fonte: documentos, organizao, especificaes existentes, observaes, entrevistas, ... Validao dos requisitos Gerenciamento dos Requisitos Tcnicas para validao de Requisitos: Revises de requisitos: Anlise manual sistemtica dos requisitos. Prototipao: Uso de um modelo executvel do sistema para verificar requisitos. Gerao de casos de teste: Desenvolvimento de testes para requisitos a fim de verificar a testabilidade. Resumindo: A elicitao e a anlise de requisitos constituem um processo iterativo, envolvendo entendimento de domnio, coleta, classificao, estruturao, priorizao e validao de requisitos. Os sistemas tm mltiplos stakeholders com diferentes requisitos. Fatores sociais e organizacionais influenciam os requisitos de sistema. A validao de requisitos est relacionado s verificaes de validade, consistncia, completeza, realismo e facilidade de verificao. Mudanas de negcio levam, inevitavelmente, s mudanas de requisitos. 7

 O gerenciamento de requisitos inclui planejamento e gerenciamento de mudanas.

Usurios de um Doc. De Requisito: Clientes de Sistema: Especificam os requisitos e os leem para verificar se eles atendem a suas necessidades, e especificam as mudanas nos requisitos. Gerentes: Utilizam o documento de requisitos para planejar um pedido de proposta para o sistema e para planejar o processo de desenvolvimento de sistema. Engenheiros de Sistema: Utilizam o documento de requisitos para compreender que sistema deve ser desenvolvido. Engenheiros de Teste de Sistema: Utilizam o documento de requisitos para desenvolver testes de validao para o sistema. Engenheiros de Manuteno do Sistema: Utilizam o documento de requisitos para ajudar a compreender o sistema e as relaes entre as partes. Tcnicas de Extrao: Tcnicas informais: Baseada em comunicao estruturada e interao com o usurio. Exemplo: Entrevista, questionrio, Tcnica dos 5 Ws, Joint Application Design (JAD), Brainstorming, Observaes, PIECES, etc. Tcnicas Formais: construo de um modelo conceitual do problema sendo analisado, ou de um prottipo de um produto de software a ser construdo.

UML (Linguagem de Modelagem Unificada): No uma metodologia de desenvolvimento que mostra como projetar o sistema e sim uma forma de auxilio na visualizao do desenho com a comunicao entre objetos. Seu desenvolvimento teve inicio em outubro de 1994, quando Rumbaugh se juntou a Booch na Rational. Com o objetivo de unificar os mtodos Booch e OMT em 1995 foi lanado o esboo da verso 0.8 do Unified Process (Processo Unificado, como a UML era conhecida primeiramente). Aps a juno de Jacobson Rational a UML foi expandida para incorporar o mtodo OOSE, e em 1996, foi lanada a verso 0.9 da UML. OMG (Object Management Group): organizao internacional que aprova padres abertos para aplicaes orientadas a objeto. Ela possibilitou que outras empresas pudessem contribuir com a evoluo da UML, chagando a verso 1.1 da mesma. Vises da UML 2.0: Viso de Requisitos Funcionais: Requisitos Funcionais do sistema pelo ponto de vista do usurio oDiagrama de Casos de Uso Viso Estrutural Esttica: Estrutura esttica do sistema oDiagrama de Classes, Diagrama de Estrutura. Viso de Comportamento Dinmico: Comportamento dinmico do sistema, mostrando suas interaes. oDiagramas de Sequencias, Diagrama de Atividades, Diagrama de Estados. A UML 2.0 define 13 tipos de diagramas divididos em 2 categorias: Diagramas Estruturais

oPacotes oClasses oObjetos oEstrutura Composta oComponentes oInstalao Diagramas Comportamentais

oCasos de uso oAtividades oMquina de estado 10

oColaborao ou Comunicao oSequncia oTempo oInteratividade Modelagem Esttica ou Estrutural: Os diagramas estticos ou estruturais definem estaticamente a arquitetura de um modelo. So usados para modelar classes, objetos, relaes e componentes fsicos que compem um modelo. Alm disso, tambm so usados para modelar os relacionamentos e as dependncias entre elementos. Modelagem Dinmica (de Comportamento): Os diagramas dinmicos ou de comportamento apresentam as variedades da interao e do estado instantneo dentro de um modelo enquanto executado. Diagramas: 1. DIAGRAMA DE PACOTES ou DE MDULOS: Descreve os pacotes ou pedaos do sistema dividido em agrupamentos lgicos, mostrando as interaes entre eles, j que pacotes podem depender de outros pacotes. muito utilizado para ilustrar a arquitetura de um sistema mostrando o agrupamento de suas classes.

11

2. DIAGRAMA DE CLASSES: Define os elementos bsicos de um modelo, ou seja, os tipos, as classes e os relacionamentos usados para construir um modelo completo. Em programao uma representao da estrutura e relaes das classes que serve de modelo para objetos, muito til para o sistema, pois define todas as classes que o sistema necessita possuir e a base para a construo dos diagramas de comunicao, sequencia e estados.

3. DIAGRAMA DE OBJETOS: uma variao do diagrama de classe e utiliza quase a mesma notao, porm nele apresentado os atributos com valores e mostra os objetos que foram instanciados das classes. No to importante, mas til para exemplificar diagramas de classes mais complexos. Tambm usado como parte dos diagramas de colaborao, onde mostrada a colaborao dinmica entre os objetos.

12

4. DIAGRAMA DE ESTRUTURA COMPORTAMENTAL: Destina-se descrio dos relacionamentos entre os elementos, ou seja, a colaborao interna de classes, interfaces ou componentes para especificar uma funcionalidade. Fornece meios de definir a estrutura de um elemento e de focar no detalhe, na construo e em relacionamentos internos, mostrando a estrutura interna de um classificador estruturado ou colaborao.

5. DIAGRAMA DE COMPONENTES: Mostra como as classes devero se encontrar, organizadas atravs da noo de componentes de trabalho, ou seja, as dependncias entre componentes de software, incluindo implementaes de classes, arquivos de cdigo fonte, arquivo de cdigo binrio, arquivos executveis, scripts.

13

6. DIAGRAMA DE INSTALAO ou EXECUO: mostra a configurao dos elementos de processamento em tempo de execuo, alm dos componentes, processos e objetos do sistema, sendo usado para modelar a arquitetura de um sistema da perspectiva dos componentes de hardware e dos componentes de software.

7. DIAGRAMA DE CASO DE USO: Descreve a funcionalidade proposta para o sistema, sendo usado para modelar interaes do usurio/sistema. Define o comportamento, as exigncias e o resultado esperado de um a funcionalidade. Ele descr a sequencia de eventos de um ator que usa um sistema para completar um processo. 14

8. DIAGRAMA DE MQUINA DE ESTADOS: uma representao do estado ou situao em que um objeto pode se encontrar no decorrer da execuo de processos de um sistema. Com isso, o objeto pode passar de um estado A (estado inicial) para um estado B (estado final) atravs de uma transio. Representa as aes ocorridas em reposta ao recebimento de um evento, onde cada ponto de parada representa um estado da aplicao.

9. DIAGRAMA DE ATIVIDADES:

uma variao do diagrama de mquina de

estados que representa a execuo das aes e as transies que so acionadas pela concluso de outras aes ou atividades, ou seja, um grfico de fluxo, mostrando o fluxo de

15

controle de uma atividade para outra. Comumente, isso envolve a modelagem das etapas sequenciais em um processo computacional.

10. DIAGRAMA DE COLABORAO ou COMUNICAO: Mostra, de maneira semelhante ao diagrama de sequncia, a colaborao dinmica entre os objetos, ou seja, exibe uma interao, consistindo de um conjunto de objetos e seus relacionamentos, incluindo as mensagens que podem ser trocadas entre eles. Com nfase for o contexto do sistema, que d prioridade ordenao estrutural em que as mensagens so trocadas entre os objetos de um sistema.

11. DIAGRAMA DE SEQUENCIA: Representa a sequncia de processos, usado para representar o comportamento das operaes, mtodos entre classes de um cenrio. Ele 16

registra o comportamento de um nico caso de uso, e exibe os objetos e as mensagens passadas entre esses objetos, descrevendo a maneira como os grupos de objetos colaboram em algum comportamento ao longo do tempo. O diagrama de sequncia d nfase ordenao temporal em que as mensagens so trocadas entre os objetos de um sistema.

12. DIAGRAMA DE TEMPO ou TEMPORAL: O Diagrama de tempo, apresenta o comportamento dos objetos e sua interao em uma escala de tempo, focalizando as condies que mudam no decorrer desse perodo. um modo alternativo de mostrar uma fuso dos diagramas de sequncia e de estado, apresentando o estado dos objetos em relao ao tempo e as mensagens que modificam esse estado, usando para isso mtrica de tempo na linha de vida. Pode ser til em aplicaes de tempo real (just in time).

17

13. DIAGRAMA DE INTERATIVIDADE: a fuso do diagrama de atividades e sequncia. Ele permite que fragmentos das interaes sejam facilmente combinados aos pontos e fluxos de deciso. Nele, sequncias formam um fluxo de atividades, mostrando como elas trabalham em uma sequncia de eventos.

18

19