TweetFollow Us on Twitter

May 93 - Solution-Based Modeling: A Methodology for the Rest of Us

Solution-Based Modeling: A Methodology for the Rest of Us

Jeff Alger and Neal Goldstein

This article is the second of two parts, much of which is excerpted from a forthcoming book by Jeff Alger and Neal Goldstein. Copyright © 1993 by Jeff Alger and Neal Goldstein. All rights reserved. The first part appeared in the March issue of Frameworks.

Review From Part I

Solution-Based Modeling and its companion notational system, the Visual Design Language, were developed to map well to the way creative people work best while still allowing management to estimate, schedule and maintain control. The objectives are to improve communications, decision-making and, as a consequence, the success rate of projects, chiefly through improving communications and decision-making.

There are three basic components of SBM.

  • An architecture that structures analysis, design and programming information into a series of well-defined models.
  • A notation, VDL, that can be used to define and express the models with minimal loss and distortion of information.
  • A process for overall development that pays attention to the needs of all parties to the project, from end users to management to engineering to quality assurance and documentation. This includes modeling technology that helps teach people how to build robust, complete models, alone or in work groups, and continuous quality assurance structures: algorithms and metrics that make quality software a consequence of the overall process, rather than the result of a separate step.

The architecture and notation were discussed in the first part of this article in the March issue of Frameworks. This part focuses on the process and briefly discusses a fourth component, tools, currently under development by SBM International and others. Extensions to the method are also discussed. Before proceeding, let us review briefly the overall architecture and notation discussed in the first part.

Architecture

There is growing acceptance in the software engineering community today of the so-called "multiple models" approach: dealing with a single subject by building many overlapping models. In SBM, we create a series of models of the following kinds.
  • Business models describe the business system that surrounds the computer system or program.
  • Conceptual models are idealized, or deliberately simplified, models of the content and interface of the program.
  • Run-time models describe the running program and ignore implementation details about how the source code is structured.
  • Implementation models collectively are the implementation, expressed as a combination of source code and design diagrams.

We call these four kinds of models planes and name them the Business, Technology, Execution and Implementation planes, respectively. Within each plane, we use the term region to describe one model of that kind.

Notation

The Visual Design Language (VDL) was designed in conjunction with graphics design experts and tested to enhance comprehension and retention of information in software projects. VDL emphasizes the use of small, self-contained diagrams called scenarios. An SBM project uses scenarios as the way to capture, communicate and validate business, conceptual design, software architecture, and programming informations. Scenarios typically overlap heavily in content and subject matter. Within any scenario there are elements and relationships among those elements. Provision is made for both static scenarios, in which time is not a factor, and dynamic scenarios that show a flow of action of state over time.

Process

There are four basic activities in a SBM project:

  • Creating new scenarios,
  • Validating scenarios,
  • Programming, and
  • Managing the project and library.

Creating New Scenarios

Participants in the team draft a series of simple scenarios, each of which concentrates on a single topic. The overall "model" is, in a sense, simply the collection of valid scenarios gathered during the project. SBM encourages and supports exploration of problems at or near the basic level, rather than using a top-down approach. However, to abandon top-down approaches without a substitute process in place would be foolish, since one still needs defined starting points and controlled, incremental expansion. To address this problem, SBM relies on centrality. Let's revisit the jigsaw puzzle analogy. Once the border is in place, what do you do next? Most people would pick some interesting topic, perhaps a building or a flower, and work on that pattern for awhile. When work on that topic bogs down, one shifts to some other central topic. Eventually, one works out toward the periphery perhaps connecting topics to each other or to the border. Finally, when there is nothing left but blue sky, the final, hard work begins.

This so-called center-periphery strategy is precisely the exploratory process used in SBM. It is such a natural process that it doesn't need to be formally taught; you already use it every day. In fact, even when people are asked to work in other ways, such as top-down, they end up using center-periphery strategies and make it look otherwise. SBM merely provides an environment in which it is safe and politically acceptable to run entire projects this way.

  1. Start with a central topic.
  2. Blanket that topic with small, overlapping scenarios in several regions of the overall four-plane model.
  3. When that bogs down, pick another central topic and iterate.
  4. As the model fills out, spend more and more time on the periphery.
  5. When the overall structure of the project is well-established, do the fine detail work.

