Project life cycle, ...the process

Firstly, forget technology, (i.e. computers, software, databases, etc.). Thoroughly learn the customer's requirement or business process. Start with strategic concepts. Then develop a construct as a process, (i.e. systematical arrangement of goal satisfying procedures), as oppose to a technical application.

Secondly, the entire team story boards the customer's requirement to fully understand the intent of the project's end deliverable. Likely employ a domain specific development tool to contain a specific objected-based model.

Thirdly, begin working towards the end deliverable by writing a fully extendable pattern-based framework.

Regarding patterns: although groups and consortiums have authored elements of reusable object-oriented software as "patterns," it is significant to define a pattern. A pattern is a three part rule expressing a relation between a certain context, a problem, and a solution, (Alexander, C. 1979). A pattern is at once both an instruction and a thing specific to the real world. A pattern is only sufficient when it is both a functional component, (i.e. thing), and also sets the rule(s) instructing how to create or recreate that thing.

Which patterns to use? Consider the customer's requirement or business process. There are traditional processes for a company to amass wealth and therefore succeed. In one approach, a company can employ distinctive competencies and set its products and services apart from the competition (Luftman & Brier, 1999). Differentiation or uniqueness will attract customers away from competitors and therefore gain a market share advantage (Porter, 1980). As such, since the customer's requirement or business process is likely unique, then shall be the patterns used to develop software. Simply falling back on tried and true patterns is insufficient.

Erich Gamma, and others identified as The Gang of Four, will be first to suggest their catalog of 23 well-known patterns are simply just the start. Their effort was simply to provide a recognizable landmark-like language criteria, (i.e. common design vocabulary), to begin the study of patterns. Therefore, since differentiation and uniqueness are bedrock to business success, the true effort is to prepare a set of patterns based on abstract classes, and perhaps more correctly interfaces, affording inheritance-driven polymorphism. The result or fallout would likely include natural extendibility.

Returning to "...the process", commence an iterative test-driven coding process based on the directives within the framework. Test-driven signifies unit tests reflecting constructs of the project are developed first. Then code is developed to resolve the unit tests. Use of a code coverage tool is necessitated. Codify and iteratively review all new discovery with both team and customer. Within an automated "nightly build" process continually build and alpha test all components with legitimate front-to-back framework-based test harnesses. Unit testing at this level is insufficient. Further, venturing outside the framework likely indicates special purpose programming, (i.e. spaghetti code), which is abhorrent.

Alpha test failures identified as syntactical necessarily shall be corrected at earliest opportunity. Alpha test failure resulting from product construct and framework omission necessitates an iterative meeting process requiring attendance of architectural personnel. This will require customer notification as well.

Nearing the end of development employ beta testing by an independent panel. Regard beta test failures, and subsequent fixes, as new discovery, not as "bugs." If there are syntactical errors, (i.e. bugs), at the beta test stage, then unit testing and test driven development has failed and there needs to be a project re-assessment.

Make customer deliverable beta release for customer approval. Iterate through the customer approval beta test until customer accepts entire project. Make final delivery.

Reality vs, ...the process. Reality dictates there are three fundamentals to software development, 1) timely delivery, 2) quality, and 3) features. Largely timely delivery is dictated by consumer interest, market and channel conditions, the economy, first-to-market advantages, and financial leverage. Businesses can not pick and choose when their products or services will be popular. That is up to the consumer. Therefore only quality and features remain as adjustable measures to ensure timely delivery. It is academic. What good is a feature if its quality is poor? Therefore, features are on the chopping block and first to go.

Alexander, C. (1979). The timeless way of building. New York: Oxford University Press.

Luftman, J., & Brier, T. (1999, Fall). Achieving and sustaining business-IT alignment. California Management Review, 42(1), 109-121.

Porter, M. (1980). Competitive strategy: Techniques for analyzing industries and competitors. New York: The Free Press.

Copyright Brian Smith PhD, San Diego CA 2005-2011

QCRT

