PRICE Systems

I have recently being following an animated thread on LinkedIn “Death of a Metaphor – Technical Debt.” It’s been live for 2 months with over 200 contributions from dozens of different people.  The discussion was launched by questioning whether continued use of this metaphor makes sense.  The discussion thread weaves and bobs around actually answering this question but it’s amazing how passionate the world is on this topic.  My personal opinion is that it’s a perfectly adequate metaphor because it helps create a discussion between IT and the business leaders in terms that both can understand – dollars and cents. 

Sometimes during software development decisions are made to forgo structural quality to meet some other objective – additional functional requirements, time to market, etc.  How many of us have been involved in a development project where it was more important to get the product out the door than it was to get it done right – we take short cuts with the intent to go back and do it right once the immediate fire drill is over.  The problem is that once the product is out the door and meeting the customers expectation - how do we convince the business that there is as much (maybe more) long term value in fixing a product that is seemingly working than in investing in new features that will make the product more appealing to more users.  What business leaders may not understand is the cost of continuing to maintain and grow a structurally questionable - sometimes brittle – application.  Technical debt is the monetization of that cost making it possible for IT to communicate the value to the business of creating and maintaining a structurally sound application.  Check out this blog for a good discussion of technical debt and how to prevent accruing it.  “Technical Debt gets the Message Across”. 

The IEEE published “Top 11 Technologies of the Decade” in the  January 2011 editions of the IEEE Spectrum magazine.  It should come to a surprise to no one that the Smartphone was number 1 on this list.  The answer to the author’s question “Is your phone smarter than a fifth grader” was a resounding YES![1] 

 In 1983 Motorola introduced the first hand hell cellular phone.  It weighed in at two and a half pounds, had memory capacity for 30 phone numbers, took 10 hours to recharge and had a selling price of $4000 ($8045 in 2006).  The phone was the size of a man’s head and would sustain an hour of conversation before a recharge was required.  In June of 2007 Apple announced that it was launching the iPhone which would basically integrate all of the electronic gadgets teenagers carried around in their pockets into a complete package – phone, web browser, iPod and camera.  The iPhone 5 which should be available by Fall 2011 incorporates NFC technology, an upgraded operating system with cloud integration, music streaming, voice interface, 4G connectivity and an embedded social networking tool. NFC technology makes it possible to use the phone effectively as a credit card – making payments by swiping the phone near a device that can read its information. [2][3][4][5]

The proliferation of smartphones and tablets has led (and will continue to lead) to the proliferation of mobile applications.  And it seems as there are no bounds to the kinds of applications that are being developed for smartphones.  A sampling of some popular applications is listed below:

* Chase Mobile – which allows users to check account balances and review transactions
* Angry Birds – very popular gaming software
* Facebook - allows users to report their status from anywhere
* Yelp – allows users to locate places to eat, shop , etc. along with reviews from local patrons of said establishments