Notice that this not only does not require a top-down process, it also does not force a linear approach. That is, one is free to shift focus from plane to plane and region to region at any time, rather than having to finish one region before starting on the next. This, too, is simply the way people work whether you want them to or not. In SBM, we recognize that fact and design project management strategies around it. This is the essence of the multiple models approach: rather than viewing a problem from one direction only, we continually turn it around in our hand, considering it from multiple perspectives in order to gain a more complete understanding.

VDL and the scenario paradigm are useful in many different contexts, from a software engineer scribbling at a white board to interviews with people outside the central project team to a focus group of typical end users being asked to provide critical feedback to product marketing to briefings for management on the state and objectives of the project. This is not random chance: VDL was specifically designed to appeal to a broad cross-section of team participants and "level the playing field" of communications.

Validating

The process described above releases the creative juices. People are free to follow their creative flow in the most productive way, unencumbered by an artificial process. However, eventually one must return to hard reality: the scenarios and models must be formally validated. To that end, SBM uses a series of validation strategies collectively called calibration.
  • Synthesis is used to ensure that scenarios are mutually consistent.
  • Correlation assures that multiple models are consistent with one another and each is complete in terms of the other.
  • Synchronization tests for completeness and consistency of the final architecture within itself.

Synthesis is a term borrowed from data modeling. Gather a set of scenarios, then compare them pairwise to remove any contradictions that may exist, such as synonyms and homonyms. These and other synthesis problems are really just common sense and most people have no problem recognizing them when two scenarios are laid side-by-side. With a small batch, one can simply spread them on a table and compare them pairwise visually. This quickly breaks down as the number of scenarios grows, so larger sets require the use of a cross-reference index that quickly answers requests such as "tell me all the scenarios in which object X occurs." The database support for this sort of query is surprisingly simple; in our book we describe a simple Hypercard-like database that has been used by a number of project teams to good effect. However, there is no substitute for a good automated tool here and this is a major focus of our own efforts today.

Correlation has already been described briefly: matching up one model with another through the correlation relationships Implements, Replaces and Same As. All, or a clearly defined subset (e.g., the program element of the Solution Model), of one model must be completely accounted for in the other model; in turn, each element of the other model must support some aspect of the original.

Synchronization is a series of five separate tests, all applied rigorously in the Execution Plane to validate the completeness of the run-time model. The synchronization tests are

  • Creation, validating that objects and data structures are created before use,
  • Destruction, validating that objects and data have not been destroyed prior to use,
  • Object Knowledge, that is, demonstrating how an object obtains the address of another prior to sending it a message,
  • Connectedness, validating that each method is called in response to some user or operating system event, and
  • Protocol, making sure that the calling protocol for methods is consistent throughout the model.

The first three of these are closely related and apply to all collaborations, both for the objects at each end and the inputs and outputs that make up the calling protocol of the method: For each, demonstrate that it was created in time, hasn't been destroyed, and the originating object has the required object knowledge. These tests apply equally to primitive data structures.

In a procedural program, where the branching logic is hierarchical, it is easy to tell when a subroutine cannot possibly be reached. In an event-driven world of graphical user interfaces, it is not quite so simple to tell what is and is not reachable. Enter the connectedness test. A method is connected if it is called in response to some event. Events can include user activities like mouse clicks, operating system events such as timer interrupts, or higher-level events such as messages from collaborative applications. The basic algorithm works as follows.

  1. Enumerate all sources of events.
  2. For each one, mark the method or methods called directly in response by the operating system or class library.
  3. For each marked method, mark its collaborators; that is, the other methods it calls. Apply this step recursively until no more methods can be marked.
  4. Find all unmarked methods. These are unconnected.

Unconnected methods may indicate any of several underlying problems: synonyms, vestigal code, missing collaborations, or methods put in place to support future expansion.

The protocol test is also quite simple: is any given method always called with the same formal argument types? This is commonly handled as part of synthesis; if not, it must be a separate step as part of synchronization.

