alocar recursos específicos para o desenvolvimento de diferentes versões do sistema.

calcular as funcionalidades do sistema, incluindo cálculos de pontos de função.

identificar uma alteração específica efetuada em um código fonte.

controlar as versões dos diversos softwares adquiridos pela empresa.

estimar o custo e tempo de desenvolvimento de uma versão específica de um sistema.

análise e mudança de tecnologia.

negócios e concorrência de produtos.

projeto e alta rotatividade de pessoal.

produto e mudança frequente de requisitos.

desenvolvimento e indisponibilidade de hardware.

o conjunto de diagramas que trata dos aspectos relacionados com as classes, objetos e os relacionamentos do sistema e o conjunto de diagramas que aborda aspectos do estado de funcionamento das aplicações, como o diagrama de máquina de estados e o diagrama de interação.

diagramas voltados para a elaboração de programas que usam classes associadas ao conceito de herança e polimorfismo e diagramas voltados para a elaboração de programas que usam classes que usufruem dos conceitos de interface e componente.

o grupo de diagramas que trata de modelar o comportamento do sistema, como o diagrama de classes e o diagrama de pacotes e o grupo de diagramas que trata da estrutura do sistema, como o diagrama de caso de uso e o diagrama de atividades.

os diagramas estruturais, que apresentam os níveis de implementação e como as partes do sistema se relacionam, e os diagramas comportamentais, os quais apresentam o comportamento dinâmico dos objetos do sistema, mostrando as mudanças no tempo, dentre os quais está o diagrama de caso de uso.

uma agregação de diagramas para desenvolver aplicações que não envolvem o uso de classes e objetos, como o diagrama de caso de uso e o diagrama de componentes e outra agregação de diagramas que são aplicados diretamente no modelo de desenvolvimento orientado a objetos.

Ambos os diagramas representam partes do sistema desenvolvido com base na análise estruturada. Um dos diagramas representa a relação entre os processos existentes no sistema em uma única camada de abstração. O outro diagrama apresenta a relação entre os dados do sistema, apoiando o desenvolvimento de bancos de dados relacionais que podem ser implementados em um Sistema de Gerenciamento de Banco de Dados.

O diagrama com o nível maior de especificação, conhecido por diagrama de contexto, apresenta uma visão detalhada das entradas e saídas de dados, os processos que tratam os dados originados das entidades externas e armazenam as saídas nos depósitos de dados. O outro diagrama apresenta uma abstração do relacionamento entre os dados armazenados nas entidades externas e nos depósitos de dados, sendo esta uma visão macro do diagrama de contexto.

O primeiro diagrama, com o maior nível de abstração, conhecido por diagrama de contexto, contém a representação macro do sistema com as entidades externas, depósitos de dados e o processo do sistema com os fluxos de dados. O outro diagrama apresenta os subprocessos internos ao processo do sistema, com os respectivos fluxos de dados, respeitando as ligações entre as entidades externas e depósito de dados modelados no diagrama de contexto.

Os diagramas desenvolvidos seguem a abordagem dos diagramas estruturais da UML, a qual propõe o uso do DFD para ilustrar os processos existentes, os fluxos de dados do sistema, as entidades externas e os depósitos de dados. O diagrama de contexto contém um único processo e os fluxos macros. O segundo diagrama apresenta os diagramas derivados do processo principal.

Estes diagramas são baseados na análise estruturada de sistemas e ambos modelam as entidades externas, depósito de dados e os relacionamentos entre as entidades com a definição das cardinalidades, apoiando o desenvolvimento de um banco de dados relacional. O DFD compõe o modelo conceitual, servindo de apoio às próximas etapas de concepção de um banco de dados, tal como o modelo lógico e o modelo físico.

grupos de procedimentos os quais são representados por um diagrama de blocos para ilustrar os relacionamentos entre artefatos de um software.

um conjunto de tarefas representadas por ícones e interligadas por símbolos de fluxograma para facilitar o entendimento de um processo de negócio.

uma representação textual do grupo de tarefas que compõem um processo para a tomada de decisões por membros de uma organização.

classes de negócio interligadas por notações de relacionamento, tais como associações ou generalizações, a fim de facilitar a compreensão dos requisitos de um software.

objetos de software que ilustram a instância de classes de negócio, organizadas através da notação de pacote, sendo uma maneira de visualizar os processos de negócio que incidem sobre estes objetos.

apresenta um conjunto de recomendações baseadas na ISO/IEC 12207 e na ISO/IEC 15504, específico para empresas de grande porte.

é composto por 5 níveis de maturidade, sendo estes níveis classificados em “Inicial”, “Gerenciado”, “Definido”, “Gerenciado Quantitativamente” e “Em Otimização”.

possui compatibilidade com o modelo CMMI-DEV, visto que o modelo MPS.BR possui o mesmo conjunto de áreas de processo e a mesma organização de métricas de capacidades para obtenção de maturidade.

tem o apoio do Ministério da Ciência e Tecnologia, FINEP e Banco Interamericano de Desenvolvimento, possuindo um custo de certificação semelhante ao CMMI, bastante adequado à realidade brasileira.

é baseado nas normas ISO/IEC 12207 e ISO/IEC 15504, promovendo a melhoria dos processos de desenvolvimento de software brasileiro, em especial, para empresas de pequeno e médio porte, compatível com o modelo CMMI-DEV.

acompanha e monitora ações durante a verificação do software, sendo este o processo que garante o atendimento aos requisitos informados pelo usuário final.

possui autonomia para realizar alterações no projeto para garantir que o software seja bem construído e atenda as necessidades da equipe de desenvolvimento.

mantém atualizados os requisitos junto ao usuário final e a equipe de desenvolvimento, a fim de obter sucesso no processo de homologação do software, atendendo as necessidades e expectativas.

classifica os requisitos em diferentes tipos, sendo os do tipo funcional relacionados com o custo e confiabilidade do software e os do tipo não-funcional relacionados com os casos de uso.

obtém o comprometimento dos integrantes da equipe de desenvolvimento de software para o cumprimento do processo de software.

modelo espiral.

ciclo de vida em cascata.

modelo de desenvolvimento evolucionário (prototipação).

modelo de desenvolvimento ágil.

método de desenvolvimento Cleanroom (Sala Limpa).

é uma área da computação que visa abordar de modo sistemático as questões técnicas e não técnicas no projeto, implantação, operação e manutenção no desenvolvimento de um software.

consiste em uma disciplina da computação que aborda assuntos relacionados a técnicas para a otimização de algoritmos e elaboração de ambientes de desenvolvimento.

trata-se de um ramo da TI que discute os aspectos técnicos e empíricos nos processos de desenvolvimento de sistemas, tal como a definição de artefatos para a modelagem ágil.

envolve um conjunto de itens que abordam os aspectos de análise de mercado, concepção e projeto de software, sendo independente da engenharia de um sistema.

agrupa as melhores práticas para o concepção, projeto, operação e manutenção de artefatos que suportam a execução de programas de computador, tais como as técnicas de armazenamento e as estruturas em memória principal.

integridade e privacidade.

confidencialidade e disponibilidade.

acuidade e auditabilidade.

versatilidade e manutenibilidade.

irreversibilidade e retratabilidade.