Evolving Architecture

One of my former students asked a great question on architecture and architecture reviews. The question, the answer, and some further elaboration by Joe Maranzano, an expert in architecture and architecture reviews follow these short notes.

Establishing a discipline of architecture reviews relatively early in the software development process is a great idea. The paper by Starr and Zimmerman (get it here) “A blueprint for success: Implementing an architectural review system.” www.stqemagazine.com, 2002, is a great introduction to architecture reviews. I will keep you posted on further sources of information on architecture reviews.

Enough background, here's the question, answer, and Maranzano's additional comments.

1. Does any sort of review only occur after the particular task reviewed is completely finished? That is, after the architecture review is done is it still possible to add to or change the architecture .. or should that be avoided?

Of course if the review suggests changes or deficiencies the architecture should be adjusted to accommodate them. Tuning can still be done until design, any changes after that have a ripple effect -- the design has to be changed and code and ... . Bottom line the general architecture should not change after the review but knowledge during the design/development process may cause adjustments. And there are exceptions, if you are using very new technology the architecture may change as you discover how it really works during development. We sometimes refer to that type of project as advanced development, and generally use our top staff on it. I think the key is that the architect (and there only should be one) should shepherd her architecture through development and testing -- so a simple answer is the architect should not change, the architecture may change but this should be done carefully.

Joe added: "You might want to mention that if some portion of the architecture has to change (e.g., due to design discoveries or economic impact of the solution) that a review of that portion of the architecture can and should be done."

Hope you found this interesting and, as always, comments are welcome.

Later.

The NeverEnding Story/Software

In the past ten years I have noticed a new class of software projects emerging. For lack of a better term I call them organic projects, since they take on a life of their own -- they really have no real endpoint and releases, when they occur, are a matter of convenience not a potential endpoint. Often these projects go through continuous release and evolve not only as the understanding of the requirements evolve, but also grow because they create new capabilities, that inspire a new burst of requirements, that create new capabilities, that inspire ... . Data collection and data mining projects fall into this category as do other internal projects that support corporate operations. The web as a whole is an evolving meta project of this class, where requirements evolve through use. Many Open Source projects follow a similar path but often their evolution is inspired by a changing developer and user base. Indeed I see more projects falling into this category as software permeates more of our lives and more individuals have the capability to author and modify software. Another defining attribute of this software is that it normally lasts decades (if not longer since software has only been around for decades!).

These projects are not well accommodated by current Software Engineering models, theory and practice. Agile methods come close, but they do not seem to consider long time scales. Incremental and spiral models, although spawning lots of releases, are workng to an end -- in incremental you prioritize the features and in spiral you do that plus risk assessment. Similarly design, development, testing, maintenance, (name your own) are affected.

So what do you think? Is this a new class of software and do you have other (better) examples of this? Is it worth beginning a thread on this blog that discusses this class of software and thoughts on the software engineering of these evolving systems?

Later.

Requirements Innovation

Has innovation in requirements kept pace with innovation software process, design, analysis or even testing? I do not think so. Sure there is some innovation in requirements elicitation, especially with the use of prototyping, the Delphi method, ... but I see very little innovation in requirements presentation and use. In this age of hypertext and graphics I would expect more in presentation. Similarly in use, about the only thing I can point to is Parnas' active reviews (In D.M. Hoffman and D.M. Weiss Software Fundamentals: Collected Papers by David L. Parnas, Addison-Wesley, 2001, ISBN: 0-201-70369-6, Chapter 17. -- if you do not have this book and you are or aspire to be a software engineer, you should put it on your "books to read list", if not "books to purchase when I have enough money" list.).

Granted that life cycle tools have integrated requirements into their workbenches but there is no scheme for the rest of us.

I hope to make this one of the tracks we explore on the blog. We spend so much time grappling with and relying on requirements, yet we do not seem to spend enough time trying to improve them and their use.

So, for discussion, am I wrong? Is there innovation in requirements presentation and use, and if so where? If there is not innovation in requirements presentation and use, where should we begin? Perhaps one place to begin is to suggest publicly available instances of what you consider great requirements or attempts to be innovative in representing and using requirements. I will try to do the same. Later.

Proto Spasms

In our CS540 class Monday we discussed prototyping. One recurring issue is how members of the team can prevent promotion of the prototype to a product. Recall that most prototype schemes are designed to support requirements elicitation and after the prototype is completed the appropriate course is to formalize requirements and then begin design. Unfortunately prototypes often take on a life of their own and sometimes the developers contribute to it.

So the question is how can we insure that prototyping is not misused. My answer in class was a strategic one involving architects and architectural reviews. However, in organizations where reviews are not in place (and may never be in place) what can teams do to prevent misuse?

For the contrarians out there, do you know of instances where promoting a prototype (excluding evolutionary prototypes) to a product was a good thing? I appreciate your input! Later.

Redesign

Return visitors will notice that I have redesigned the site. This includes making it more consistent with Stevens colors. I would appreciate your comments on the site.

My New Year's resolutions include posting at least once per week on this site. I know there was a bit of inactivity during the holidays but I hope to increase the activity in the coming months.

If you find value to this site, tell your friends AND contribute to the site. I will be happy to post new items if you email them to me and of course give you credit fo rthe post. Of course you can always comment on the posts.

Advancing Software Engineering will always be a community effort of all the constituencies: practitioners, researchers and stakeholders. Later.

The Unexplored Universe

This is a request for feedback from students who have taken my Introduction to Quantitative Software Engineering Course, CS540 for those of you who prefer numbers. However I encourage others to contribute, since I will provide the current list of topics I introduce in the course.

Currently the course covers: Software Process Models, Software Requirements, Capability Matrurity Model and the Software Engineering Institute, Managing Software Requirements, Software Project Planning, Software Requirements, Metrics, Estimating Effort, Risk Analysis, Scheduling, Softwar eProject Reviews, MULTICS case study, Quality Assurance, Development Standards, Configuration and Build Management, Testing, Systems Engineering, Analysis and Modeling, Architecture, Design, Supporting Techniques (Problem Solving, Meeeting Methods, Negotiation, Management management), Object-Oriented Analysis, OO Design, OO Testing, OO Metrics, Light vs. Heavy Methodologies Including XP, Open Source, Gaming, Softwar Factories, Computer Human Interaction, Formal Methods, Clean Room Development, Fault Tolerance, Software Archeology. Phew. The textbooks include Brooks Mythical Man Month and van Vliets Software Engineering.

My goal is to touch on each of these subjects and provide pointers so that students can investigate the topics further on their own. So I am reticent to exclude topics and would appreciate pointers to topics in Software Engineering that I have missed. One bit of feedback last semester was that I should spend more time on Quality.

Are there other topics that I am missing? Are there some topics that I should not cover? Do you have ideas for other classic case studies? One topic I am considering adding next term is Out Sourcing of Software -- would this be helpful?

Thanks for your help! Later.