The list goes on but clearly if you can dream it – there’s an app for that (or at least there could be an app for that).  As practitioners in the art of estimation, all this mobile application development leads to the inevitable question of what does it cost to develop mobile apps and how is mobile application development different from more traditional forms of development? 
Mobiles apps can be categorized as either native applications – which run entirely on the device or web applications - with small clients resident on the device which interact with applications running on a remote server.  It appears that in general the web applications are less complex than the native ones, and thus less effort is required to build, test and deploy them.
While mobile application development is still in its infancy so a lot of what is going on in the industry now has a bit of the Wild West feel to it.  This stage of any technology is impacted by learning curve issues which may dampen productivity but at the same time there is the newness factor – where smart people are excited about the promise of new technologies and are willing to work extra hard to make things happen.  So while there is some effort/cost data available for mobiles apps, we must temper our enthusiasm.
Another concern when developing mobile applications is which platform(s) it is being developed for.  If an application is being developed for iPhone, Android and Blackberry the effort is significantly increased.  Although there are elements of the design that can certainly transcend platforms, each of these platforms has its own operating system and development environment. There are additional potential compatibility issues in cases such as Android where there are multiple companies manufacturing devices. Additionally, application developers need to determine which versions of OS for each of the platforms the application will work with.  They also need to be aware of and respect the user interface guidelines developed for the device(s) for which they are building apps.
Mobile applications may need to respond to various forms of external data from sensors, a real or virtual keypad, a GPS, microphones, etc.  They also may need to respond to movements of the actual device as well - so the screen adjusts when the user changes the orientation of the device.  There are also many instances where mobile apps will need to interact with other applications on the device.  Often the mobile application will need to share elements of the user interface with other applications. 
Mobile applications need to be developed in such a way as to limit the consumption of resources.  No matter how good your killer app is, if it drains the phone battery in half an hour no one is going to use it.  Along with all other applications that have access to the Internet, they should be built with a focus on security so that the users data is protected from malicious intrusions.
All of the issues listed above are likely to impact the complexity of the development effort of the mobile application – thus they have the potential to be an important part of the cost equation as well.  In many cases mobile applications are smaller than traditional applications so increased complexity may be offset because the projects and corresponding project teams are small.  Still this increased complexity is important to consider.
Another area where mobile apps are dramatically different than traditional apps is in the testing of the application.  Simulators and emulators exist and can be helpful in some circumstances but they are not always easy to use, effective or efficient.  There are also issues, with some platforms around the maturity of the technology that allows applications to be transferred from the development environment to the mobile device – further complicating the testing process.  Finally there is just the sheer magnitude of making sure that the application functions correctly on all the combinations of hardware, operating system and carriers on which it will be expected to perform.  The cost and effort associated with testing may present significant differences when being evaluated for mobile applications.
Smartphones are here to stay and more and more businesses will want (or need) to develop apps for them in order to remain competitive.  With the technology still relatively immature there is limited data that will help us develop cost models but there is feedback from the field on what issues are most likely to impact costs.  Though the technology is still emergent – there is some data available from commercially based mobile app developments – so at least we have a place to start.
Share your experiences with mobile application development by leaving a comment for this post.

[1] Ross, Philip E., “Top 11 Technologies of the Decade”, IEEE Spectrum, January 2011
[2]  http://www.motorola.com
[3] http://www.apple.com
[4] http://en.wikipedia.org/wiki/Mobile_phone
[5]http://www.ibtimes.com/articles/170418/20110628/quick-look-at-iphone-5-features-as-september-release-date-looks-probable-nfc-camera-8mp-lte-4g-displ.htm

Check out this Report on Big Data from McKinsey & Company published in June 2011. 

Back in the day, when personal computers were becoming widely accepted and Microsoft Windows© was the new cool thing, SneakerNet was a common means of sharing data.   Certainly the introduction and subsequent improvements of networking technology and the Internet have made data sharing a whole lot easier and quicker.  But the concept of Big Data creates a whole new level of opportunity and potential for collecting and using data in ways heretofore unthinkable.

So what is Big Data?   According to the report referenced above – “Big Data” refers to datasets whose size is beyond the ability of typical database software tools to capture, store, manage and analyze.  The authors are cautious not to declare a specific size since lightening fast technology advances may quickly make their number wrong thought they do propose currently that datasets in the few terabytes to several petabytes (1000’s of terabytes).  (hmm… I just had to add petabytes to my Word® 2007 dictionary).  The concept of Big Data requires the collection of data from multiple sources (sensors, smartphones, GPS’s, social media postings, data collected by government agencies, etc.) and performing analysis of that data in ways that will make life better and bring more value to businesses, consumers, citizens, etc.
Some examples of Big Data types of applications include;

* Marketing  initiatives like Amazon.com’s “you might also want …” admonition based on information available about your buying patterns and the buying patterns of those purchasing the same item

* Applications like RedLaser which lets a shopper scan a bar code of an in-store item with their smartphone and get immediate price and product comparisons

* Improved supply chain management through access to data across the supply chain helping manufacturers optimize planning and delivery of new products

* Mobile phone apps that allow merchants to track customers from the moment they enter the store to determine traffic patterns and flows through shelves and displays

* Capabilities like OnStar ® where sensors in the automobile send real time data to the service if the airbags deploy or to alert that a system is malfunctioning.

* Capabilities like ShopAlert that sends coupons or offers to smartphones of subscribers when they are in the vicinity of a store, restaurant or bar

The report actually contains a lot more examples across various platforms and sectors.  They have specifically Health Care, Public Sector, Retail, Manufacturing and the ever growing business of using personal location data.  Within each of these categories – opportunities for creating value as well as potential barriers to adoption are presented.

