2005/5/10

     
 

ACDK as Method

artefaktur

| Introduction | Features | History | Comparison | Java Conformance | Library | ACDK DMI | Framework | Method | Standard |


There is not only a strong connection between workpiece and the tool used, but also a close relationship between the instrument and the methods applied Es gibt nicht nur eine enge Verbindung zwischen Werkzeug und Werkzeug, sondern auch eine Verbindung zwischen dem eingesetzten Mitteln und Methoden.


When we first wrote ACDK, we had an idea of what software development would look like. ACDK should be seen as an offer to understand software development in today's work-, project- and product relations.


Content of this chapter:

   Native Programming
   Software development as an engineering performance
   Extreme Programming
   Time to Market
   Project and Product affairs



 Native Programming

Musicians think in terms of scores, architects in terms of elevation plans and programmers in terms of programming language, in order to increase developments.
ACDK supports the developer with a language concept, standards, libraries and tools by bringing together the sight of programmers and project conditions.


 Software development as an engineering performance

Software development is possible as an engineering performance through integrations of standards, methods, and tools in project environments and is integrative administered through methods of project managements.

The project environment consists of:
  • a homogeneous object model
  • components & libraries
  • testing and debug procedures (self-test)
  • document systems for concepts, specification, classes, implementation and modules.
  • configurations, release and vision management
  • task tracking, project management

 Extreme Programming

Approximately 80% of all programming codes are discarded or replaced during the term of a project or product. Traditional approaches of software engineering are trying to reduce this factor. The introverted side of the paradigm of reusable codes that is often forgotten is that of discarded codes. Parts of programs must be discarded without putting the whole system in danger (a minimal invasive intervention).

Programs, which parts have never been discarded or replaced are tested and serviced badly. No one has probably dared to touch the halfway running codes. ACDK makes the process of re-using and discarding codes easier. On one side, it provides a degenerated component model that has a load carrying capacity and on the other side, it offers a project environment to minimize the risk of discarding codes. Even if programs have been through larger changes, they can be tested upon their original and specific function by generating the original code documents and the assigned self- test programs.

 Time to Market

Software is usually developed with a lack of time and employees. A customer wants to develop software products "Time to Market," operation hours in industries are to be reduced and products are to be improved during the production.
This will only be possible by dissolving the classical waterfall model deriving from software development.

ACDK supports a development, where flowing transitions from specification of interfaces to developments of prototypes, implementation and operation hours are possible.

 Project and Product affairs

ACDK places no difference between a project affair and product affair. The advantages from both are combined in a software engineering method.

There are short release cycles possible through a support of project environments, in order to have sights into projects at all times to measure features and qualities of the final outcome.

Normally, there is no difference between a prototype and a product. The project or product can have technical changes through continuing Java- compatibility.

There is a positive effect on software quality and a rising marketability for software development through degenerations of product policies out of project affairs and integrations of pre- made product components in project software.