The combination of these five tests, applied to the Execution Plane, is designed to uncover the problems that occur in the worst nightmares of project managers and architects. It has been estimated that 50% of a C++ programmer's time is spent tracking down memory leaks and dangling pointers, the subject of the first three of the synchronization tests. Our own surveys show that these tests address problems typically associated with 30%-40% of the programming phase of a project, and that when they occur there seems to be an unwritten rule that they occur at the eleventh hour and cause maximal damage to class hierarchies, QA test suites, and team morale. What SBM does is take these out of the domain of programming and deal with them as design issues.

We can now complete the center-periphery process described earlier by taking into account the three forms of calibration. The result is that of Figure 4, with frequent iterations at all steps.

Programming

A wealth of detail already attended to, programming in SBM projects is considerably easier than in many other approaches. There are two aspects to programming: designing class hierarchies and writing the code that implements methods. In SBM, classes are designed to optimize the implementation; they are not required to have any intrinsic "meaning." Hierarchies are designed to maximize reuse within the project while also maximizing modularity and independence. The process is basically bottom-up in designing interfaces and both bottom-up and top-down in designing implementations of methods.
  1. Group run-time objects of the Execution Plane into concrete types. All members of a concrete type share identical attributes, methods, interfaces and collaborators.
  2. For each type, create a concrete class in the Implementation Plane.
  3. Look for patterns of similarity among the concrete classes. Where such patterns exist, abstract classes are often formed to maximize sharing of properties across concrete classes.
  4. As methods are implemented, differences in behavior, thought not protocol, emerge that lead in the opposite direction: derivation of subclasses that differ in method implementation but not interface.

Managing

In managing SBM projects, everyone on the team should understand at least the following basic subjects:
  • Goal-directed phases,
  • Prototyping,
  • Estimation and the SHP formula,
  • Library management, and
  • Team management.

Goal-Directed Phases

In classical software project management, a phase is considered complete when some activity is complete. Thus, an analysis phase is complete when one is through doing analysis activities. This is in direct opposition to one of the basic principles of SBM, non-linear workflow. Fortunately, other fields have long used more sophisticated strategies in which phases of project plans are orthogonal to the activities that take place within those phases; we adapt those to the world of software development. For example, when a construction firm builds a bridge, it may go through several phases: site preparation, falsework (the temporary frame prior to pouring concrete), and so on through final cleanup. In each phase, there may be planning, design, construction, supervisory and other activities. One can tell that a given phase is complete when certain objectives have been met, independent of the activities used to get there.

In SBM projects, there are three phases between the time the project is identified and launched and the time of the final QA and shipping cycle: analysis, design and programming. Each of these phases has a defined objective to be reached.

The analysis phase is complete when

  1. Someone in authority certifies that the Business and Technology Planes cover all intended scope,
  2. All scenarios of those planes are synthesized with one another,
  3. The Technology and Business Planes fully correlate to one another, and
  4. A credible, detailed project plan is in place for the design phase.

Notice that these objectives do not require working in any particular order within the top two planes of the model. One can freely move around from region to region as long as all regions are complete by the end of the phase. In fact, there is nothing in these objectives that gets in the way of design or programming work during the analysis phase; that is, prototyping.

The design phase is complete when

  1. The Execution Plane and Technology Plane fully correlate,
  2. All scenarios of the top three planes are fully synthesized,
  3. The Execution Plane has been fully synchronized, and
  4. A credible, detailed project plan is in place for the implementation phase.

Again, this says nothing about the specific activities used to get there. One will, of course, spend a great deal of time doing design work in the Execution Plane, but there will also be refinement to the upper planes (analysis) and prototypical programming and class design.

The implementation phase is complete when

  1. The Implementation Plane and Execution Plane fully correlate,
  2. All scenarios in the model are fully synthesized, and
  3. All methods have been implemented and passed engineering QA.

During this phase there will be a mixture of programming, design and some analysis activities.

It might seem at first glance that these objectives are internally inconsistent. After all, we said that the analysis phase is not done until the top two planes are complete, yet asserted that during the design and programming phases we would revise the top two planes. There really is no contradiction. During the analysis phase, new ideas and requirements are injected from outside the model. During the last two phases the only changes made to the upper two planes are the result of correlation from below

Prototyping

