Gerenciamento e Desenvolvimento de Software
(Aula 4)
Bacharelado em Sistemas de Informa¸c˜ao
Leonardo Medeiros
Instituto Federal de Alagoas
Roteiro
1 RUP
Rational Unified Process Pap´eis Artefatos e Atividades 2 Fases Inicia¸c˜ao e Elabora¸c˜ao Constru¸c˜ao e Transi¸c˜ao 3 Instancia¸c˜ao RUP
4 An´alise e Projeto de Sistemas
Modelagem de Neg´ocio
5 Requisitos
Tipos de Requisitos Problemas dos Requisitos
6 Documenta¸c˜ao
Documento de Requisitos Estrutura do Documento Escrevendo
Rational Unified Process
Rational Unified Process
O Rational Unified Process (tamb´em chamado de processo RUP) ´e
um processo de engenharia de software. Ele oferece uma abordagem baseada em disciplinas para atribuir tarefas e
responsabilidades dentro de uma organiza¸c˜ao de desenvolvimento.
Sua meta ´e garantir a produ¸c˜ao de software de alta qualidade que
atenda `as necessidades dos usu´arios dentro de um cronograma e de
Rational Unified Process
Dimens˜
oes do RUP
O RUP tem duas dimens˜oes:
O eixo horizontal representa o tempo e mostra os aspectos
do ciclo de vida do processo `a medida que se desenvolve
O eixo vertical representa as disciplinas, que agrupam as atividades de maneira l´ogica, por natureza.
Rational Unified Process
Rational Unified Process
Pap´eis
RUP - Pap´
eis
Normalmente os pap´eis s˜ao desempenhados por uma pessoa
ou um grupo de pessoas que trabalham juntas em equipe. Os pap´eis n˜ao s˜ao pessoas; pelo contr´ario, eles descrevem
como as pessoas se comportam no neg´ocio e quais s˜ao as
responsabilidades que elas tˆem.
Os pap´eis tˆem um conjunto de atividades coerentes por eles executadas.
Pap´eis
Pap´
eis do RUP
Analista Arquiteto de Software Eng. De Software Testador Gerente Outros 1 Designer Gr´afico 2 Administrador do Sistema 3 etc.
Artefatos e Atividades
RUP
Atividades
As atividades est˜ao fortemente relacionadas aos artefatos.
Os artefatos fornecem a entrada e a sa´ıda para as atividades e o mecanismo pelo qual as informa¸c˜oes s˜ao transmitidas entre as atividades.
Artefatos e Atividades
RUP
Artefatos
Artefatos s˜ao produtos de trabalho finais ou intermedi´arios
produzidos e usados durante os projetos. Os artefatos s˜ao usados
para capturar e transmitir informa¸c˜oes do projeto.
Um artefato pode ser:
Documento de Requisitos Modelo de Casos de Uso Componente ou subsistema
Inicia¸c˜ao e Elabora¸c˜ao
Fase de Inicia¸c˜
ao
A meta dominante da fase de inicia¸c˜ao ´e atingir o consenso entre todos os envolvidos sobre os objetivos do ciclo de vida do projeto.
A fase de inicia¸c˜ao tem muita importˆancia principalmente para os esfor¸cos dos projetos novos, nos quais h´a muitos riscos de neg´ocios e de requisitos que precisam ser tratados.
Inicia¸c˜ao e Elabora¸c˜ao
Fase de Inicia¸c˜
ao
Objetivo
Estabelecer o Escopo do Software
Descrever os casos de uso cr´ıticos e principais cen´arios da aplica¸c˜ao
Exibir pelo menos uma op¸c˜ao da arquitetura para um dos
cen´arios apresentados
Estimar custo geral e a programa¸c˜ao do projeto Estimar riscos em potencial
Inicia¸c˜ao e Elabora¸c˜ao
Fase de Elabora¸c˜
ao
A meta da fase de elabora¸c˜ao ´e criar a baseline para a
arquitetura do sistema a fim de fornecer uma base est´avel
para o esfor¸co da fase de constru¸c˜ao.
A arquitetura se desenvolve a partir de um exame dos
requisitos mais significativos (os que possuem grande impacto na arquitetura do sistema) e de uma avalia¸c˜ao de risco. A estabilidade da arquitetura ´e avaliada atrav´es de um ou mais prot´otipos.
Inicia¸c˜ao e Elabora¸c˜ao
Fase de Elabora¸c˜
ao
Objetivos
Assegurar que a arquitetura, os requisitos e os planos sejam est´aveis o suficiente para minimizar o risco na implementa¸c˜ao. Tratar todos os riscos significativos do ponto de vista da arquitetura do projeto.
Estabelecer uma arquitetura da baseline derivada do tratamento dos cen´arios
Produzir um prot´otipo evolutivo dos componentes de
qualidade de produ¸c˜ao
Demonstrar que a arquitetura de baseline suportar´a os
Constru¸c˜ao e Transi¸c˜ao
Fase de Constru¸c˜
ao
A fase de constru¸c˜ao ´e de certa forma um processo de manufatura, em que a ˆenfase est´a no gerenciamento de recursos e controle de opera¸c˜oes para otimizar custos, programa¸c˜oes e qualidade.
A meta da fase de constru¸c˜ao ´e esclarecer os requisitos restantes e concluir o desenvolvimento do sistema com base na arquitetura da baseline.
Constru¸c˜ao e Transi¸c˜ao
Fase de Constru¸c˜
ao
Objetivos
Minimizar os custos de desenvolvimento, otimizando recursos e evitando retrabalho desnecess´arios.
Atingir a qualidade adequada com rapidez e eficiˆencia. Atingir as vers˜oes ´uteis (alfa, beta e outros releases de teste) com rapidez e eficiˆencia.
Concluir a an´alise, o design, o desenvolvimento e o teste de todas as funcionalidades necess´arias.
Desenvolver de modo iterativo e incremental um produto completo.
Atingir um certo paralelismo entre o trabalho das equipes de desenvolvimento.
Constru¸c˜ao e Transi¸c˜ao
Fase de Transi¸c˜
ao
A Fase de Transi¸c˜ao entra quando uma baseline estiver desenvolvida o suficiente para ser implantada no dom´ınio do
usu´ario final. Isso normalmente requer que algum subconjunto
us´avel do sistema tenha sido conclu´ıdo.
O foco da Fase de Transi¸c˜ao ´e assegurar que o software esteja dispon´ıvel para seus usu´arios finais. A Fase de Transi¸c˜ao pode atravessar v´arias itera¸c˜oes e inclui testar o produto em prepara¸c˜ao
Constru¸c˜ao e Transi¸c˜ao
Fase de Transi¸c˜
ao
Objetivos
teste beta para validar o novo sistema em confronto com as expectativas do usu´ario.
convers˜ao de bancos de dados operacionais.
engenharia voltada para implanta¸c˜ao, como prepara¸c˜ao, empacotamento e produ¸c˜ao.
atividades de ajuste, como corre¸c˜ao de erros, melhoria no desempenho e na usabilidade.
avalia¸c˜ao das baselines de implanta¸c˜ao tendo como base a vis˜ao completa e os crit´erios de aceita¸c˜ao para o produto obten¸c˜ao do consentimento dos envolvidos.
Instancia¸c˜
ao do RUP
O RUP ´e uma metodologia de desenvolvimento
O importante ´e aplicar a metodologia para atender a nossa
necessidade
Logo o RUP ´e instanciado em um processo de
desenvolvimento seguido pelas institui¸c˜oes Ex: https://ok.dev.java.net/okprocess-pt.xml
An´
alise e Projeto de Sistemas
An´alise de sistemas ´e a atividade que tem como finalidade a realiza¸c˜ao de estudos de processos a fim de encontrar o melhor caminho racional para que a informa¸c˜ao possa ser processada. Os analistas de sistemas estudam os diversos sistemas existentes entre
Disciplinas – Abordadas na An´
alise e Projeto de Sistemas
(APS)
Modelagem de Neg´ocio
Requisitos An´alise e Design
Modelagem de Neg´ocio
Modelagem de Neg´
ocio
Nessa disciplina n˜ao iremos aprofundar bastante. N˜ao ´e objetivo do curso.
Por´em percebam que vocˆes como Desenvolvedores de Web 2.0
vocˆes tˆem que dominar a modelagem do neg´ocio. Para poder
desenvolver solu¸c˜oes adequadas ao ambiente.
Iremos abordar as tarefas principais para termos no¸c˜ao dos artefatos de sa´ıda e sua importˆancia na fase seguinte REQUISITOS.
Modelagem de Neg´ocio
Modelagem de Neg´
ocio
Entender a estrutura e a dinˆamica da organiza¸c˜ao
Entender os problemas atuais da organiza¸c˜ao-alvo e identificar as possibilidades de melhoria
Assegurar que os clientes, usu´arios e desenvolvedores tenham
um entendimento comum da organiza¸c˜ao
Derivar os requisitos de sistema necess´arios para sustentar a organiza¸c˜ao-alvo
Modelagem de Neg´ocio
Modelagem de Neg´
ocio
Artefatos de Sa´ıda
Especifica¸c˜ao Suplementar de Neg´ocios Gloss´ario
Rela¸c˜ao da Modelagem de Neg´ocio com demais disciplinas
A disciplina Requisitos utiliza modelos de neg´ocios como um importante subs´ıdio para entender os requisitos do sistema. A disciplina An´alise e Design utiliza entidades de neg´ocios como subs´ıdio para identificar classes de entidade no modelo de design.
Modelagem de Neg´ocio
Modelagem de Neg´ocio
Modelagem de Neg´
ocio
Requisitos
Engenharia de Requisitos
A Engenharia de Requisitos estabelece o processo de defini¸c˜ao de Requisitos no qual o que deve ser produzido ´e ”elicitado*”, modelado e analisado.
*
N˜ao existe essa palavra em portuguˆes o correto seria elucidado, por´em ´e muito utilizado em Inform´atica
RUP Fases Instancia¸c˜ao RUP An´alise e Projeto de Sistemas Requisitos Documenta¸c˜ao
Pergunta
O que ´e um Requisito?
Um requisito tanto pode ser uma declara¸c˜ao abstrata de alto n´ıvel de um servi¸co, como uma restri¸c˜ao do sistema ou ainda uma especifica¸c˜ao funcional detalhada de alguma rotina.
Pergunta
O que ´e um Requisito?
Resposta
Um requisito tanto pode ser uma declara¸c˜ao abstrata de alto n´ıvel de um servi¸co, como uma restri¸c˜ao do sistema ou ainda uma especifica¸c˜ao funcional detalhada de alguma rotina.
Requisito x Especifica¸c˜
ao
Requisito: condi¸c˜ao necess´aria para a obten¸c˜ao de certo objetivo, ou para o preenchimento de certo objetivo. Especifica¸c˜ao: descri¸c˜ao detalhada/minuciosa das
caracter´ısticas que um material, obra, ou um servi¸co dever˜ao apresentar.
Portanto
Ex. de Requisitos do sistema
Definem o que ´e solicitado ao sistema fazer e com quais
limita¸c˜oes ele ´e requisitado a operar. Ex.:
1 O sistema deve manter registro de todos os materiais da
biblioteca incluindo livros, s´eries, jornais e revistas, fitas de v´ıdeo e ´audio, relat´orios, cole¸c˜oes de transparˆencias, discos de computadores, e CD-ROMs.
2 O sistema deve permitir os usu´arios pesquisarem um item
atrav´es do t´ıtulo, autor ou ISBN.
3 A interface de usu´ario do sistema deve ser implementada
Tipos de Requisitos
Tipos de requisitos
De modo geral temos:Requisitos Funcionais que definem parte da funcionalidade do sistema.
Requisitos N˜ao Funcionais que dizem respeito a restri¸c˜oes,
aspectos de desempenho, interfaces com o usu´ario,
confiabilidade, seguran¸ca, mantenabilidade, portabilidade, padr˜oes
Requisitos Organizacionais que dizem respeito `as metas da
empresa, suas pol´ıticas estrat´egicas adotadas, os empregados da empresa com seus respectivos objetivos; enfim toda a estrutura da organiza¸c˜ao.
Tipos de Requisitos
Requisitos Funcionais (RF)
Descreve funcionalidade e servi¸cos do sistema Depende do:
1 Tipo do software 2 Usu´arios esperados
Tipos de Requisitos
Exemplos de RF
[RF001] Usu´ario pode pesquisar todo ou um sub-conjunto do
banco de dados
[RF002] Sistema deve oferecer visualizadores apropriados
para o usu´ario ler documentos armazenados
[RF003] Todos os documentos devem ser pass´ıveis de impress˜ao
Tipos de Requisitos
Requisitos N˜
ao-Funcionais (RNF)
Definem propriedades e restri¸c˜oes do sistema (tempo, espa¸co, etc)
Requisitos de processo tamb´em podem especificar o uso de
determinadas linguagens de programa¸c˜ao, m´etodo de
desenvolvimento
Requisitos n˜ao-funcionais podem ser mais cr´ıticos que requisitos funcionais. N˜ao satisfaz, sistema in´util. Requisitos de Qualidade: Usabilidade, manutenabilidade, compatibilidade, etc.
Tipos de Requisitos
Exemplos de RNF
Requisitos do Produto: o produto deve comportar-se de forma particular (velocidade de execu¸c˜ao, confiabilidade, etc.)
RNF001 Consultas baseadas em c´odigo de barras devem ser conclu´ıda em at´e 5 segundos
Requisitos Organizacionais: conseq¨uˆencia de procedimentos e pol´ıticas da organiza¸c˜ao (padr˜oes de processo, diretrizes, etc.)
RNF002 Todos os documentos entregues devem seguir o padr˜ao de relat´orios XYZ-00
Problemas dos Requisitos
Principais Problemas dos Requisitos
Os requisitos n˜ao refletirem as reais necessidades dos clientes do sistema.
Os requisitos serem inconsistentes e/ou incompletos.
O custo alto para se fazer mudan¸cas de requisitos depois de
terem sido acordados.
A existˆencia de mal entendidos entre clientes, analistas e os
engenheiros de software que desenvolvem ou mantˆem o
Documento de Requisitos
Documento de Requisitos
´
E um documento formal usado para comunicar os requisitos aos clientes, engenheiros e gerentes.
O documento de requisitos descreve:
1 Os servi¸cos e fun¸c˜oes que o sistema deve prover; 2 As limita¸c˜oes sobre as quais o sistema deve operar; 3 Propriedades gerais do sistema, isto ´e limita¸c˜oes nas
propriedades emergentes;
4 Defini¸c˜oes de outros sistemas com o qual o sistema deve se
Documento de Requisitos
Usu´
arios do Documento de Requisitos
Clientes do Sistema: Especificam os requisitos e os lˆeem
para checar se eles satisfazem suas necessidades.
Gerentes de Projeto: Usam os documentos de requisitos para planejarem uma proposta para o sistema e o processo de desenvolvimento do sistema.
Desenvolvedores (Arquitetos e Eng. De Software): Usam os requisitos para entenderem o sistema em constru¸c˜ao. Engenheiros de Teste: Usam os requisitos para desenvolverem testes de valida¸c˜ao do sistema.
Estrutura do Documento
A estrutura do documento de requisitos
Padr˜ao IEEE/ANSI 830-1993 uma estrutura para o
documento de requisitos Introdu¸c˜ao
1 Prop´osito do documento de Requisitos 2 Escopo do produto
3 Defini¸c˜oes, acrˆonimos e abrevia¸c˜oes 4 Referencias
Estrutura do Documento
Adaptando um padr˜
ao
O padr˜ao do IEEE ´e gen´erico e pretende ser aplicado em uma variada gama de documentos de requisitos.
Em geral, nem todas as partes do documento s˜ao necess´arias
para todos os documentos de requisitos.
Cada organiza¸c˜ao dever´a adaptar o padr˜ao de acordo com o tipo de sistema que desenvolve.
Considere uma companhia (XYZ) que desenvolve equipamentos cient´ıficos.
Estrutura do Documento
Uso de Templates
AS f´abricas de software em geral possuem TEMPLATES de
Documentos de Requisitos a serem seguidos pelos analistas. O uso de templates permite:
1 Padroniza¸c˜ao da documenta¸c˜ao
2 Diversos analistas tendem a documentar da mesma forma o
que auxilia no entendimento do artefato por parte dos desenvolvedores.
Ver Arquivo
Escrevendo
Escrevendo Requisitos
Requisitos s˜ao geralmente escritos como textos em linguagem
natural complementados por diagramas e equa¸c˜oes.
Problemas com os requisitos
1 Uso de cl´ausulas condicionais complexas que podem confundir; 2 Terminologia inconsistente;
3 Os escritores assumem que os leitores possuem conhecimento
Escrevendo
Essencial da Escrita
Requisitos s˜ao lidos mais freq¨uentemente do que s˜ao escritos. Vocˆe dever´a investir tempo lendo e entendendo os requisitos.
N˜ao assuma que todos os leitores dos requisitos tenham o
mesmo background e usem a mesma terminologia sua.
Permita tempo para revis˜ao e refeita do documento de
Escrevendo
Escrevendo diretrizes
Defina templates (modelos) padr˜oes para descri¸c˜ao de requisitos;
Use a linguagem de forma simples, consistente e concisa; Use diagramas de forma apropriada;
Complemente a linguagem natural com outras descri¸c˜oes de
requisitos;
Escrevendo
Pontos Principais
Requisitos definem o que o sistema deve prover e define os limites do sistema;
Problemas nos requisitos causam a entrega tardia dos sistemas e solicita¸c˜oes de mudan¸cas depois que o sistema estiver em uso;
Engenharia de requisitos diz respeito a elicita¸c˜ao, an´alise e documenta¸c˜ao dos requisitos do sistema;
Engenharia de sistemas diz respeito ao sistema como um todo, incluindo hardware, software e processos operacionais; O documento de requisitos ´e a especifica¸c˜ao definitiva para os clientes, engenheiros e gerentes;
Bibliografia (1/2)
I. Sommerville.
Engenharia de Software.
Pearson, 2009.
E. Bezzerra.
Princ´ıpios de An´alise e Projeto de Sistemas com UML.
