Difference between revisions of "Software Engineering"
| Line 13: | Line 13: | ||
* Acegi is an authentication framework based on Spring. [http://www.javaworld.com/javaworld/jw-10-2007/jw-10-acegi2.html Acegi Security in one hour] seems like a good introduction. | * Acegi is an authentication framework based on Spring. [http://www.javaworld.com/javaworld/jw-10-2007/jw-10-acegi2.html Acegi Security in one hour] seems like a good introduction. | ||
| + | |||
| + | == Notes == | ||
| + | |||
| + | '''Agility''' really is a consequence of adequate modelling. For a system that provides behaviour without internally modelling the problem domain (aka Universe of Discourse etc.), accommodating a change of requirements will likely result in large scale changes in design and implementation. In contrast, if the system is based on a detailed and highly adequate model, the extent of changes in design and implementation caused by a requirements change will correspond closely to the extent of the requirement change itself. Thus, small changes in requirements can be accommodated in an agile manner. | ||
| + | |||
| + | '''Reusability''' really reflects the adequacy of a model independently of the purpose (i.e. independently of the current set of requirements). | ||
| + | |||
| + | The real use of '''prototoypes''' is that the software developers get to engage with the problem domain in a symbolic manner. It is an added benefit that prototypes provide opportunity for clients (or other non-developer stakeholders) to get to see the developing system, but (contrary to a somewhat popular view), this is not the main benefit. | ||
Revision as of 01:46, 2 July 2009
Building Software
- GNU autoconf, automake, and libtool, by Gary V. Vaughan, Ben Elliston, Tom Tromey and Ian Lance Taylor
Web Technologies
Authentication
- Acegi is an authentication framework based on Spring. Acegi Security in one hour seems like a good introduction.
Notes
Agility really is a consequence of adequate modelling. For a system that provides behaviour without internally modelling the problem domain (aka Universe of Discourse etc.), accommodating a change of requirements will likely result in large scale changes in design and implementation. In contrast, if the system is based on a detailed and highly adequate model, the extent of changes in design and implementation caused by a requirements change will correspond closely to the extent of the requirement change itself. Thus, small changes in requirements can be accommodated in an agile manner.
Reusability really reflects the adequacy of a model independently of the purpose (i.e. independently of the current set of requirements).
The real use of prototoypes is that the software developers get to engage with the problem domain in a symbolic manner. It is an added benefit that prototypes provide opportunity for clients (or other non-developer stakeholders) to get to see the developing system, but (contrary to a somewhat popular view), this is not the main benefit.