Putting all this together, we can identify a target plane for each phase. For the analysis phase, the target is the Technology Plane; for design, the Execution Plane; and for implementation the Implementation Plane. This concept of a target plane allows a broader framework for an age-old subject: prototyping. In SBM, prototyping is work below the target plane of the current phase. During the analysis phase, coding is certainly prototyping, but so is drafting design or class hierarchy scenarios. During the design phase, coding and class hierarchy design are both forms of prototyping.

Few methodologies have really come to grips with the problems of managing prototyping. Prototyping is often used as a substitute for analysis and design, rather than a complement to them. In SBM, we provide a sound theoretical and practical framework for prototyping. A prototype is undertaken to help achieve the objectives of the current phase. During the analysis phase, for example, it may be unclear what user interface has the best look and feel, or whether a key algorithm with acceptable performance can be found to implement some concept of the Content Model. In each case, prototyping is in order. We clearly identify the objectives of the prototype, then pick the form of prototype most suited to answering those questions. Prototyping is not an exception to our phases, but rather fits smoothly within them.

Estimation

SBM takes a fresh approach to the whole subject of estimation by returning to a simple basic premise: the purpose of estimating is to provide sound information on which to base decisions. Perfect estimates that arrive too late are unacceptable. Our estimates have to be available early enough to be useful when the most important decisions regarding scope and resources are being made, even if it means using approximations. Furthermore, the process by which estimates are made must be understandable to all, so that every member of the extended team understands the impact their own decisions have on whether the project comes in on time and within budget. Estimation in SBM is based on a simple formula we call the "SHP" (pronounced "ship") formula:

Scenarios = Human Resources * Productivity

Scenarios represent quantities of throughput for the project. That is, we can measure the "size" of a project by counting how many scenarios it creates. This has proven to be an extremely useful metric, much more useful than any other quantification we have considered and a considerable improvement over conventional metrics such as lines of code or function points. Be careful about interpreting this number, however. The number of scenarios is used to quantify all work, not just activities directly related to scenarios. This includes research, interviews, team meetings, coding, and general overhead activities.

Human resources are measured in person-days and productivity is measured in scenarios per person-day. That is, take the number of scenarios drafted, reviewed and calibrated by the team as a whole and divide by the number of person-days during that period. Our studies have shown that productivity is remarkably consistent across team sizes, platforms, even team experience (more experienced personnel simply get more done with fewer scenarios) at about 1.2 scenarios per person-day. The lowest number we have seen is 0.8, the highest 1.7, with a strong cluster centered on 1.2. (Until organizations gather statistics of their own, we recommend a conservative working estimate of 1.0 scenarios per person-day.) This fact makes the SHP formula a useful one for predicting how long a project will take: if you can estimate how many scenarios will be required, you can predict how long the project will take.

We combine the SHP formula with the statistic that 50% of development efforts go toward analysis activities to come up with a unique approach to software estimation. We assume that the estimators are wrong; in fact, consistently wrong. But by sampling a small subset of the estimate, then extrapolating the results to the overall "guestimate," we can converge on a statistically valid estimate for the project. It works something like this.

  1. You guess that it will take 600 scenarios to complete the analysis phase, based on adding up smaller estimates for individual topics of the Reference and Solution frames.
  2. Sample one or more of those topics by breaking them down into a finer-grained estimate based on subtopics. Suppose, for example, that the sum of the finer-grained estimate for a given topic is 50 scenarios, where the previous guess for that topic was 40. Extrapolate by increasing all other topics by 25%. The new estimate is 750 scenarios.
  3. Sample one subtopic by actually doing the analysis work through to completion. Compare the actual number of scenarios, say, 16, against the estimate for the subtopic, say, 12, and extrapolate the ratio of the original estimate to the actual experience. The new estimate in this example is 1000 = 600 * 50/40 * 16/12.
  4. Continue to sample in this way until the estimates converge with the samples.

There are a couple of minor subtleties to this process, such as accounting for the appearance of new, unanticipated topics during sampling, but this is the basic strategy. It is quick, reliable, and easy to explain, even to people who have no experience with software development. It also does not rely on completing more than a small sample of the analysis before yielding useful information about the size of the project. For most projects, a good, early estimate can be achieved within two to four weeks of the start of the analysis phase.

