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.

 

Community Search:
MacTech Search:

Software Updates via MacUpdate

1Password 6.5.5 - Powerful password mana...
1Password is a password manager that uniquely brings you both security and convenience. It is the only program that provides anti-phishing protection and goes beyond password management by adding Web... Read more
Apple Remote Desktop Client 3.9 - Client...
Apple Remote Desktop Client is the best way to manage the Mac computers on your network. Distribute software, provide real-time online help to end users, create detailed software and hardware reports... Read more
Art Text 3.2.2 - $49.99
Art Text is graphic design software specifically tuned for lettering, typography, text mockups and various artistic text effects. Supplied with a great variety of ready to use styles and materials,... Read more
WhatRoute 2.0.15 - Geographically trace...
WhatRoute is designed to find the names of all the routers an IP packet passes through on its way from your Mac to a destination host. It also measures the round-trip time from your Mac to the router... Read more
Sparkle 2.1.1 - $79.99
Sparkle will change your mind if you thought building websites wasn't for you. Sparkle is the intuitive site builder that lets you create sites for your online portfolio, team or band pages, or... Read more
Dash 4.0.1 - Instant search and offline...
Dash is an API documentation browser and code snippet manager. Dash helps you store snippets of code, as well as instantly search and browse documentation for almost any API you might use (for a full... Read more
TextSoap 8.3.2 - Automate tedious text d...
TextSoap can automatically remove unwanted characters, fix up messed up carriage returns, and do pretty much anything else that we can think of to text. Save time and effort. Be more productive. Stop... Read more
Apple Remote Desktop 3.9 - Remotely cont...
Apple Remote Desktop is the best way to manage the Mac computers on your network. Distribute software, provide real-time online help to end users, create detailed software and hardware reports, and... Read more
Paragraphs 1.1.4 - Writing tool just for...
Paragraphs is an app just for writers. It was built for one thing and one thing only: writing. It gives you everything you need to create brilliant prose and does away with the rest. Features... Read more
Amazon Chime 4.0.5528 - Amazon-based com...
Amazon Chime is a communications service that transforms online meetings with a secure, easy-to-use application that you can trust. Amazon Chime works seamlessly across your devices so that you can... Read more

Blasty Bubs is a colorful Pinball and Br...
QuickByte Games has another arcade treat in the works -- this time it's a mishmash of brick breaking and Pinball mechanics. It's called Blasty Bubs, and it's a top down brickbreaker that has you slinging balls around a board. [Read more] | Read more »
Corsola and Heracross are the new region...
Generation 2 finally launched in Pokémon GO, unleashing a brand new batch of Pokémon into the wild. Even before the update went live people were speculating on how to catch elusive Pokémon like the legendary "dogs", Unknown, and whether or not... | Read more »
The Warlock of Firetop Mountain (Games)
The Warlock of Firetop Mountain 1.0 Device: iOS Universal Category: Games Price: $4.99, Version: 1.0 (iTunes) Description: An epic adventure through a mysterious mountain filled with monsters, magic and mayhem! “...it looks downright... | Read more »
Fantasy MMORPG MU Origin’s receives a hu...
Developer Webzen are looking to take their highly popular fantasy battler MU Origin to the next level this month, with its most ambitious overhaul yet. The latest update introduces the long sought after Server Arena, new treasure dungeons, and much... | Read more »
RPG Djinn Caster (Games)
RPG Djinn Caster 1.0.0 Device: iOS Universal Category: Games Price: $4.99, Version: 1.0.0 (iTunes) Description: SPECIAL PRICE 38% OFF(USD 7.99 -> USD 4.99)!!!A Fantasy Action RPG of far foreign lands! Summon the Djinns and rise to... | Read more »
Alto's Odyssey gets its first trail...
There's finally video evidence of Alto's Odyssey, the follow up to the 2015 App Store hit, Alto's Adventure. It looks just as soothing and atmospheric as Alto's last outing, but this time players will be journeying to the desert. Whereas Alto's... | Read more »
Last week on Pocket Gamer
What’s going on in the wider world of portable gaming? Each week we ask that question of our sister website Pocket Gamer. The PG team covers iOS gaming, just like 148Apps, but it also strays into the world of Android games and handheld consoles... | Read more »
Pokémon GO Generation 2 evolution guide
At long last, Niantic Labs finally unleashed the Generation 2 Pokémon into the wild. Pokémon GO trainers are scrambling to grab up this new set of 80 Pokémon. There are some special new tricks required to catch all of these new beasties, though.... | Read more »
The best new games we played this week
It feels as though the New Year got off to a creaking start as far as mobile games go, but that's changed over the past few weeks. The last few days alone have seen the debut of a number of wonderful games, so we thought we'd take the time to... | Read more »
Recruit more scallywags and discover new...
Get ready to show off your sea legs all over again in Oceans & Empires’ new grand update, which aims to make the act of rising to the role of seven seas ruler even more fresh and appealing, thanks to a richness of new content on both iOS and... | Read more »

Price Scanner via MacPrices.net

Apple’s New iPad Ads Don’t Address Pro Users’...
Apple launched a new tranche of iPad Pro TV ads last week addressing actual queries and challenges from the Twitterverse, albeit using actors for the visuals. That’s great. As an iPad fan and heavy... Read more
Free Verbum Catholic Bible Study App For iOS
The Verbum mobile app runs on Logos’ powerful Bible software and is an advanced resource for mobile Catholic study. The Verbum app surrounds the Bible with the Tradition. Verbum comes with 15 free... Read more
27-inch Apple iMacs on sale for up to $200 of...
B&H Photo has 27″ Apple iMacs on sale for up to $200 off MSRP, each including free shipping plus NY sales tax only: - 27″ 3.3GHz iMac 5K: $2099.99 $200 off MSRP - 27″ 3.2GHz/1TB Fusion iMac 5K: $... Read more
15-inch 2.2GHz Retina MacBook Pro on sale for...
Amazon has 2015 15″ 2.2GHz Retina MacBook Pros (MJLQ2LL/A) available for $1849.99 including free shipping. Apple charges $1999 for this model, so Amazon’s price is represents a $150 savings. Read more
Apple refurbished iPad Air 2s available start...
Apple has Certified Refurbished iPad Air 2 WiFis available for starting at $319 including free shipping. A standard Apple one-year warranty is included: - 16GB iPad Air 2 WiFi: $319 $60 off original... Read more
Apple refurbished iPad Pros available for up...
Apple has Certified Refurbished 9″ and 12″ Apple iPad Pros available for up to $160 off the cost of new iPads. An Apple one-year warranty is included with each model, and shipping is free: - 32GB 9″... Read more
Apple restocks refurbished 2015 and 2016 13-i...
Apple has Certified Refurbished 2015 and 2016 13″ MacBook Airs available starting at $759. An Apple one-year warranty is included with each MacBook, and shipping is free: - 2016 13″ 1.6GHz/8GB/128GB... Read more
13-inch 2.5GHz MacBook Pro (Apple refurbished...
Apple has Certified Refurbished 13″ 2.5GHz MacBook Pros (MD101LL/A) available for $829, or $270 off original MSRP. Apple’s one-year warranty is standard, and shipping is free: - 13″ 2.5GHz MacBook... Read more
QuickerTek Announces 5TB Apple AC AirPort Tim...
QuickerTek Inc. has announced their new 5TB hard drive upgrade for Apple’s AC AirPort Time Capsule. By customer request, this upgrade also features six external antennas and offers the highest... Read more
Apple Certified Refurbished iMacs available f...
Apple has Certified Refurbished 2015 21″ & 27″ iMacs available for up to $350 off MSRP. Apple’s one-year warranty is standard, and shipping is free. The following models are available: - 21″ 3.... Read more

Jobs Board

*Apple* Retail - Multiple Positions - Apple,...
Job Description: Sales Specialist - Retail Customer Service and Sales Transform Apple Store visitors into loyal Apple customers. When customers enter the store, Read more
Manager *Apple* Systems Administration - Pu...
Req ID 3315BR Position Title Manager, Apple Systems Administration Job Description The Manager of Apple Systems Administration oversees the administration and Read more
*Apple* Retail - Multiple Positions - Apple,...
Job Description: Sales Specialist - Retail Customer Service and Sales Transform Apple Store visitors into loyal Apple customers. When customers enter the store, Read more
Manager *Apple* Systems Administration - Pu...
Req ID 3315BR Position Title Manager, Apple Systems Administration Job Description The Manager of Apple Systems Administration oversees the administration and Read more
*Apple* Technician - nfrastructure (United S...
Let’s Work Together Apple Technician This position is based in Portland, ME Life at nfrastructure At nfrastructure, we understand that our success results from our Read more
All contents are Copyright 1984-2011 by Xplain Corporation. All rights reserved. Theme designed by Icreon.