2014 Year-End Wrap-Up

Here we are at the end of 2014.  My first blog post of the year was a list of goals and resolutions for the year that just ended, so now, on the last day of the year, seems like a good time to review those intentions and see how well they turned out for me.

My documented goals were these:

Goal:  Take better care of my body.  
Status:  Success.  I now drink more water and less soda than I used to. I've been eating more fruits and vegetables when they are available. I've become increasingly better at taking the supplements and medications that my doctor recommended for me.  However, I still need to get more exercise and take better care of my body in general.

Goal:  Improve my financial situation.
Status:  Success.  I have trimmed my spending to almost nothing, which still doesn't leave me quite enough to cover all of my expenses on the average month, but I am closer now than I have been since I moved here six years ago.  I am highly optimistic that 2015 will finally allow me to break even by the end of the year.

Goal:  Increase my game development activity.
Status:  Failure.  Though I did make my first substantial demo of my new engine, it's certainly not a finished game.  Graduate school and the ever increasing demands of my job and family life have essentially removed me entirely from the game dev scene this year, which has taken a serious toll on my psychological well-being.

Goal:  Be a better friend.
Status:  Success.  I can't take all the credit, because I had some very dear friends just reach out to me unexpectedly and reconnect just like old times.  I am profoundly grateful in a way that words cannot express.  I still don't keep in touch with my friends like I want to, but at least I have a few special ones in my life on a regular basis now.  I needed this in a way that I never thought possible.

Goal:  Raise my professional credentials.
Status:  Success.  I didn't obtain any certifications like I'd hoped, but I did start work toward my Ph.D.  That's huge.

Goal:  Find a work/life balance.
Status:  Failure.  I still have absolutely no idea how to get my work done on time and done well, while also letting me take care of my family and all of the other things on this list.  I shall renew this goal for 2015 and just keep trying.

Thanksgiving 2014

Happy Thanksgiving, everyone!

I don't have a lot of time to write this post because Thanksgiving is in full swing and so is the anticipated commotion that accompanies it.  But I have a tradition of writing a list of things for which I am thankful on Thanksgiving, so I didn't want the holiday to pass without taking the time to do it.  I have no time for planning or editing, so you're going to get this in a single, unedited, stream-of-consciousness writing.

I am thankful for:

My family.  My son is an awesome little dude who I love with all my heart.  My wife occasionally manages to find a little time for us around her overstuffed schedule.  My brother-in-law has been extremely helpful with babysitting and letting me keep my work schedule fairly consistent.  My parents and I have managed to keep in touch better this year.  Thanks to social media, especially Facebook, I've reconnected with some cousins and distant relatives who I haven't seen in decades.

My career.  It certainly isn't exactly what I want it to be, but each year takes me a little closer.  I'm thankful for the opportunities to speak at major events (twice this year!), collaborate with other dedicated, compassionate, intellectual educators, and continually improve my skills and knowledge.

My students.  Sure, I occasionally get a difficult one that I'd rather not deal with, but most of my students are friendly, fun, respectful, creative, and hard-working.  Many of them are exactly the types of people with whom I like to work.

My colleagues.  This year has provided some great opportunities for me to meet new colleagues and get to know the ones I'd already met.  I'm thankful for the support we offer each other, in both professional and personal ways.  It flatters me that some of them have trusted to confide some very personal things in me, and that is something that I take very seriously.

My friends.  I carry a perpetual burden of guilt regarding the lack of contact I have with my friends, and I don't see any easy way to fix that. However, I am extremely thankful for those who have helped me to improve the frequency of my contact with them.  Some very old and dear friendships have been resuscitated this year just by making small efforts to reach out every once in a while.  I hope this continues, and possibly spreads to other friends, old and new, who I miss terribly. I don't know if anything can cure my loneliness, but having contact with people who care certainly helps.

My education.  Not only do all of my past experiences factor into everything I do, but I also started attending graduate school again to pursue my Ph.D. this year.  I am thankful for the opportunity to do this, the support provided by my employer, and the fantastic experiences I've had so far in this program.  It's perhaps the most exciting thing I have going on right now.