Not only is an early estimate possible, but the numbers - scenarios and human resources - take at most fifteen minutes a week to gather as the analysis phase proceeds. This makes it possible to generate a new estimate each week, adjusting scope smoothly each Monday to keep the project on track against its baseline delivery date. Thanks to sampling, features can usually be cut before the investment is made in their analysis.

Library Management

SBM and VDL are designed to make the primary means of documenting a project also the most convenient way for team members to take notes or scribble ideas. That is good, for it minimizes the time interval between creativity and documentation and minimizes the translation needed once information is captured. As we have discussed, this strikes at the heart of communications problems in software projects. This means that much, much more information is captured in paper or electronic form than is normally the case in software projects. We have found it not unusual for a project team to assemble three to ten times as much documentation, measured in terms of pages, than would normally be the case, but without slowing down the project in the process. That is almost a Holy Grail of software engineering. With that benefit, however, comes a cost: simply keeping track of the scenarios and keeping them current and calibrated.

There is no question that managing that much paper or a database that size, depending on the form of automated support used, is a major part of project management.

team Management

No method should be considered complete unless one maps it on to the sorts of day-to-day decisions faced by team members, including project managers. There are two areas of project management that deserve mention here: the structure of the project team and the use of SBM and VDL as a means of addressing classic problems of communications, decision-making and people management.

SBM recognizes the following decision-making roles, or areas of specialization (though in a typical project more than one area may be handled by a single person). This is in addition to overall project management.

  • Business Analyst. Responsible for completion of the Business Plane.
  • Content Architect. Responsible for completion of the Content Model and Content Architecture.
  • User Interface Architect. Responsible for completion of the UI Model and UI Architecture.
  • Environment Architect. Responsible for completion of the Environment Model and Environment Architecture.
  • Software Engineer. Responsible for the Execution and Program Planes (thus overlapping the three Architects). Decisions are focused on optimization, synchronization, and software engineering issues such as modularity and reuse.
  • Project Librarian. In a medium-to-large project, this should be a dedicated position, rather than have everyone do their own cataloguing and calibrating. Responsible for maintenance of the library of scenarios and for seeing to it that calibration is done completely and at the right time.

In each case, these are the people who are accountable for seeing to it that the work in their respective areas gets done, even if they do not personally do all the work. They also should carry the authority to make final decisions in those areas. These roles correspond to the sorts of skill sets commonly found in a single individual. They also concentrate related areas of decision-making.

Productivity is constrained by many factors, but at the top of the list are interpersonal, team-centered issues. We wrote earlier of the dominant personality problem: an individual with strong verbal skills and an aggressive personality often dominates project decision-making, all out of proportion to differences in skill level. VDL helps level the playing field by diminishing the roles of both verbal skills and personality. Anyone can learn to use VDL quickly and calibration demands that everyone's input be accounted for.

SBM and VDL also make it feasible for people to work separately or in teams of two, then integrate the results. This is otherwise difficult to do because the media of expression are not formalized enough to support the equivalent of synthesis. As a result, more decisions are made in group settings than is really healthy or productive. In SBM, we recommend a process we call "come together-break apart": one hour per day the team meets as a group to review work done by each other and identify and prioritize needs for new work. In the remaining time, team members work individually or in teams of two, resolving To Do items from scenarios already done. Breakout sessions are also used to revise work based on group feedback, catalog it, and calibrate. This process is not only more efficient than group meetings, since in a group only one person can (or should) be talking at a time, it also leads to better decision-making.

During group sessions, a printing white board is invaluable. It is used to sketch VDL scenarios - and the all-important To Do lists - as the group deliberates. More than a medium, it becomes a means of reaching agreement. Whoever holds the marker has a finger hovering over the "print" button and says, "Are we agreed? Going once… going twice… print!" Everyone in the room knows that agreement was reached and gets a copy of the result. VDL facilitates this because the medium is consistent, not the result of individual style or whim.

The estimation strategy outlined above makes possible a new model for accountability in software projects: the extended team, including engineers and non-engineers, is jointly responsible for meeting the deadline for completion of the analysis phase. The engineering team is then responsible for completion of the design and implementation on time. This seemingly simple change has a profound impact on the quality of decision-making.

