The project specification can be defined in word processor format as you would normally. By adding some special items, such as titled bulleted lists and highlighted text items, both a test suite and glossary can be written right into the spec. The Arbiter server will parse these documents and run the tests, reporting the results into the documents themselves. This allows the client to see project process.
AutoPatch was born from the needs of using an agile development process while working on systems that have persistent storage. Without AutoPatch, developers usually can't afford the maintenance headache of their own database, and DBAs are required just to apply changes to all of the various environments a serious development effort requires.
The very application of database changes becomes an inefficient, error-prone, expensive process, all conspiring to discourage any refactoring that touches the model, or being a bottleneck when model changes are made.
AutoPatch solves this problem, completely.
With AutoPatch, an agile development process that requires a database change looks like this:
* Developer alters the model, which requires a change to the database
* Developer possibly consults a DBA, and develops a SQL patch against their personal database that implements the alteration
* Developer commits the patch to source control at the same time as they commit their dependent code
* Other developers' and environments' databases are automatically updated by AutoPatch the next time the new source is run
This represents streamlined environment maintenance, allowing developers to cheaply have their own databases and all databases to stay in synch with massively lower costs and no environment skew.
That's what AutoPatch does.
Clusters with one database? Multiple schemas? Logical migrations, instead of just DDL changes? Need to do something special/custom? Need to distribute your changes commercially? All without paying anything? No problem.
Context Architecture for agile projects has to be described and defined differently. Not all decisions will be made at once, nor will all of them be done whe...
Chariot Solutions is a software development and consulting firm focused on helping clients achieve greater success through the intelligent application of established and emerging technologies. Emphasizing the use of agile architectures based upon open standards, we deliver solutions that allow clients to react more quickly to competitive pressures and market opportunities.
I am fascinated by the art of software development. How do you write great code? How do you document complex architectures? How do you lead teams and projects? How do you create interesting and effective development environments? How do you communicate wi
Dialogue-Driven Development (d3) is an approach to project management that puts client interaction and communication as the highest priority in a successful project. Dialogue-Driven Development encourages: * Mission statements * Goal planning * Prototypin
EasyMock provides Mock Objects for interfaces in JUnit tests by generating them on the fly using Java's proxy mechanism. Due to EasyMock's unique style of recording expectations, most refactorings will not affect the Mock Objects. So EasyMock is a perfect
The Eclipse Process Framework (EPF) aims at producing a customizable software process enginering framework, with exemplary process content and tools, supporting a broad variety of project types and development styles.
Agile Development, in particular, eXtreme Programming (XP), has been gaining a lot of momentum because it can effectively address the problems plaguing software development such as mis-understanding customers' requirements, missing deadlines, over-budget,
As our world continues to evolve, our businesses are finding themselves in a position where they need to evolve too. To that effect, perhaps our software development methods should be reconsidered and rebuilt for this new world.
Extreme Programming (or XP) is a popular software development process that encourages a return to the days of little or no documentation, Design After First Testing, and Constant Refactoring After Programming. Despite its popularity, not everyone thinks X
H. Deters, J. Droste, and K. Schneider. Proceedings of the 27th International Conference on Evaluation and Assessment in Software Engineering, page 329–338. New York, NY, USA, Association for Computing Machinery, (Jun 14, 2023)
E. Damiani, A. Colombo, F. Frati, and C. Bellettini. Agile Processes in Software Engineering and Extreme Programming, volume 4536 of Lecture Notes in Computer Science, Springer Berlin Heidelberg, (2007)
M. Anders, M. Obaidi, B. Paech, and K. Schneider. International Working Conference on Requirements Engineering: Foundation for Software Quality, page 235--250. Springer, (2022)
H. Schrieber, M. Anders, B. Paech, and K. Schneider. Joint Proceedings of REFSQ 2021 Workshops, OpenRE, Poster and Tools Track, and Doctoral Symposium co-located with the 27th International Conference on Requirements Engineering: Foundation for Software Quality (REFSQ 2021), Essen, Germany, April 12, 2021, volume 2857 of CEUR Workshop Proceedings, CEUR-WS.org, (2021)
J. Klünder, O. Karras, and K. Schneider. 2020 IEEE Third International Workshop on Affective Computing in Requirements Engineering (AffectRE), page 1-2. (September 2020)
K. Meyer, M. Schubert, and M. Böttcher. Entwicklung IT-basierter Dienstleistungen – Co-Design von Software und Services mit Serv CASE, page 305-318. Physica-Verlag, (2008)