Em resumo, o J2EE é uma ferramenta poderosa para desenvolver aplicativos empresariais

robustos e escaláveis, aproveitando componentes reutilizáveis e padrões de segurança avançados.

Pressões de Negócio e Fases de Desenvolvimento de Software são conceitos distintos, mas

ambos desempenham papéis cruciais em organizações e projetos de TI

Em resumo, as pressões de negócio são contextuais e externas à organização, enquanto as fases

de desenvolvimento de software são processos internos que transformam requisitos em software
funcional.
Os "artefatos de software" referem-se a quaisquer produtos tangíveis ou
intangíveis criados durante o processo de desenvolvimento de software. Esses
artefatos são criados para ajudar no planejamento, projeto, implementação,
teste e manutenção de sistemas de software.
DEFINIÇÃO E BREVE DESCRÇÃO DO TERMO J2EE

Java2 Platform Enterprise Edition (J2EE) é uma tecnologia que torna possível projetar,
desenvolver, empacotar e implantar aplicações empresariais baseadas em compontentes. A
plataforma oferece um modelo multi-camada distribuido com a possibilidade de reutilização de
componentes, transferência de dados feita em XML, um modelo de segurança unificado e um
flexível controle transacional.

O fato de ser uma especificação aberta, possibilita que aplicações sejam desenvolvidas sem
vínculo com nenhum fornecedor específico. Para explicitar melhor, voce pode criar um único
arquivo para toda uma aplicação. Ao implantá-lo em um application server este se encarrega de
desempacotá-lo instanciar um aplicativo web e as entidades de sua aplicação.

O desenvolvimento de aplicações J2EE é realizado por diversos elementos cada uma com uma
função (papel) específico:
• Desenvolve componentes que farão parte de aplicações (incluindo descrição das interfaces
home e remote e do descritor de implantação) – Deployer (Instalador/Implantador):
• Instala e configura a aplicação em um determinado ambiente
• Gera classes para permitir o container gerenciar componentes EJB – Administrador do Sistema
• Mantém a infra-estrutura de hardware e software do sistema – Fornecedor do Servidor EJB
• Oferece ferramentas e as APIs dos serviços
Caracteristicas:

Especificação aberta: Permite o desenvolvimento de aplicativos sem depender de fornecedores

específicos.

Implantação em Application Servers: Você pode criar um único arquivo para toda a aplicação
e implantá-lo em um servidor de aplicativos. O servidor cuida de desempacotar e instanciar o
aplicativo.

Suporte a EJBs (Enterprise JavaBeans): O J2EE permite configurar EJBs usando a JNDI
(Java Naming and Directory Interface). Esses serviços podem ser compartilhados por várias
aplicações.

Histórico:

Anteriormente conhecido como Java 2 Platform, Enterprise Edition (J2EE), o nome foi alterado
para Java Platform, Enterprise Edition (Java EE) na versão 5.Versões anteriores incluem J2EE
1.2, 1.3 e 1.4, enquanto a versão atual é o Java EE 8.
 Pressões de Negócio:
Refere-se às forças e influências que afetam uma organização, suas operações e estratégias.
As pressões de negócio podem moldar decisões estratégicas, prioridades e investimentos da
organização

Cracteristica

 Competitividade: A necessidade de se destacar em um mercado competitivo.

 Regulamentações: Conformidade com leis e regulamentos.
 Expectativas dos Clientes: Atender às demandas e expectativas dos clientes.
 Evolução Tecnológica: Adaptação às mudanças tecnológicas.
 Econômicas: Flutuações econômicas e pressões financeiras..

Fases de Desenvolvimento de Software:

Representam etapas sequenciais no ciclo de vida do desenvolvimento de software. As fases de
desenvolvimento garantem que o software seja criado de forma estruturada e eficiente.As
pressões de negócio influenciam as decisões tomadas em cada fase do desenvolvimento de
software.Por exemplo, a pressão competitiva pode afetar o planejamento, enquanto
regulamentações podem impactar o design e a implementação.

Fases:

 Planejamento: Definir escopo, objetivos, requisitos e recursos.

 Análise de Requisitos: Compreender as necessidades dos usuários e especificações do sistema.
 Projeto: Criar a estrutura geral do sistema e o design da interface.
 Implementação: Codificar o software.
 Teste: Verificar se o software atende aos requisitos.
 Implantação: Colocar o software em produção.
 Manutenção: Corrigir erros e atualizar o software.