These may sound like common sense or even trivial matters, but they are not. These sorts of issues are very important to the success or failure of entire projects, and are therefore not just petty interpersonal issues. SBM and VDL greatly facilitate the basics of people management: communicating, reaching agreement, making team productivity as close as possible to the productivity of one person times the size of the team. We are amazed at the lack of attention these issues have received in other methodologies given their impact on outcomes of projects.

Extensions to the Basic Method

SBM is actually a special case of a more general approach to managing change. For example, there are straightforward extensions that handle the full maintenance lifecycle, distributed systems, and large projects broken down into smaller subproject teams. It is also relatively easy to extend the approach to support future object-oriented frameworks that will not have clear boundaries between "applications," but rather what we call "object soup:" objects firing messages off to other objects without regard to application-level protocols.

We have also heard from a number of people who have been using SBM and VDL purely for their strength in business modeling, even if no software development is under consideration. The techniques of visualization, communication, decision-making and validation are as important for introducing change to businesses as they are for systems development projects. In fact, we view this as the largest future market for the SBM approach.

Finally, because of the modular, scenario-based form used to express analysis and design, SBM and VDL make it practical to reuse analysis and design scenarios across projects. With all the hoopla about reuse of code (notable for the lack of real success), a simple fact seems to have been forgotten: most of the money spent on software development is spent on analysis and design, not code. At this time we are working with several organizations on repositories of analysis and design scenarios to be used across projects. We also feel this presents an opportunity to create an entire new industry: production and sale of analysis and design "packages."

Automated Support

SBM and VDL can be supported with an extremely simple database, one that can be assembled in under a day with any consumer database product. Many SBM projects have been run completely manually, though not without a good deal of grumbling. Clearly, though, SBM could benefit from good, automated support.

The least important problem is graphic support, that is, drawing pretty pictures. This occupies a small fraction of the overall human resources in a SBM project. Instead, the focus should be on two issues that do take up a lot of time: calibration and browsing. The browsing is particularly important, answering such questions as "show me all the scenarios in which object X appears" or "show me all the responsibilities (or collaborators or parts…) of object X across all scenarios."

It is also important to maintain the basic principles behind SBM: non-linear and non-hierarchical flow, multiple models, visual communication, and defering calibration until creative flow has slowed. This combination has made it difficult for CASE vendors to support the methodology to date. ("Of course, we'll have to get rid of the 3D notation, divide everything up into three different tools to be used linearly, constrain the use of VDL to well-defined syntax, and otherwise change it all around, but SBM is great and we'd like to support it!") Despite this difficulty, we have recently been approached by several CASE vendors about proposed extensions to their products. As SBM continues to grow in popularity we expect this trend to continue until SBM is widely supported.

In the meantime, SBM International will soon be releasing a series of tools specifically designed to support SBM. As of this writing, the first of these tools , the VDL Companion™ modeling tool, is in beta test and should be in final release by the time this article is published. Higher-end products are being worked on that will support calibration algorithms (VDL Professional™) and multi-user repositories (VDL Teamware™). These are designed to maintain the spirit of SBM and VDL: non-linear, visual, non-hierarchical and supporting very flexible use of VDL for introducing new idioms.

SBM International provides consulting, training and tools that support the use of SBM. For more information, contact the authors at (415) 424-9400, FAX (415) 857-0198, or at 3124 South Court, Palo Alto, CA 94306.

 
AAPL
$104.48
Apple Inc.
+1.49
MSFT
$44.81
Microsoft Corpora
+0.43
GOOG
$542.21
Google Inc.
+9.50

MacTech Search:
Community Search:

Software Updates via MacUpdate

