|Access||Adobe photoshop||Algoritmi||Autocad||Baze de date||C||C sharp|
|Calculatoare||Corel draw||Dot net||Excel||Fox pro||Frontpage||Hardware|
|Php||Power point||Retele calculatoare||Sql||Tutorials||Webdesign||Windows|
|Asp||Autocad||C||Dot net||Excel||Fox pro||Html||Java|
Reaching a Solution
CDEs and Process Automation
IT must now utilize the same automation methods that have been used to integrate other business teams. This includes shifting environments to be more portal-like and creating underlying process, semantic, and analytic facilities to enable team members to work efficiently while still providing the desired controls and measurements. We view this as creating supply chain automation for IT assets. This shift started five years ago with initial efforts to link pieces of the process together, such as models and code, but the main inflection point begins this year and will evolve rapidly during the next five years. These solutions will initially be focused around the development and deployment process and then expand to encompass overall portfolio management and the integration of business with IT. This integration is also critical to the overall success that organizations will find in shifting toward SOA.
A Combination of Tools and Practices
Although tools will provide a boost, they must be combined with best practices. The most productive, efficient teams tend to follow several patterns as outlined by Coplien and others. Attributes such as small numbers (10-12), close proximity, and architects who implement work because of the ability to communicate and retain flow as well as the removal of “translation” loss.
Figure 2 — Roles in Action
Structured processes provide a great deal of formal guidance and documentation. The concept is to drive out defects early in the process (when it is cheap) by being exact. However, two things happen that challenge the success of this idea: projects take long enough that business requirements change between specification and delivery, and users often have a difficult time specifying what is needed until something is actually delivered. Thus, a waterfall might work fine for application maintenance because the requirements are well known; at the same time, it is ill suited to brand-new applications, where the requirements are less exact.
Organizations that want to improve collaboration should attack these social issues first. They must find ways outside the context of projects for IT team members to interact with their business counterparts. Organizations must establish guidelines around the use of instant messaging and spend time training project leaders on running effective meetings. If the organization currently is lacking in process standards or operates at a low Capability Maturity Model Integration (CMMI) level, placing a collaborative process-driven tool might help, but it is more effective to determine and train on an effective process foundation first. This is answering some of the big questions before proceeding to the details.
As organizations shift toward more agile development
methodologies, they are seeing positive benefits in overall productivity and
code quality. However, the tools used by teams are still more suited to
waterfall methods. Each tool is designed for a specific task and with no
underlying integration or meta model. This leads to
process inefficiency and miscommunication. In a traditional cycle, each
By 2007, tool suites will have grown to include
integration for project metrics and portfolio management, enabling
organizations to make business-driven decisions about what projects are
delivering and what projects to undertake. This will be driven both by vendors
building out solutions as well as by the acquisition of existing solution
providers. By 2009, the shape of development environments will have been
dramatically altered to
One of the greatest challenges is leading developers to make changes. As a group, developers tend to be wed to a routine and to chosen toolsets. This is one reason working from the IDE is so
important. If a product seems to be an impediment or creates a break in the flow, it will be rejected. By bringing process into the developer's working environment, less disruption occurs, and by working across a unified system, metrics become easier to gather. This has been illustrated by several early products that have integrated specific select development processes, such as modeling and code, unit testing, and pattern-driven design guidance. Rules can ensure that static analysis has been run and that unit tests have been created and passed before a piece of code is checked in, but this needs to occur without jumping between different systems and writing various configuration scripts. Early-generation tools often expect the developer to spend a lot of time writing tools to bridge the gaps. Workflow will enable projects to follow a process, notifying team members about tasks to complete. Although increasing process steps, these tools will raise productivity by leading to more maintainable systems, and catching errors earlier in development and automation will help keep them from being in the way. This does not mean that developers will be excited for more process, but integration and value will enable quick return on investment.
While IDE vendors will expand the breadth of offerings, there will continue to be a strong market for third-party solutions to fill in the gaps and to provide common tools across platforms. In addition, we expect a wide variety of useful open-source products to continue to emerge. However, differences in schemas and a lack of standards will limit the ability to have a complete unified toolset across all of IT.
Although iterative development practices have been shown
to improve development productivity and customer satisfaction, they are
difficult for organizations to use because of the mismatch with existing tools
and the lack of
Politica de confidentialitate|
Adauga cod HTML in site