Pico Container "Good Citizen" rules
http://docs.codehaus.org/display/PICO/Good+Citizen
Wednesday, March 3, 2010
Architecture-Driven Design
Dave Thomas' talk "Lean and Agile in the Large" mentioned Architecture-Driven Design....
http://www.selfishprogramming.com/2007/10/
Jim Coplien on Scrum Architecture: Jim started by highlighting that use cases describe what a system does and architecture represents what that system is. A common problem on Agile projects is that a lot of teams become unstuck during the third sprint because there is no architecture. After all, architecture is what enables developers to work together. Jim therefore recommended we assert what we know on an architecture in order to provide a high level design, taking no more than three days, made up of abstract base classes and domain dictionaries (two sides of A4 per domain). Jim went on to say that TDD (Test-Driven Development) does not produce (good) architectures. That architectures cannot be derived from unit tests. That we should adopt architecture-driven design instead of unit-test-case-driven design. The session hit the sweet spot as a technical Agile session: suitably thought-provoking or controversial depending on how you interpreted his presentation.
http://books.google.com.au/books?id=5uYbmQerI08C&pg=PA91&lpg=PA91&dq=%22architecture+driven+design%22&source=bl&ots=dsKwO7joli&sig=_lOrGO5I4eggLLsJWDEiRVt8dZI&hl=en&ei=RrSOS_quJ8ugkQXe49XoDA&sa=X&oi=book_result&ct=result&resnum=5&ved=0CBEQ6AEwBA#v=onepage&q=%22architecture%20driven%20design%22&f=false
A design that fulfills all functional requirements but fails to meet non-functional ones is not a valid design. Architecture-driven design offers a mature approach to design because it explicitly considers non-functional requirements from the beginning, and not just immediate requirements such as size and performance, but also easy of maintenance, accomodation of projected changes, understandability and so on.
http://www.selfishprogramming.com/2007/10/
Jim Coplien on Scrum Architecture: Jim started by highlighting that use cases describe what a system does and architecture represents what that system is. A common problem on Agile projects is that a lot of teams become unstuck during the third sprint because there is no architecture. After all, architecture is what enables developers to work together. Jim therefore recommended we assert what we know on an architecture in order to provide a high level design, taking no more than three days, made up of abstract base classes and domain dictionaries (two sides of A4 per domain). Jim went on to say that TDD (Test-Driven Development) does not produce (good) architectures. That architectures cannot be derived from unit tests. That we should adopt architecture-driven design instead of unit-test-case-driven design. The session hit the sweet spot as a technical Agile session: suitably thought-provoking or controversial depending on how you interpreted his presentation.
http://books.google.com.au/books?id=5uYbmQerI08C&pg=PA91&lpg=PA91&dq=%22architecture+driven+design%22&source=bl&ots=dsKwO7joli&sig=_lOrGO5I4eggLLsJWDEiRVt8dZI&hl=en&ei=RrSOS_quJ8ugkQXe49XoDA&sa=X&oi=book_result&ct=result&resnum=5&ved=0CBEQ6AEwBA#v=onepage&q=%22architecture%20driven%20design%22&f=false
A design that fulfills all functional requirements but fails to meet non-functional ones is not a valid design. Architecture-driven design offers a mature approach to design because it explicitly considers non-functional requirements from the beginning, and not just immediate requirements such as size and performance, but also easy of maintenance, accomodation of projected changes, understandability and so on.
Agile before Waterfall
From: http://en.wikipedia.org/wiki/Agile_software_development
Gerald M. Weinberg: We were doing incremental development as early as 1957, in Los Angeles, under the direction of Bernie Dimsdale [at IBM’s ServiceBureau Corporation]. He was a colleague of John von Neumann, so perhaps he learned it there, or assumed it as totally natural. I do remember Herb Jacobs (primarily, though we all participated) developing a large simulation for Motorola, where the technique used was, as far as I can tell, ... All of us, as far as I can remember, thought waterfalling of a huge project was rather stupid, or at least ignorant of the realities. I think what the waterfall description did for us was make us realize that we were doing something else, something unnamed except for “software development. quoted in Larman, Craig; Victor R. Basili (June 2003). "Iterative and Incremental Development: A Brief History" (pdf). Computer 36 (6): pp 47–56. doi:. http://www2.umassd.edu/SWPI/xp/articles/r6047.pdf.
Gerald M. Weinberg: We were doing incremental development as early as 1957, in Los Angeles, under the direction of Bernie Dimsdale [at IBM’s ServiceBureau Corporation]. He was a colleague of John von Neumann, so perhaps he learned it there, or assumed it as totally natural. I do remember Herb Jacobs (primarily, though we all participated) developing a large simulation for Motorola, where the technique used was, as far as I can tell, ... All of us, as far as I can remember, thought waterfalling of a huge project was rather stupid, or at least ignorant of the realities. I think what the waterfall description did for us was make us realize that we were doing something else, something unnamed except for “software development. quoted in Larman, Craig; Victor R. Basili (June 2003). "Iterative and Incremental Development: A Brief History" (pdf). Computer 36 (6): pp 47–56. doi:. http://www2.umassd.edu/SWPI/xp/articles/r6047.pdf.
Subscribe to:
Posts (Atom)