jAlbum Pro 12.2.4 - Organize your digita...
jAlbum Pro has all the features you love in jAlbum, but comes with a commercial license. With jAlbum, you can create gorgeous custom photo galleries for the Web without writing a line of code!... Read more
jAlbum 12.2.4 - Create custom photo gall...
With jAlbum, you can create gorgeous custom photo galleries for the Web without writing a line of code! Beginner-friendly, with pro results Simply drag and drop photos into groups, choose a design... Read more
ExpanDrive 4.1.7 - Access remote files o...
ExpanDrive builds cloud storage in every application, acts just like a USB drive plugged into your Mac. With ExpanDrive, you can securely access any remote file server directly from the Finder or... Read more
OmniOutliner Pro 4.1.3 - Pro version of...
OmniOutliner Pro is a flexible program for creating, collecting, and organizing information. Give your creativity a kick start by using an application that's actually designed to help you think. It'... Read more
Evernote 5.6.2 - Create searchable notes...
Evernote allows you to easily capture information in any environment using whatever device or platform you find most convenient, and makes this information accessible and searchable at anytime, from... Read more
OmniOutliner 4.1.3 - Organize your ideas...
OmniOutliner is a flexible program for creating, collecting, and organizing information. Give your creativity a kick start by using an application that's actually designed to help you think. It's... Read more
BBEdit 11.0 - Powerful text and HTML edi...
BBEdit is the leading professional HTML and text editor for the Mac. Specifically crafted in response to the needs of Web authors and software developers, this award-winning product provides a... Read more
Apple Security Update 2014-005 - For OS...
Apple Security Update is recommended for all users and improves the security of Mac OS X. For information on the security content of this update, please visit this website: http://support.apple.com/... Read more
EyeTV 3.6.6 - Watch and record TV on you...
EyeTV brings a rich TV experience to your Mac. Watch live TV on your Mac. Pause, rewind, and record whenever you want. EyeTV gives you powerful control over what you watch and how you watch it. Put... Read more
RapidWeaver 6.0 - Create template-based...
RapidWeaver is a next-generation Web design application to help you easily create professional-looking Web sites in minutes. No knowledge of complex code is required, RapidWeaver will take care of... Read more

Latest Forum Discussions

See All