My house.  I complain all the time because my current house is twice as expensive but half as good as my old house, but I have to admit that it's far from being the worst thing people live in.  I'm thankful that it's adequately comfortable and functional, that it's in a good location, and that I have a home at all.  Not everybody does.

This list feels incomplete, so I may add to it if I'm so inspired.  But it'll do for now.

Again...Happy Thanksgiving!

I Never Thought I'd Love Requirements Engineering

Anyone who knows me or has read my blogs knows that I'm a software engineer with a sick level of passion for the subject.  Software engineering is comprised of a variety of disciplines and knowledge areas, so it's only natural that one would be attracted to some areas, repulsed by some, and remain neutral to some.

A current grad school class (CSCI715 at North Dakota State University with Dr. Gursimran Walia) required us to read two papers about requirements engineering, which has always been a topic that I acknowledge as an utterly necessary activity, but not one that I found particular enjoyable.  However, as I read these papers, I found myself being drawn in and becoming rather excited about some of the research directions in this area.  (I know I'm a nerd.  Shut up.)

Requirements engineering (RE) is arguably the most critical activity in a software engineering effort, possibly second only to construction.  The aim of this process is to develop a clear understanding of how a new software system is expected to behave and perform.  The importance of this cannot be overstated, for without this understanding, other activities cannot be completed with certainty.  Design, development, testing, configuration management, deployment, and practically every other software engineering activity depends heavily on the presence of a complete, accurate, verifiable, and clear specification of requirements.  Without an understanding of the expectations, we have no way of knowing when the work is finished.  We would have no means of assessing the correctness of the resulting behavior.

Legendary software engineer Frederick P. Brooks, in his paper No Silver Bullet: Essence and Accidents of Software Engineering, writes:

The hardest single part of building a software system is deciding precisely what to build. No other part of the conceptual work is as difficult as establishing the detailed technical requirements, including all the interfaces to people, to machines, and to other software systems. No other part of the work so cripples the resulting system if done wrong. No other part is more difficult to rectify later.  Therefore, the most important function that the software builder performs for the client is the iterative extraction and refinement of the product requirements. (Brooks 1987)

Given the magnitude of these implications, it is expected that software engineers would make efforts to improve the efficiency and effectiveness of the requirements engineering process.  Two papers that propose such improvements are Requirements Engineering: A Roadmap by Bashar Nuseibeh and Steve Easterbrook; and Research Directions in Requirements Engineering by Betty H.C. Cheng and Joanne M. Atlee.

Nuseibeh and Easterbrook begin in a typical fashion by justifying the importance of requirements engineering and then analyzing a formal definition of it.  Then they break away from the pack in a variety of ways:  First, they argue quite effectively that RE involves more than just business and technology, but that it also depends on psychology, anthropology, sociology, linguistics, and philosophy.  Second, they propose requirements management and communication as integral umbrella activities.  Though this appears to be stating the obvious, it is an area that many authors neglect to adequately address.  Also, rather than just providing simple examples of the primary RE activities, they include a moderately detailed list of approaches for accomplishing each one.  Finally, and perhaps most significantly, they reorganize the classic paradigm into more specific categories:  eliciting, modeling and analyzing, communicating, agreeing, and evolving.

The first of these activities is elicitation, the process of extracting software requirements from the people and environment surrounding the need for a new software system.  Nuseibeh and Easterbrook recommend beginning the elicitation process by identifying system boundaries, the results of which will continue to influence further elicitation efforts.  To accomplish this, they advise requirements engineers to identify the stakeholders, elicit their business and technical goals, and explore a series of scenarios including the way things are done before the new system is available and the ways that the new system is expected to change the performance of these tasks.  The techniques proposed to elicit this information include traditional data gathering, joint application design, prototyping, modeling, cognitive knowledge acquisition, and various contextual techniques.

Proceeding forward from elicitation is analysis, the process of solidifying, refining, and organizing the requirements obtained through elicitation.  The most common and effective technique for performing analysis is to create models, upon which Nuseibeh and Easterbrook place such emphasis as to rename the process with it -- “Modelling and Analyzing Requirements”.  The authors describe the use of models for analysis in five distinct categories:

1. Enterprise models that document an organization’s structure, operations, and goals;
2. Data models to represent details and relationships in the information that a system must produce, process, and/or store;
3. Behavioral models to explore the functional activities of people and systems;
4. Domain models to capture important aspects of the business, technical, and/or physical environment in which a system will operate; and
5. Non-functional requirements models to express the quality attributes of a system.

Throughout all of the phases in RE, communication intermingles with other umbrella activities.  Communication is primarily documentation which takes numerous forms depending on the nature of the requirements being communicated and the intended audience.  Proper documentation simplifies the process of requirements management by enabling requirements traceability (RT), which is the ability to track a requirement from its original elicitation through implementation and beyond.

One key thing that Nuseibeh and Easterbrook handle very differently from most authors is their treatment of verification, which is an attempt to ensure that requirements are correct and complete.  Instead, they refer to the concept of agreeing requirements, which concentrates more on validation than verification.  Validation is the task of ensuring that the requirements statements accurately reflect the true needs of the stakeholders.  Agreeing requirements involves making sure that the stakeholders all agree with the requirements statements, and may possibly involve some negotiation techniques to reach consensus.

Finally, Nuseibeh and Easterbrook confront the inevitable problem of change by including a discussion on evolving requirements.  The process of evolving requirements is really just a form of another software engineering activity -- change management, which involves expecting change and following an established procedure for responding to it.  Since requirements can change at any point, the process of evolving requirements incorporates all other phases of requirements engineering, possibly requiring an engineer to revisit phases that have already been performed in order to successfully incorporate the new changes.  Evolving requirements exemplifies the need for requirements traceability and demands, at the very least, a return to elicitation and analysis.

Whereas Nuseibeh and Easterbrook’s paper focused primarily on current practices in requirements engineering, Cheng and Atlee’s paper looks to the future by exploring and summarizing research directions.  Essentially, they begin with an explanation of why RE is difficult, summarize the current state of the art of RE research, and then proceed to identify future research areas to help manage the difficulties identified.

Cheng and Atlee do an exceptional job of describing the purpose of each RE phase; presenting each one with a concise definition and justification for its existence.  By concentrating on each activity’s intent, the authors draw clear connections to the types of solution-based research that most directly benefit each task.  Elicitation involves identifying requirements, so most research in elicitation focuses on improving the precision, accuracy, and variety of those requirements.  Modeling involves creating abstract representations of requirements, so research in this area involves improvement of scenario-based models and techniques for manipulating them.  Analysis involves the refinement and organization of requirements, so research in this area attempts to improve evaluation techniques.  Validation ensures that requirements accurately reflect the needs of stakeholders, so research into verification techniques deals mostly with communicating the requirements to stakeholders in a clear way so that an accurate assessment can be made.  Requirements management comprises numerous responsibilities, so the research areas here cover a diverse array of concerns:  automation of RE tasks, analyses of requirement stability for the purpose of isolating those most likely to change, and techniques for organizing large numbers of requirements.

Following the discussion of solution-based research, the bulk of the paper concentrates on evaluation-based research, in which there are a number of research strategies which the authors first summarize and then discuss in detail:

• Paradigm shift: Radically new ideas change the way of thinking.
• Leveraging other disciplines:  Analogies to other disciplines are drawn to help find solutions.
• Leveraging technology:  New technology is applied to solving RE problems.
• Evolutionary:  The state of the art is advanced by incremental but meaningful improvements.
• Domain-specific:  A problem is solved in a way that applies to a specific application domain.
• Generalization:  A domain-specific technique is generalized to apply outside of that domain.
• Engineering:  RE techniques are simplified to make them accessible to practitioners and students.
• Evaluation:  Existing RE techniques are assessed according to some benchmark or objective.

In addition to the detailed coverage of research strategies, Cheng and Atlee identified nine “hotspots” -- areas that are expected to have the largest impact on software engineering:

1. Scale:  The size and complexity of software systems creates a need for improved modeling, analysis and requirements management techniques.
2. Security:  New technologies present new security threats, which may or may not benefit from improved RE.
3. Tolerance:  Some requirements are difficult to quantify precisely, so tolerances must be established to assess sufficient correctness.
4. Increased Reliance on the Environment:  Systems are increasingly interoperable with other systems, so we need better ways to represent scope boundaries and interfaces.
5. Self-Management:  Requirements and environment change frequently, and a self-managing system that can react and adapt would have numerous applications.
6. Globalization:  Communication is difficult for globally distributed development teams.  There is a need for tools and techniques to facilitate collaboration and negotiation.
7. Methodologies, Patterns, and Tools:  A need exists for improving the transfer of RE techniques from research into practice.
8. Requirements Reuse:  Products from similar product lines have a large number of requirements in common.  Reusable requirements would shorten engineering timeframes and benefit from past experience, but must be adequately flexible to adapt to subtle variations.
9. Effectiveness of RE Technologies:  The results of RE efforts are only useful if they are applicable to real-world problems.  Evidence of applicability is required in order to assess the value and utility of RE techniques and research.

The paper culminates in a thoughtful and inspiring list of recommendations, many of which involve collaboration and communication:  Researchers should work with practitioners, other researchers, and industrial organizations; repositories of artifacts should be jointly established; researchers should conduct evaluation research and proactively consider emerging technologies; and academics need to confer this knowledge to students of disciplines related to software development.

Quite a few of these research directions piqued my interest and caused me to reconsider my own selection of research area.  Cheng and Atlee’s description of the engineering research strategy rung with familiarity because it rephrased my own proposal for a book that I have outlined.  My concept involved leading the reader through the major SE lifecycle activities, describing the purpose of each one, and exploring ways to accomplish the objectives without the need to endure the complex, formal processes prescribed by most SE literature.  These simpler alternatives make software engineering much more attainable to the average developer or student, which conforms to the way Cheng and Atlee described engineering as a research strategy.

Of the nine hotspots, however, requirements reuse really grabbed my attention.  Again, the idea echoed in my mind as something for which I too have expressed a need.  As a game developer, I notice that the same basic requirements seem to be elicited repeatedly.  On the most basic level, it is fairly obvious that games within the same genre have many of the same functional gameplay requirements.  From a system perspective, each product released for a specific target platform shares many requirements with other products developed for that same platform.  Perhaps we can even consider this at a more general level, e.g. nearly all games involve similar multimedia needs, like graphics, animation, and audio.

This idea may even extend to non-functional requirements.  For instance, games generally place the highest priority on performance.  However, an MMO server also has a critical need for security, games that are intended to be expanded with downloadable content (DLC) have a need for extensibility, and the ever-increasing number of gaming devices demands portability.  I simply wonder if the possibility exists of establishing a set of core requirements that serve as a starting point for RE, and can then be extended, overridden, and supplemented to satisfy the unique needs of a new game product.

As I consider how one might go about researching the topic of requirements reuse in the domain of video games, I realize that there are a number of potential challenges.  First, we would need to define scope boundaries to provide focus for the types of requirements we will specify.  Second, this specification should be formed by experienced, professional game developers, preferable those who have completed multiple products.   Third, the requirements statements would need to be used in several projects so we have a valid sample size.  Fourth, we would need evaluation criteria for assessing the effectiveness of the requirements after the project had completed.  Finally, and most importantly, we would need a few different game development groups who are willing and able to incorporate our requirements statements, track the requirements accurately, and provide detailed, honest feedback on the outcomes.

Only after contemplating the content of these papers have I begun to feel genuine excitement about requirements engineering.  From this point forward, I am now considering requirements engineering research as a viable dissertation area.

An Introduction to Software Architecture

I teach an undergraduate course in software engineering that covers a lot of great information, but is disappointingly light on the subject of software architecture.  As a software engineer, I find it a bit disturbing that such a vital topic is handled so summarily.

At the request of my students, I put together a supplemental presentation on the topic.  When asked if I had any notes of my talk, I had to admit that I did not.  So, for the sake of my students and whoever else is reading this blog entry, here is a written form of my supplemental presentation on software architecture.

Introduction

When you think of the word “architecture,” what comes to mind?  You might imagine the styles in which buildings are designed.  Some might think of electronic devices and how all of their parts work together.  Others might think of how computing systems are connected in a network.

All of these are examples of architectures, and there are many more.  We software engineers are concerned with software architecture, which shares several commonalities with the types of architecture mentioned above:  Software architectures have recognizable styles.  Software architectures describe the parts and their purposes.  Software architectures show how the parts connect and communicate.

Many definitions exist for what software architecture is.  Some are casual and informal while others are precise and detailed, but they all generally agree on the main point:  It is a representation of the major components of the software and how they are connected.  It is a framework that describes the overall structure of a software system and how all of the parts are integrated together into a single, cohesive product.

Architecture is not concerned with how the components will perform their functions.  Rather, architecture is only concerned with what pieces will exist and how they connect and communicate with each other.    Architecture encompasses the structures of a system, supports general properties and qualities, and concentrates on the behavior and interaction of elements.

Given this description, architectural design may seem like a simple task, but many different styles of architecture exist and more than one may be suitable for a given application.  Each has its benefits which can help guide the decision-making process.

The Importance of Software Architecture

It is widely accepted that a carefully considered and well documented architecture provides the highest return on investment of any software engineering work product.  The reason it has such a high payoff is because of the number of benefits it provides as well as the significance of those benefits.  There are three key reasons why architecture matters.

First, it improves communication among stakeholders.  As you may know, communication is considered one of the greatest challenges in software engineering.  Since architecture can be represented using a variety of textual and diagramming notations, it can take on forms that are useful to people of diverse backgrounds.  This enables communication between people who may otherwise find it difficult to do so.  Also, architecture is documented in a variety of views which show different aspects of the system.  This means that stakeholders can view the architecture from a perspective that makes sense to them and addresses their specific concerns.

Second, it captures design decisions that will influence nearly all of the software engineering work that follows.  Here are some examples, and there are numerous others:

• Best practices suggest that the configuration manager should maintain a directory structure that roughly mirrors the architecture.  This simplifies maintenance by helping to pinpoint the precise location of faults as well as guiding various decisions during deployment.
• Software designers frequently come up with multiple designs that would solve a given problem.  An understanding of architectural priorities helps them to select a candidate design that would best support the overall quality goals of the system.
• The development team who constructs the software makes countless decisions through the development process, and many of these decisions are made easier by understanding the architecture.  It also divides the system into distinct elements which the development team can prioritize and use as a basis for metrics, planning, and estimation.
• The testing team can refer to the architecture to identify areas of concern, and testing coverage can be planned accordingly.  Also, testing priorities are more easily established when influenced by the architecture because testers can focus their efforts on the qualities that are most important to stakeholders.

Third and finally, architecture provides a relatively small, simple, and reusable model of the overall software system.  At this level, there are many similarities among the architectures of entirely different software.  Therefore, the same architecture can be reused in many different software systems.  Once an architecture has been used on a project, it can be reviewed for its effectiveness, and then reused or slightly modified for future projects that have similar nonfunctional requirements.  The presence of a simple model makes it easier to determine whether an architecture will work in a new scenario, or how to make any necessary modifications.

Influences on Software Architecture

The importance of architecture as a communication tool comes from the fact that it must satisfy a diverse array of needs, such as technical needs, business needs, and other input from stakeholders.  In a later section below, we will discuss how these concerns can all be incorporated into the decision-making process.

Technical Factors

Of course the architecture must allow for the inclusion of functional requirements – the specific behaviors that the software is expected to perform.  Functional requirements are usually independent of the architecture, but we still must ensure that the architecture does not somehow obstruct them.

From an architectural standpoint, we are more interested in nonfunctional requirements (NFR) – general properties that the system must possess.  The architecture can enable the software to have some of these qualities while hindering others.

 Nonfunctional requirements are also known by other names.  They are often called quality attributes.  Some call them by their nickname:  “the ilities”.  This nickname comes from the fact that many of them end with “-ility” – portability, modifiability, extensibility, and so on.

Most NFRs fall into these broad categories:

• Functionality – the software is sufficiently secure, contains reusable components, and can be ported to other computing platforms if necessary.
• Usability – the software is reasonably easy to learn and use efficiently.
• Reliability – the software is available when users need it, rarely breaks down, and is capable of recovering from problems.
• Performance – the software runs reasonably quickly, uses system resources economically, and can be scaled to support more data, interfaces, or users.
• Supportability – the software can be modified, extended, or repaired without excessive difficulty.

Business Factors

In addition to technical requirements, the architecture must also support business concerns, like development costs, maintenance costs, marketability, and so on.  Some nonfunctional requirements span both technical and business concerns.  For example, supportability implies specialized, technical work being performed, but the longer it takes to do so, the more it costs.  Therefore, it is both a technical factor and a business factor.

Stakeholder Input

The ultimate driver for any kind of design decision is the set of needs that the stakeholders have.  If the resulting system does not serve the needs of its stakeholders, then it is a failed product.

A Summary of Common Architectural Styles

Software architectures and building architectures have something meaningful in common:  They both have defined styles that provide certain clues to their layouts and features.

Here is a list of some common architectural styles.

• Data-Centered Architectures for systems whose primary function involves accessing or manipulating a central data store.  Good for database-centric applications.
• Dataflow Architectures for systems that perform a complex series of data processing steps between input and output.  Good for systems that perform a long series of validations, calculations, and/or transformations.
• Call-and-Return Architectures for systems whose functionality can be divided into discreet, mostly independent tasks.  Good for systems that need to be easy to modify or scale.
• Tiered Architectures for systems whose major elements may reside on separate machines in a distributed environment.  Good for systems that need to communicate remotely across a network.
• Object-Oriented Architectures for systems that can be logically separated into distinct components that communicate through messages.  Good for systems that can take advantage of an existing code base by reusing or extending it.
• Layered Architectures for systems whose elements can be arranged in a hierarchical fashion based on their level of abstraction or generalization.  Good for systems that require portability or those that need to encapsulate a particularly complex subsystem.

Selecting an Architectural Style

Here is where things can get tricky – many software applications could be built upon more than one of these architectures.  So how do we go about selecting an architecture when there are so many viable possibilities?

If we are fortunate enough to have documented architectures from previous projects, we have two models to help us out.  A guidance model is a document that summarizes the experience of using a particular architecture, along with an explanation of what problems were encountered and what decisions were made.  When considering multiple architectures, their guidance models can be used to create a decision model which summarizes the relevant points from the guidance models and provides a side-by-side comparison of them.

If we do not have such information available to us, then we can create our own analysis model to gain an understanding of what qualities (NFRs) we will need the architecture to support for us.  An analysis model is a representation of the system, usually from the user’s point of view, that shows us what the users will expect from the system and what constraints and limitations may exist.

Once we have an analysis model, we can apply a technique called the Architectural Tradeoff Analysis Method (ATAM).  The ATAM gives us a way to predict whether an architecture will provide the desired quality attributes.

The Architectural Tradeoff Analysis Method (ATAM)

Here is a brief summary of how the ATAM works:

First, use analysis models to understand what the stakeholders expect in terms of nonfunctional requirements.  It may require multiple models to make sure that all stakeholder concerns have been addressed.

Then select a few candidate architectural styles and diagram them in a way that specifically shows how they might support the NFRs.  For example, if security is a top priority, then diagram the architecture to highlight how it might allow security to be implemented.  This type of diagram is called a view, and the same architecture can be represented in multiple views.  (In fact, that is a best practice.  We will discuss the 4+1 view model below.)

Experiment with each view by making a change to it, and see how that change affects the quality attribute.  Make this same change with all of the views and see how other qualities might be affected.  If a small change has a large, negative impact on the quality, then we have identified a sensitivity point which becomes a major factor in the evaluation of the architecture.

Once sensitivity points have been determined, we have a somewhat reliable picture of which architecture will be most likely to support the nonfunctional requirements.

The ATAM is likely to be repeated a few times as new details emerge.

Documenting Software Architecture

One of the most vital signs of a quality architecture is how well it is documented.  Most software architects advise that every architecture should have at least two views:

• A static view that shows the overall structure of the architecture.
• A dynamic view that shows how the elements behave and communicate.

Others argue that two views is insufficient to communicate all stakeholder concerns.  A much more thorough approach is preferred for most large projects.  The 4+1 view model is considered to be the best overall way to document software architectures for complex systems.  It consists of five views, each of which represents the architecture from a different perspective.

1. The logical view focuses on functionality.  It is usually represented in UML class diagrams or sequence diagrams.
2. The development view focuses on the components of the software that must be built by the programmers.  It is usually represented by UML component diagrams.
3. The process view focuses on dynamic aspects of the system and shows how the elements behave and communicate.  It is often represented by UML activity diagrams.
4. The physical view focuses on how the software will be physically arranged once it is deployed to the users.  A common way to represent this is with UML deployment diagrams.
5. The scenario view (a.k.a. use case view) describes sequences of activities interactions between elements of the system.  There is no standard diagram for communicating this information.  It must be done in a way that the users can understand, which may or may not involve technical diagrams.

FYI:  The reason we do not just call it the “5 view model” is because of the nature of the scenario view.  Rather than being a distinctly different view from the other four, it is usually a combination of the others to constitute the user’s view of the system.

Summary

The diversity of software architectures makes it difficult to define precise processes for specifying them or defining precise criteria for assessing their quality.  We do have some processes that have been incredibly effective, such as the ATAM, and we have documentation strategies to help us document and communicate the important details, such as the 4+1 view model.  As software engineering continues to mature as a discipline, activities such as architectural design are becoming more effective and refined.

ATTENTION, SPAMMERS!

Dear spammers:

Among the many things that I am not interested in are the following:

• Becoming a mystery shopper
• Enlarging my penis, breasts, or any other part of my body
• Qualifying for grants or scholarships in subject areas that have nothing to do with mine
• "Hooking up" or "getting laid" by complete strangers
• Getting printer ink, weight loss drugs, hormone supplements, or any other useless product delivered straight to my door
• Taking advantage of military veterans benefits
• Getting price quotes on home warranties
• Applying for jobs in New Jersey or Louisiana, or, for that matter, anywhere I'd have to relocate
• Paying below retail on women's shoes
• Earning a CDL license and becoming a truck driver

So, please, stop asking.

Goals and Resolutions for 2014

I've heard that you should never share your resolutions because people will laugh at you or sabotage your efforts.  I've also heard that you should share your goals with others because they can support you and help you reach them.  I'm not sure which bit of advice is more correct, so I'll take my usual approach and compromise.  I'll share here some of my goals and resolutions for the glorious year that we are now beginning, but I'm keeping a few special ones to myself.

• Take better care of my body.  
• Drink more water, eat more fruits and vegetables, take my doctor-recommended supplements as directed, get more exercise, take better care of problematic body parts, limit my intake of junk food and beverages.
• Improve my financial situation.
• Find a way to increase my income or decrease my cost of living so I can actually have a few dollars left over rather than being in the hole each month as I was through most of last year.
• Increase my game development activity.
• Do something project-related every week, no matter how small.  Attend more events and meetups.  Keep up with what other developers are doing.  Play a lot more of other people's games.
• Be a better friend.
• Reach out to a friend at least once every month.  Stop letting work and family obligations keep me reclusive.  Be more social and communicative.
• Raise my professional credentials.
• I know I can't do all of these, but I hope to do a couple of them:  Start work on my Ph.D, write a couple of chapters for my book, obtain CSDP certification, update my Java certification.
• Find a work/life balance.
• Randomly stumble across that magic formula that will let me get my work done on time and done well, while also letting me take care of my family and all of the other things on this list.  This is the only goal that I have no idea how to achieve.

I wish good fortune to us all when it comes to keeping our resolutions and improving our lives.  May the Force be with us.