However I don't think this is the key point about agile
methods. Lack of documentation is a symptom of two much deeper
differences:
Agile methods are adaptive rather than predictive.
Engineering methods tend to try to plan out a large part of the software
process in great detail for a long span of time, this works well until
things change. So their nature is to resist change. The agile methods,
however, welcome change. They try to be processes that adapt and
thrive on change, even to the point of changing themselves.
Agile methods are people-oriented rather than
process-oriented. The goal of engineering methods is to define a
process that will work well whoever happens to be using it. Agile
methods assert that no process will ever make up the skill of the
development team, so the role of a process is to support the
development team in their work.In the following sections I'll explore these differences in
more detail, so that you can understand what an adaptive and
people-centered process is like, its benefits and drawbacks, and
whether it's something you should use: either as a developer or
customer of software.
Mit Unterstützung des Bundesministeriums für Bildung und Forschung (BMBF) erarbeitet eine gemeinsame Initiative von Universitäten und Unternehmen einen neuartigen Ansatz für den systematischen Aufbau webbasierter Anwendungen. Ziel ist es, Methoden und Technologien für die hocheffiziente Entwicklung komplexer, dynamischer Web-Applikationen bereitzustellen.
Das auf einen Zeitraum von drei Jahren ausgelegte Forschungsvorhaben WISE - Web Information and Service Engineering ist ein Projekt der Initiative „Software Engineering 2006“, mit der das BMBF die technologische Wettbewerbsfähigkeit auf dem Gebiet der Software-Entwicklung erhalten und ausbauen möchte.
"Relying on CVS and Subversion [...] with access controls limited to the select few committers makes it very difficult for those on the fringes to get more involved."
If you have an idea for a new feature in the morning, you can write it and push it to the production servers before lunch. And when you can do that, you have more ideas.
Business process management (BPM) – while also its own independent practice / school of thought – is an application of technology that is served by many products, not the least of which is jBPM. The best definition of BPM that I've found is: "Business Process Management (BPM) is the concept of shepherding work items through a multi-step process. The items are identified and tracked as they move through each step, with either specified people or applications processing the information. The process flow is determined by process logic and the applications (or processes) play virtually no role in determining where the messages are sent.".
Agile Modeling (AM) is a practice-based methodology for effective modeling and documentation of software-based systems. Simply put, Agile Modeling (AM) is a collection of values, principles, and practices for modeling software that can be applied on a software development project in an effective and light-weight manner. As you see in Figure 1 AM is meant to be tailored into other, full-fledged development methodologies such as XP or RUP, enabling you to develop a software process which truly meets your needs. The techniques of AM, in particular Agile Model Driven Development (AMDD), the lifecycle for which is depicted in Figure 2, enable you to scale agile software development to very complex situations.
Description of Phenomenology, the background and associated research methods. Rather easy to understand and helpful for putting research into practice.
Agile Development is one of the big buzzwords of the software development industry. But what exactly is it? Agile Development is a different way of managing software development projects. The key principles, and how Agile Development fundamentally differs from a more traditional Waterfall approach to software development, are as follows:
The concepts
The CodeCount toolset is a collection of tools designed to automate the collection of source code sizing information. The CodeCount toolset spans multiple programming languages and utilizes one of two possible Source Lines of Code (SLOC) definitions, physical or logical.
The CodeCount toolset is provided in source code only, and may be used as is, modified or further distributed subject to certain limitations.
The tools in the collection are supplied in C source code only. You are responsible for compiling and building executable versions.
The Product
The CodeCount toolset is copyright USC Center for Software Engineering but is made available with a Limited Public License which permits the distribution of the modifications you make provided you return a copy to us so we can further enhance the toolset for the benefit of all.
"Online QDA is a set of training support materials which address common problems (both early and advanced) of using Qualitative Data Analysis (QDA) methods and selected Computer Assisted Qualitative Data AnalysiS (CAQDAS) packages"
Crap4j is a Java implementation of the CRAP (Change Risk Analysis and Predictions) software metric – a mildly offensive metric name to help protect you from truly offensive code.
The CRAP metric combines cyclomatic complexity and code coverage from automated tests (e.g. JUnit tests) to help you identify code that might be particularly difficult to understand, test, or maintain – the kind of code that makes developers say: “This is crap!” or, if they are stuck maintaining it, “Oh, crap!”.
The best way to learn more about CRAP and Crap4j is to check the various articles, newsgroups and blogs about them.
the most effective learning situation is one where a small number of apprentices work alongside an even smaller number of journeyman, who are receiving guidance from a master craftsman