Jam Messenger Review
Jam Messenger Review By Jennifer Allen on October 23rd, 2014 Our Rating: :: SIMPLE MESSAGINGiPhone App - Designed for the iPhone, compatible with the iPad Want a very quick way to send push-based messages? Jam Messenger is basic... | Read more »
Felllice (Games)
Felllice 1.0 Device: iOS Universal Category: Games Price: $.99, Version: 1.0 (iTunes) Description: EXCLUSIVE PRICE DROP! 50% OFF FOR A LIMITED TIME! EAT EAT EAT AND GROW ! | Read more »
The Arrow Game: by Grazie Media (Games)
The Arrow Game: by Grazie Media 1.0 Device: iOS Universal Category: Games Price: $.99, Version: 1.0 (iTunes) Description: Guide a flying arrow through skyscrapers and city streets to hit a distant target. Experience an endless... | Read more »
Worldly (Games)
Worldly 1.2 Device: iOS Universal Category: Games Price: $2.99, Version: 1.2 (iTunes) Description: | Read more »
Money Pro - EASY! Bills, Budgets and Acc...
Money Pro - EASY! Bills, Budgets and Accounts w/ Sync 1.0 Device: iOS Universal Category: Finance Price: $4.99, Version: 1.0 (iTunes) Description: Manage money like a pro. Money Pro is the next generation of Money app (over 2 million... | Read more »
Pro Strategy Football 2014 (Games)
Pro Strategy Football 2014 2014.141001 Device: iOS Universal Category: Games Price: $4.99, Version: 2014.141001 (iTunes) Description: Take the proven strategy of the PSF franchise and add in Casual Play, improved graphics and... | Read more »
Super Glyph Quest (Games)
Super Glyph Quest 1.01 Device: iOS Universal Category: Games Price: $2.99, Version: 1.01 (iTunes) Description: Adventure is back Questers! Combine elemental glyphs together to cast powerful spells and vanquish adorable monsters in... | Read more »
Fighting Fantasy: Caverns of the Snow Wi...
Fighting Fantasy: Caverns of the Snow Witch 1.0 Device: iOS Universal Category: Games Price: $5.99, Version: 1.0 (iTunes) Description: Travel to Northern Allansia’s perilous Icefinger Mountains to defeat the wicked Snow Witch in this... | Read more »
Star Warfare 2: Payback Review
Star Warfare 2: Payback Review By Blake Grundman on October 22nd, 2014 Our Rating: :: ONE-TRICK PONYUniversal App - Designed for iPhone and iPad Unfortunately, it doesn’t take long for Star Warfare 2’s free-firing fun to turn into... | Read more »
TinType by Hipstamatic (Photography)
TinType by Hipstamatic 1.0 Device: iOS iPhone Category: Photography Price: $.99, Version: 1.0 (iTunes) Description: Create hauntingly beautiful, soul capturing portraits with TinType by Hipstamatic. Inspired by daguerreotypes,... | Read more »

Price Scanner via MacPrices.net

WD My Passport Pro Bus-Powered Thunderbolt RA...
WD’s My Passport Pro RAID solution is powered by an integrated Thunderbolt cable for true portability and speeds as high as 233 MB/s. HighlightsOverviewSpecifications Transfer, Back Up And Edit In... Read more
Save with Best Buy’s College Student Deals
Take an additional $50 off all MacBooks and iMacs at Best Buy Online with their College Students Deals Savings, valid through November 1st. Anyone with a valid .EDU email address can take advantage... Read more
iPad Air 2 & iPad mini 3 Best Tablets Yet...
The new iPads turned out to be pretty much everything I’d been hoping for and more than I’d expected.”More” particularly in terms of a drinking-from-a-firehose choice of models and configurations,... Read more
Drafts 4 Reinvents iOS Productivity App
N Richland Hills, Texas based Agile Tortoise has announced the release of Drafts 4 for iPhone and iPad. Drafts is a quick capture note taking app with flexible output actions. Drafts 4 scales from... Read more
AT&T accepting preorders for new iPads fo...
AT&T Wireless is accepting preorders for the new iPad Air 2 and iPad mini 3, cellular models, for $100 off MSRP with a 2-year service agreement: - 16GB iPad Air 2 WiFi + Cellular: $529.99 - 64GB... Read more
Apple offering refurbished Mac Pros for up to...
The Apple Store is offering Apple Certified Refurbished 2013 Mac Pros for up to $600 off the cost of new models. An Apple one-year warranty is included with each Mac Pro, and shipping is free. The... Read more
Select MacBook Airs $100 off MSRP, free shipp...
B&H Photo has 2014 a couple of MacBook Airs on sale for $100 off MSRP. Shipping is free, and B&H charges NY sales tax only. They also include free copies of Parallels Desktop and LoJack for... Read more
13-inch 2.5GHz MacBook Pro on sale for $100 o...
B&H Photo has the 13″ 2.5GHz MacBook Pro on sale for $999.99 including free shipping plus NY sales tax only. Their price is $100 off MSRP. Read more
Strong iPhone, Mac And App Store Sales Drive...
Apple on Monday announced financial results for its fiscal 2014 fourth quarter ended September 27, 2014. The Company posted quarterly revenue of $42.1 billion and quarterly net profit of $8.5 billion... Read more
Apple Posts How-To For OS X Recovery
OS X 10.7 Lion and later include OS X Recovery. This feature includes all of the tools you need to reinstall OS X, repair your disk, and even restore from a Time Machine backup. OS X Recovery... Read more

Jobs Board

Senior Event Manager, *Apple* Retail Market...
…This senior level position is responsible for leading and imagining the Apple Retail Team's global event strategy. Delivering an overarching brand story; in-store, Read more
*Apple* Solutions Consultant (ASC) - Apple (...
**Job Summary** The ASC is an Apple employee who serves as an Apple brand ambassador and influencer in a Reseller's store. The ASC's role is to grow Apple Read more
Project Manager / Business Analyst, WW *Appl...
…a senior project manager / business analyst to work within our Worldwide Apple Fulfillment Operations and the Business Process Re-engineering team. This role will work Read more
*Apple* Retail - Multiple Positions (US) - A...
Job Description: Sales Specialist - Retail Customer Service and Sales Transform Apple Store visitors into loyal Apple customers. When customers enter the store, Read more
Position Opening at *Apple* - Apple (United...
…customers purchase our products, you're the one who helps them get more out of their new Apple technology. Your day in the Apple Store is filled with a range of Read more
All contents are Copyright 1984-2011 by Xplain Corporation. All rights reserved. Theme designed by Icreon.