While the technology and the possibilities create lots of excitement – there are also some areas of concern – how much personal data is too much and how close do we want “Big Data” to look like “Big Brother”.   Certainly there are lots of issues that need to be addressed at all different levels before Big Data goes wildly mainstream – but it seems to me that the possibilities for value and capability will, in many cases, be worth it. 

How have you seen Big Data used?  What possibilities can you see for Big Data applications?  Leave a comment to this post to share your Big Data stories.

PRICE Systems is involved with the formulation of the total Life Cycle/Whole Life of systems of systems and is asking the question, "Is the META 'V' on the right track?"

INCOSE is considering the total life of the system, the traditional Development Engineering V must be expanded to account for the life of the system beyond Initial Operational Capability.  In this writer's opinion, we have to extend the development V to account for this with this Meta-V concept.  The Affordability Working Group recognizes that IOC is:

·        The initial release of both the Primary and Enabling system; and the initial release of a successful system continues to evolve to meet environmental changes. Further, monitoring and feedback are integral parts of the evolutionary process.

PRICE Systems is integral in the INCOSE Design for Affordability Initiative as a vital member of the Working Group Internationally.

The INCOSE Affordability Working Group’s definition of Affordability is:

Affordability is the balance of system performance, cost and schedule constraints over the system life while satisfying mission needs in concert with strategic investment and organizational needs.

The INCOSE Affordability Working Group’s definition of SE Design for Affordability is:

Design for Affordability is the Systems Engineering practice of balancing system performance and risk with cost and schedule constraints over the system life satisfying system operational needs in concert with strategic investment and evolving stakeholder value.

To meet the Affordability Working Group goals we need to move from the conceptual to the concrete (i.e., how do we demonstrate that the affordability of a system has been improved; or define the trade space).  To do this, we can decompose the definitions into their potential constituent parts.  The definitions lead to considering three constituents for affordability:

Which represent the central concept of affordability as “Cost of Capability over time.”

a.      Required Capability – what does the system contribute to the mission or the next higher System Context, or How does the system generate operational value? e.g., search, detection, rescue, transport

b.      Required Capability Performance – How well must the system perform the required capability, e.g., defeat X% of the threats, detect Y% of the targets, or top speed of N kts. How do we measure?

c.      Budget, Risk and Schedule – Resources, technical, financial & temporal available to provide the capabilities and needed performance (system value). How do we measure?

System Life Cycle or Affordability over time

It is important to note that there is a significant difference between the INCOSE approach and the Gate’s definition.  That is, INCOSE is addressing the entire system life cycle while Gate’s considers “conducting a program”.  This is a significant difference as the B-52 is a single system; however, there have been many programs over the life of B-52 system.  Since INCOSE is considering the total life of the system, the traditional Development Engineering V must be expanded to account for the life of the system beyond Initial Operational Capability.The Affordability Working Group recognizes that IOC is:

·        The initial release of both the Primary and Enabling system; and

·        The initial release of a successful system continues to evolve to meet environmental changes.

Further, monitoring and feedback by PRICE Systems as a member of the INCOSE Working Group are integral parts of the evolutionary process.

Open Source software is software that is distributed publically with all of its source code.  Users of open source software are encouraged to review the source code, make changes to it and share those changes with the rest of the user community.  The value in open source is that providing the source code to the user community allows those in the community who are willing and able to make improvements, add features, and fix bugs. Open source takes the notion of peer review to the next level.   It means that instead of just a development team, the entire user community can potentially be collaborating to make the code better.  Even those members of the user community that are not technically savvy are encouraged to contribute to the quality of the software.  The premise for open source is that the more varied views and perspective that go into crafting and growing a software application, the more that application will deliver customer delight.  Eric Raymond in his essay The Cathedral and the Bazaar  likens the model of developing open source software to a “great babbling bazaar of differing agendas and approaches".  

Given this you would think that government organizations would be hesitant to venture into the use of open source but I was pleasantly surprised when I happened upon this website .  The NASA Open Source Agreement is an Open Source Initiative (OSI) approved license to allow public release of NASA funded software.  NASA believes that open source software is revolutionizing the way that software is created, improved and used.  They think it is the best way to keep the public apprised of what they are doing and a great way for students, scientists and programmers to contribute their expertise and skills to NASA endeavors.