Artefactos de software
O termo artefato em conexão com o desenvolvimento de software é amplamente associado com
métodos ou processos de desenvolvimento específicos, por exemplo, o Processo Unificado. Este
uso do termo pode ter sido originado com esses métodos.
Autores como Orlikowski e Iacono (2001, p.19)[1] definem artefato como "pacotes de
propriedades materiais e culturais empacotados em alguma forma socialmente reconhecível
como hardware e / ou software". Por outro lado, autores como Curry, Marshall e Kawalek (2014)
[2]
comentam que é cada vez mais complexo definir o limite entre os artefatos e funções
tecnológicas dado a evolução da modalidade prática do artefato em si, o qual passa de um
simples substituto do trabalho para um atuador no processamento de informação.
Alguns exemplos comuns de artefatos de software incluem:
-Documentação: Isso pode incluir documentos de requisitos, especificações de design, manuais
de usuário, manuais de instalação, planos de teste, entre outros.
-Diagramas e modelos: Diagramas UML (Unified Modeling Language), fluxogramas,
diagramas de casos de uso, diagramas de classes, diagramas de sequência, e outros modelos
utilizados para representar o sistema e suas interações.
-Código-fonte: Os arquivos de código-fonte escritos em diversas linguagens de programação
são os principais artefatos produzidos durante o desenvolvimento de software.
-Executáveis e Binários: Os programas executáveis ou binários gerados a partir do código-
fonte, que são as versões prontas para uso do software.
-Bancos de Dados: Esquemas de banco de dados, scripts de criação de banco de dados, scripts
de migração de dados e outros artefatos relacionados à estrutura e manipulação de dados.
-Artefatos de Teste: Casos de teste, scripts de automação de teste, relatórios de testes e outros
artefatos relacionados à atividade de teste de software.
-Protótipos e Wireframes: Protótipos de interface de usuário, wireframes e mockups que
representam visualmente a aparência e a interação do software.
-Configuração e Ambiente: Arquivos de configuração do sistema, scripts de implantação,
ambientes de desenvolvimento e configuração de servidor.

Esses documentos (e muitos outros) são necessários para que as pessoas envolvidas no
desenvolvimento de software tenham uma base de informação em comum para se comunicar a
respeito do software. Esses documentos são chamados, coletivamente, de artefatos de software.
Dependendo da metodologia de desenvolvimento (se alguma for usada), os tipos de artefato
variam.
É possível, em tese, não ter artefatos, exceto pelo código-fonte, mas isso pode tornar qualquer
tarefa de manutenção do programa mais difícil. Para um desenvolvedor descobrir o que faz cada
parte do sistema, seria preciso fazer engenharia reversa do programa. Com isso, torna-se
desejável consultar um diagrama ou documentação, facilitar o entendimento de cada parte
integrante de um sistema (ou como cada parte deveria funcionar).

Esses artefatos são essenciais para o desenvolvimento e manutenção bem-sucedidos de software,

pois fornecem uma base documentada e estruturada para o trabalho dos desenvolvedores,
testadores, gerentes de projeto e outros envolvidos no processo de desenvolvimento de software.
Referecias Bibliograficas

Perrone, Paul J.; Chaganti, Krishna (2003). J2EE Developer's Handbook. Indianapolis,
Indiana: Sam's Publishing. ISBN 0-672-32348-6

Bodoff, Stephanie (2004). The J2EE Tutorial. Boston: Addison-Wesley. ISBN 0-321-24575-X

«J2EE web server or container». www.service-architecture.com. Consultado em 27 de abril de

2012

Butler, Ricky W. «What is Formal Methods?» (em inglês). Consultado em 26 março de 2015

↑ Holloway, C. Michael. «Why Engineers Should Consider Formal Methods» (PDF). 16th
Digital Avionics Systems Conference (27-30 outubro de 1997) (em inglês). Consultado em 26 de
março de 2015. Arquivado do original (PDF) em 16 de novembro de 2006

Orlikowski, Wanda J.; Iacono, C. Suzanne (junho de 2001). «Research Commentary:

Desperately Seeking the "IT" in IT Research—A Call to Theorizing the IT Artifact». Information
Systems Research (2): 121–134. ISSN 1047-7047. doi:10.1287/isre.12.2.121.9700. Consultado
em 10 de abril de 2021

↑ Curry, Michael; Marshall, Byron; Kawalek, Peter (agosto de 2014). «IT artifact bias: How
exogenous predilections influence organizational information system paradigms». International
Journal of Information Management (4): 427–436. ISSN 0268-
4012. doi:10.1016/j.ijinfomgt.2014.02.005. Consultado em 10 de abril de 2021