From a business standpoint QCRT is an approach guided by paradigms, (i.e. prudent use of models, macros and templates). Additionally, if business managers avail themselves of paradigms, then they must do so while gaining a competitive edge. Therefore, business managers need accurate models [paradigms] to define the competition, the value chain and even their customers while at the same time reduce costs, manage risk, and improve product or service timeliness and quality. That is asking for nirvana, or at least utopian perfection. Truthfully, we are not going to find that largely from a truth Thomas S. Kuhn wrestled with. Kuhn, a foundational force behind the post-Mertonian scientific criteria, found himself hip deep in mire trying to explain why what is true today, was not true in the past, and likely will not be an absolute in the future. There is a reason for that. It is a matter of evidence.

Regarding evidence: paradigms are like the justice system in the USA. The law assumes the defendant is innocent until proven guilty. The burden of proof lies with the prosecution. If the evidence is sufficient then there is a conviction. If the prosecution fails to get a conviction, it does not prove the defendant is innocent. It only proves there was not enough proof to say the defendant was guilty. Nothing in U.S. law ever proves innocence, which says a criminal can be guilty as sin, and still walk free. So the law system is not perfect. Applying that to Kuhn, he suggests there should never be a perfect paradigm. By Kuhn's design, there is only enough proof to prove that prior knowledge is false. The paradigm should be left open-ended enough to allow others to prove it all factual and carry on the research, (Kuhn, 1996, p. 10). In other words, Kuhn wants something else besides a lump on Newton's head to prove there is gravity.

Since Kuhn suggests there should not be a perfect paradigm, then a business/organization paradigm reflecting utopian perfection should not be obtainable either. That is largely true because of market risk, shifts in supply and demand, resource availability, inefficient labor pooling, etc. Although imperfect business paradigms nonetheless define competitors, value chains, customers, market risk factors among other instruments. Paradigms implemented as templates, models, gauges, macros, etc. allow business managers to pick a target, for instance a competitor, and make a comparison. Hopefully, the comparison will show otherwise unseen factors that once discovered will yield a competitive edge.

The assignment is to implement the paradigms. For that I suggest business software. SAP (Systems Applications and Products in Data Processing) defines business software as comprising enterprise resource planning and related applications such as supply chain management, customer relationship management, product life-cycle management, and supplier relationship management. Taking the suggestion from SAP, I reduce the granularity to QCRT, Quality, Cost, Risk and Timeliness. Perhaps better put the four critical conventions of good business are: 1) cost reduction, 2) risk management, 3) timeliness and 4) driving quality to its highest attainable level.

In today's business environment, I find the tools for QCRT founded in Data Processing, DP, and Management Information Systems, MIS. However, DP can only improve operational efficiency, and MIS can only increase management effectiveness. Moreover, being that the goal is to obtain a competitive edge, it is necessary to implement Strategic Information Systems, SIS. SIS combines DP and MIS with evolving technology to produce tools that directly improve a company's competitiveness by changing the nature or conduct of the business (Ward & Peppard, 2002, p.23). In the forefront, SIS likely changes the conduct of the business by augmenting the customer experience. SIS example: the internet allowing the customer access to company products and services.

For my part my career has largely been developing internal tools allowing access to framework technology supporting SIS, or other technologies offering access to knowledge or knowledge management. For example, At Nextwave Broadband I dreamed up the architecture for a software tool called Message Master. I had discovered that the design engineers had difficulty manually sending operational messages to hardware devices (i.e. WiMax chipsets specifically). Further, once they managed to send the message, they had difficulty interpreting any responses. For those reasons I created Message Master. Indicated by its name, Message Master allowed hardware integration engineers the opportunity to easily send an operational message to a device, and then view the response in an intelligible manner. The larger implication is my software tool allowed the team to work faster which increased timeliness and quality. Timeliness and quality are two component of QCRT 

Kuhn, T. (1996). The Structure of Scientific Revolutions (3rd ed.). Chicago: Chicago Univ. Press.

Ward, J. & Peppard, J. (2002). Strategic Planning of Information System. : Wiley.

Copyright Brian Smith PhD, San Diego CA 2005-2011