The PRICE Calculator for Electronics Manufacturing Complexity, shown below, has a subtle but very powerful feature for Quality Adjustment, based on Mil-Hdbk-217E Quality Levels. 

 The above shows “None” which yields the standard MCPLXE, in this case a 8.07 value applying 100% Large Scale Integrated Circuits for Display (with CRT) equipment as an example. Yet, in the course of estimating a mission-critical automatic tester  with multiple controller-card assemblies for an airborne-military platform, I adjusted for more stringent quality levels—specifically “S-1” level consistent with Mil-Std-975/ Mil-Std-1547 per below.

Note that for military airborne platforms, as well as manned and unmanned space, the default is a “B” quality level. {For military mobile and ground, the defaults are “B-1” and “B-2” respectively.} The result of adjusting up to a more stringent “S1” quality/tolerance level was a much higher 8.94 MCPLXE value which significantly drove up costs. Out of curiosity, I did sensitivities on these quality levels, from “S” down to “D-1” {again B-1 & B-2 are moot} as shown in the boxed center column “Display” below (in purple).

As you can see, all electronic types (in this airborne military specification) are highly sensitive to quality levels. Graphically, we have the following results. 

 

Rule of thumb: when the quality requirement is in question— ask!

Check out this article from CIO magazine about managing your project budget.   The author, Jason Westland, suggests four things necessary to maintain control of your project budget.  While these are not earth shattering suggestions, sometimes project managers in the throes of a project can lose sight of their importance.  The strategies are:

* Continually forecast the budget
* Regularly forecast resource usage
* Keep the team informed
* Manage scope meticulously

Or to put it another way – respect and revisit the Project Management Triangle.  (To learn more about the Project Management Triangle go to this link  and look for the “Respect the Triangle: Scope, Time and Cost” paper)   Successful projects require constant vigilance around scope, people, dollars and the calendar.  The Triangle is an excellent tool for project leaders to use as a visual tool to facilitate negotiations with customers when things change in a project (and things will change!).  You can also check out my webinar on this topic.

How do you keep your projects in check?

There is a ton of code out there and we’re constantly adding more.  Gartner reported in 2009 that there were more than 310 billion lines of code in use worldwide. MS Word has grown from 27,000 lines of code in the first version to about 2 million in 2010.  The Windows Operating System grew from 3 million lines of code in 1992 to 20 Million in 1998.  You get the point – there’s lots of code out there doing lots of the same things that we may want our software to do.

One of the challenges software project leaders have in estimation and planning is successfully quantifying the functionality they can reuse and understanding and communicating the effort and cost associated with that reuse.  In projects where significant reuse is anticipated, reuse is really going to shape the project.  Reuse comes in many forms.  A firm grasp of the types of reuse and the potential pitfalls of such reuse facilities a thorough analysis of the impacts that reuse has on the project.  It is ill advised to expect to get a one to one benefit for reuse.  It is even more problematic to plan on reuse as a quick fix to schedule pressure.  

Some of the things you want to consider:

* Reusing legacy code can be a great productivity booster if the code is stable, well written and some of the original developers are on hand.  On the other hand, if you’re working with legacy code that has become spaghetti code which is only supported by a mildly deranged programmer in the corner cube – you might be better off starting from scratch
* The auto translation of existing code to newer technologies can also boost project productivity but one cannot expect the process to be transparent or without hiccups.  It is important to understand the nature of the translation tool, the amount of preparation required to use it and the expected amount of human intervention to make the translation complete
* The use of Commercial Off the Shelf Software (COTS) can significantly impact the schedule for a software project but there needs to be a thorough evaluation of the capabilities of the COTS against the requirements of the project.  There also needs to be acknowledgement with the consumer of the software system that using COTS software limits the amount of customization possible resulting in the risk that the finished product is not exactly what they expected.

Also it is often more complicated to integrate reused (not developed here) solutions since there is a steeper learning curve during the integration phase.  Code reuse can be a great way to achieve increased productivity but it is important not to assess this improvement over optimistically but rather through a careful appraisal of what the reuse activity entails.

Have a reuse story (success of horror) you want to share?  Post it as a comment to this blog.