iPhone development part 1

Let’s take a detailed took at the landscape for iPhone development, enumerating the different ways to build iPhone Apps and also the tools available to help in the same. iPhone is the biggest thing to happen to the mobile world in real times. The amazing screen and other browsing features has made the Apple iPhone the most popular web browsing mobile device. The same features have also resulted in developers salivating over an opportunity to create iPhone Apps. We first discuss the two fundamental ways to build iPhone Apps and point you to important resources which will help you get started on them as soon as possible.

Basically there can be two different ways that you can write applications for the iPhone:
1. Web Applications (work via browser & networks)
2. Applications (phone based can be network independent for our current understanding)

Web Applications are applications that run of the Safari browser on the iPhone. These applications are typically web applications with their interface and layout customized to suit the browsing communications that have emerged for the iPhone.

I use the word “communication” s specifically to emphasize the fact that web applications need to not only change the layout and appearance to suit the iPhone, but also at the same time rethink usability (not design) to suit the new browsing patterns that have come with the iPhone.

Let’s discuss more on these “Web Applications”

As previously mentioned iPhone Web applications are essentially web applications which run of the Safari browser on the iPhone. The major difference from native web applications is that they cannot access the hardware features like accelerometer, file system etc. They are constrained to run in the sandbox of the browser which is similar to other web applications.

The easiest way to build iPhone web applications is to take your existing web applications and fix the layout so that they match the layout guidelines on the iPhone. The biggest change that this would require is to reduce your real estate to match the size of the iPhone. Also the navigation and usability needs to be changed to better suit the iPhone usability idioms.

The biggest usability change that can be seen in iPhone web applications is the streamlining and extreme focus that it has bought to existing web applications. Instead of the typical web pages which are crammed with content, navigation, lists, advertisements, promotions in every nook and corner, iPhone web applications need to be extremely streamlined and focussed in their approach.

This streamlining and focus is achieved with categorizing every page into only two different kind of layouts. These layouts are firstly a list based layout and secondly an action based layout. What this means that any existing web application need to be broken down into independent screens, each of which need to be either a list based screen or a single action based screen. This is apart from the additional navigation which can be provided in the form of a Next/Previous buttons in the top bar or a tab based navigation.

There are already a lot of tools which help you convert your existing web applications into iPhone applications. Below we mention two of them which probably might be the only thing you need to build iPhone web applications.

Applications are applications that are run on the iPhone itself. These applications are developed largely in Objective-C (a variant of the popular C language) and use the iPhone specific features which are exposed using the Cocoa API on the iPhone.

Obviously, as native applications run directly on the iPhone they have much better access to the iPhone hardware and can use them effectively. And exclusively the iPhone hardware dependant.

Phone applications are applications which run directly on the iPhone hardware. These applications can take advantage of the wide range of hardware innovations that come with the iPhone. These include support for multi-touch, hand gestures, iPhone camera, accelerometer and the built in GPS.

However phone applications are much harder to build as compared the web applications. And if you are not too much into programming the complex syntax of Objective-C will present to you a very steep learning curve. On the plus side, those who have scaled this curve can use their programming chops to cook up some of the most innovative applications that are getting enabled by the iPhone. Add to that the instant recognition and money that a lot of developers have earned by listing on the iPhone App store, and that should be motivation enough for you to start hacking right now.

Native applications unfortunately require you to invest in Apple hardware if you don't already have some. At the minimum you would need a Mac because the iPhone SDK currently only runs on one. Secondly, you would need an actual iPhone. Even though the SDK comes built in with an iPhone simulator this is not enough because a lot of features don't run the same as on an actual iPhone. Case in point is the accelerometer and multi-touch support both of which are not supported on the emulator.

There essentially two big pieces of technology you need to master to build iPhone native applications: Cocoa and Objective-C.

Cocoa is the platform and the API that iPhone exposes for you to access the low level iPhone functionality. Apart from this Cocoa also provides the infrastructure to build simple form based applications for the iPhone. As Apple provides exhaustive documentation on the Cocoa API it is pretty straightforward to get started on.

Objective-C is the variant of the popular C language which is used for the iPhone development. Objective-C is pretty much the same as C/C++ apart from the way it structure functions and message passing. Message Passing, or the way Objective-C structures functions calls are a much more object oriented way of programming, however the syntax takes some time to getting used to. Apart from Cocoa and Objective-C in case your native application is graphics heavy (for example games) it might need to use Open GL to build the graphics part. Open GL is an open source graphics library and is supported on the iPhone.

I believe this is more than required for theory now lets dwell more on how to implement this. So next step we will understand about creating a simple iPhone / iOS application.

Estimation Basic Order of magnitude estimate and WBS

This is what most of us face when starting off a new project. New technology, teams unfamiliar with the technology or domain, or unclear requirements ensure that this will probably be the fast & optimal estimate as per time & information availability we can provide.

Break the project down into the different tasks needed. Try to get as many tasks as possible. A useful way to break down tasks is to consider typical software activities such as analysis, design, build, demo, test, fix, document, deploy, and support and see if they are required for each task and whether they need to be broken out into new tasks. We can have a simple standard table to choose from at departmental level. Evaluate each task on two scales: complexity (high, medium, low) and size of work (large, medium, small). A less complex task may still involve a large amount of work; for example, loading a database with information from paper forms may take several weeks. A very complex task may not involve much actual work but can still take a lot of time, as in tuning a database for optimum performance. Complex tasks are usually hard to split between many people/teams while large-size, less complex tasks can usually be split up between many people/teams.

Tasks effectively fall into one of nine combinations of complexity and size. For each combination, define an expected amount of time and resources required. For example, we could say that low complexity and small-size tasks will take one week at most, medium complexity and small-size tasks will take three weeks, and so on. These weighing factors will differ based on the team and project and should be reviewed after the project to help get better values the next time. Add together all these values for each task to get an estimate of time and resources required.

Size	Complexity
	Low	Medium	High
Small			1) Tune database
Medium
Large	1) Load data		1) Integrate with security system 2) Create data validation routines

Figure 1. A sample table used for doing an order of magnitude estimate.

Doing rough and fair estimates

These estimates can be done when you have a good idea of the tasks to be done and how to do them.

Those who will do the actual work are the best people to do these estimates. One then can add up all the estimates from different people to get the final estimates. Ensure you collect estimates on the three variables of time, people, and infrastructure/material needs.

Break down tasks to as detailed a level as possible or at least 2 levels. As mentioned previously, it can help to consider typical software activities such as analysis, design, build, demo, test, fix, document, deploy, and support and see if they are required for each task. Break tasks down to a granularity of eighty hours or less.

Conclusion, the preceding techniques can help one achieve better estimates. Review estimated needs versus actual needs after every project. Identify what was correct and what was wrong. This will help you improve the next time. As with many other activities, experience will help you get better!

Now let’s look at the other best practice followed in majority of IT companies, The work breakdown structure (WBS) is an effective tool in managing programs and projects. It assists both developers and contractors in fulfilling management responsibilities. In accordance with good IT organizations management of major system programs and projects, a WBS is mandatory for major system acquisitions and major projects, and will be used for other projects when practical. A WBS is required when performance measurement is applied to a contract. The purpose of WBS is to support the initial project estimation till completion of program and project objectives within budget and schedule constraints. This can be used for various work efforts including research, development, construction, test and evaluation, and operations. The products of these work efforts may be hardware, software, data, or service elements (alone or in combination).

A WBS is developed by first identifying the system or project end item to be structured, and then successively subdividing it into increasingly detailed and manageable subsidiary work products or elements. Most of these elements are the direct result of work (e.g., assemblies, subassemblies, and components), while others are simply the aggregation of selected products into logical sets (e.g., buildings and utilities) for management control purposes. In either case, the subsidiary work product has its own set of goals and objectives which must be met in order for the project objectives to be met. Detailed tasks which must be performed to satisfy the subsidiary work product goals and objectives are then identified and defined for each work product or element on which work will be performed.

Completion of an element is both measurable and verifiable by persons (i.e., quality assurance persons) who are independent of those responsible for the element's completion. Because WBS element/product completion can be verified, a WBS provides a solid basis for technical, schedule and cost plans and status. No other structure (e.g., code of account, functional organization, budget and reporting, cost element) satisfactorily provides an equally solid basis for incremental project performance assessment.

It usually consists of three levels of products/elements with associated work definitions. The three upper levels of are defined below

• Level 1 is the entire program/project.
• Level 2 elements are the major product segments or subsections.
• Level 3 contains definable components, or subsets, of the level 2 elements.
• Level 3 can be further definable components, or subsets, of the level 3elements.
• So on & so forth

Now let’s create some rules / regulations for the WBS process implementation in sample IT organization. I have tried to be as generic as possible in this.

1. The WBS is prepared as early as project definition will permit.
2. A preliminary WBS is developed in initial phase to define the top levels of a WBS for the entire project (system) life cycle. Normally, this life cycle WBS will be in two parts: one part for the acquisition cycle of the system being acquired (Phases A through D), and one part for the operations and support phase (Phase E).
3. The WBS is to be compatible with the organization Wide standard Coding Structures defined in quality process as per the need & fitments
4. A revisit WBS is prepared by compiling the elements of the WBS(s) with the new additions or modifications as per the defined standards.
5. As design concepts change, the WBS is further refined and changed to reflect new systems and subsystem approaches.
6. When a project initiated , the WBS becomes formalized as the project outline, and all changes to it should be formally approved by the program managemt office.
7. The preliminary WBS, written by estimation group / project personnel, is developed through no more than the three highest levels of the proposed contract.
8. The preliminary WBS is developed from the basic elements of the sales WBS and expanded for use in the request for proposal (RFP), preparation of proposals, and the evaluation and selection process.
9. Normally, only the top three levels of the WBS will be specified in an RFP. The WBS is considered a preliminary WBS until it is finalized as a result of negotiation and incorporated formally into the contract.
10. When high risk items are located at low WBS levels, these items can be identified against the higher-level WBS element of which the high risk item is a part. It is not necessary or desirable to extend the WBS below the top three levels in order to identify the high risk item.
11. The periodic reviews are the basic need in Agile project execution methodology as the agility implies in changing the requirements & so the effort & cost plans in our daily executions.

As we can infer, a work breakdown structure defines all work to be performed for project completion. It is a product-oriented structure, not an organizational structure. To develop and maintain a WBS, you must have a clear understanding of the project's objectives and the end item(s) or end product(s) of the work to be performed. The WBS elements should represent identifiable work products (e.g., hardware, software, data or related service products). Because of its product orientation, a WBS provides the framework to plan, track and assess the project's technical, schedule and cost performance.

A preliminary WBS is established as soon as program management believes the project has reached a stage of definition where it is feasible. It is used to assist in the preparation of the program / project initiation documents and the project plan. As now the preliminary project development process is an iterative process. During its early phases the preliminary WBS may be revised as necessary. Once the project is established in sufficient depth,

procurements may be planned by using selected WBS elements to develop preliminary schedule diagrams. Preliminary WBSs are incorporated into the RFPs, subsequent proposals, and eventually finalized in the executed contract(s) based on negotiations.

Feel free to reach me at ravindrapande@gmail.com to share thoughts & suggestions.

Business Analytics and Business Intelligence ground reality

Business intelligence and business analytics aren’t new concepts. The idea of understanding the relationships between bits and bytes of data extends back to the late 1950s, and BI has been around in earnest since the late 1980s. However, today, the ability to aggregate, store, mine and analyze data can make or break an enterprise. As a result, BI and BA have emerged as core tools guiding decisions and strategies for areas as diverse as marketing, credit, research and development, customer care and inventory management.

As CIO.com reports, BI and BA are evolving rapidly and meshing to meet business challenges and create new opportunities. Although nearly all global 5000 organizations already use these tools, 35 percent of them fail to make insightful decisions about significant changes in business and market conditions, according to IT consulting firm Gartner. What’s more, the task isn’t getting any easier as data streams become more intertwined and other Web 2.0 environments pull data from multiple sources at single instance.

I believe business intelligence and business analytics are on the cusp of a major change. There is a shift toward providing deeper insight into business information. And there is a growing emphasis on better tools and putting more powerful and better software in the hands of business decision makers today.

Business Intelligence & Business Analysts are quite disconnected in real world, at least that's what have seen in last many years of experience. BI is evolved as platform or bunch of tools, with architecture, albeit an enterprise-wide approach, lacks deep analytical and predictive capabilities. Traditionally, this is where the work of IT ends and business analytics starts, with statistical, quantitative and predictive work conducted outside of the framework.

This unfortunate reality has contributed to the myth that BA is something totally different from BI. The vision of BI always includes analytics, and BA is merely a subset of BI focused on analytical parts of business intelligence. Because the traditional BI architecture doesn't lend itself to advanced analytics capabilities, such as statistical modeling and data mining, it's not surprising business users collect data and reports from BI systems and then use their own analytics in spreadsheets they control. This approach is not a viable solution however, because uncontrollable processes and questionable data will seriously hamper a BA effort. Research studies estimate that roughly 94 percent of spreadsheets deployed in the field contain errors, and 5+ percent of cells in unaudited spreadsheets contain errors.

What we need is an analytics-oriented BI architecture that incorporates advance analytics and analytic modeling capabilities into the current BI framework. Traditional BI vendors need to build more advanced analytical functionalities within their BI offerings. Many major BI tools don't support advanced statistical and quantitative modeling. Some support limited analytics and require highly technical skills (such as SQL) for use, which most business users don't possess. BI vendors need to provide more user-friendly analytics tools with much broader capabilities for statisticians and business analysts to use without lots of IT support. These new capabilities should include predictive analytics, data mining, text analytics, simulation, decision analysis and advanced modeling.

Second, traditional analytics software vendors need to embed powerful analytical capabilities into the BI platform and make integration much easier for customers. Most BI applications and BA applications operate on very different platforms. Every company needs to reckon with integration and ROI before investment. BI and BA vendors should work together to make the integration much less painful and help customers unleash the best of both worlds.

An integrated solution combines advanced analytics with powerful data visualization and advanced reporting capabilities to support fact-based and data-driven decision-making. Under this new architecture, advanced analytics will be an integral part of BI. Analytics process and technology could be managed under one unified BI framework and strategy that ultimately should align with a company's business strategy. Initiatives such as data management and governance could benefit both BI and BA programs.

Companies that have high quality information that is well-defined and understood across the enterprise already have a solid foundation for BA. In terms of implementation, there could be different deployment approaches based on the conceptual architecture. For instance, analytic models might be built into a database or data warehouse to leverage its processing power.

In-database analytics has lots of advantages - analyzing data where it resides to avoid data movement and duplication. However, in-database analytics can be costly when analytics processes, which are volatile and adaptive in nature (as old models need to be updated or rebuilt with latest data input), are hindering other mission-critical OLTP or OLAP operations. It may lead to a separate environment for development and deployment of an analytic model. Meanwhile, advanced analytics capabilities are better built within existing BI tools for better compatibility and integration with existing BI features. Analytics could also be built into operational systems when less data integration is needed - analyzing data while capturing it. Organizations should choose the best deployment model to fit their business analytical needs.

Lastly, BA needs to be integrated and embedded in business process to be effective & efficient. One such example is to create a closed-loop style repeatable process in the normal workflow of business operations to feed the results back into the operational system where the data for analytics is sourced. This kind of decision automation is used in cases where decisions tend to be high volume. For instance, an online retailer can use an analytical model that predicts high probability of a customer buying a certain new product to attempt cross-selling by dynamically displaying ad banners when the customer visits the online store. An online bank can approve or reject loan applications automatically based on the criteria defined by the application processing rules engine using predictive analytics. Only the exceptions (rejected applications) will be sent to loan officers for review and follow-up. The model significantly reduces the cost and decision time for the bank and customers, a win/win for both.

According to my observations he key characteristics of the analytics-oriented BI architecture are:

• Integrated (data, reporting, analytics)
• Robust and flexible (for rapid changes)
• Evolving and adaptive
• Consistent (standards in process and data)
• Controlled
• Transparent (versus black-box approach) and
• Embedded (analytics as part of business process)

With the burgeoning demand in advanced analytics and emerging analytical technologies, we will see the convergence of BI and BA in the marketplace. BI megavendors will likely acquire smaller BA players and integrate advanced analytical tools and capabilities into their BI portfolios. At the same time, traditional analytics software vendors will likely push more into the BI platform
territory.The reciprocal penetration will accelerate the consolidation, standardization and adoption of analytics while moving toward an analytics-oriented BI architecture.

Historically, this market has been served by vendors such as Business Objects and Cognos. But the competitive landscape is changing. Microsoft has now shrewdly entered the market by driving the placement of SQL servers into the space in order to broadly deploy and deliver its BI suite and reporting services in volume. Oracle has seen the effect of companies moving data out of the database to stage it for analysis. The resulting data warehouses have provided a degree of utility in housing, manipulating and delivering “strategic” information across the organization.

Also every top level boss wants an effective dashboard. To the extent that all of us are CIO/CTO/CEO’s of our own business discipline, we want a simple measurement display of how we are doing and an alert mechanism of when something goes wrong. Additionally, dashboards address the growing urgency around Sarbanes Oxley. Monitoring planning assumptions and key performance metrics has now become mission critical from a regulatory and compliance standpoint. As we all know BI reporting ends with the dashboard, which is sufficient only for some business planning, and BA picks up the rest for the Go-To Guys. Simply, this group must interact with data in a much different way from what traditional BI allows. The requirement of the BI system has been to monitor the data based on pre-configured questions requiring only a thin client environment to inform the user. In the operating world, users need to engage with the information requiring a richer client to support interactivity and the ability to ask and answer their own question without having to go back to IT. Let us make one thing clear, we don’t get business analytics when you buy business intelligence. The requirements are different and the benefits are different. The return on information and expertise achieved by arming your resources, operating managers with analytics will supercharge your existing BI investment.

Do let me know your views suggestions, These thoughts I have collected from CIO.COM, Linked discussions & various discussions with Co-workers & PMI Mumbai members. Thanks to all for sharing inputs in time with free heart. I am available at ravindrapande at gmail.com

Estimation Basic Need, options Starting Part 1

As someone correctly point out you can’t control things which you can’t measure. Very true to it’s logical sense. In our software day to day life we need to measure our efforts to track, monitor & control. This thoughts lead me to create this write-up for everyone in IT age to control day to day professional life.

A Software product / projects are typically controlled by four major variables; time, requirements, resources (people, infrastructure/materials, and money), and risks. Unexpected changes in any of these variables will have an impact on an execution. Hence, making good estimates of time and resources required for a project is crucial. Underestimating project needs can cause major problems because there may not be enough time, money, infrastructure/materials, or people to complete the project. Overestimating needs can be very expensive for the organization because a decision may be made to defer the project because it is too expensive or the project is approved but other projects are "starved" because there is less to go around.

In my experience, making estimates of time and resources required for a project is usually a challenge for most project teams and project managers. It could be because they do not have experience doing estimates, they are unfamiliar with the technology being used or the business domain, requirements are unclear, there are dependencies on work being done by others, and so on. These can result in a situation akin to analysis paralysis as the team delays providing any estimates while they try to get a good handle on the requirements, dependencies, and issues. Alternatively, we will produce estimates that are usually highly optimistic as we have ignored items that need to be dealt with. How does one handle situations such as these?

Useful Estimation Techniques

Before we begin, we need to understand & categorize what types of estimates we can provide. Estimates can be roughly divided into these types:

Initial estimates/ Ballpark or order of magnitude: Here the estimate is probably an order of magnitude from the final figure. This can be within two or three times the actual value.

Rough estimates: Here the estimate is closer to the actual value. Ideally it will be about 50% to 100% off the actual value.

Fair estimates: This is a very good estimate. Ideally it will be about 25% to 50% off the actual value.

Deciding which of these three different estimates you can provide is crucial. Fair estimates are possible when you are very familiar with what needs to be done and you have done it many times before. This sort of estimate is possible when doing maintenance type work where the fixes are known, or one is adding well-understood functionality that has been done before. Rough estimates are possible when working with well-understood needs and one is familiar with domain and technology issues. In all other cases, the best we can hope for before we begin is order of magnitude estimates. Some may quibble than order of magnitude estimates are close to no estimate at all! However, they are very valuable because they give the organization and project team some idea of what the project is going to need in terms of time, resources, and money. It is better to know that something is going to take between two and six months to do rather than have no idea how much time it will take. In many cases, we may be able to give more detailed estimates for some items rather than others. For example, we may be able to provide a rough estimate of the infrastructure we need but only an order of magnitude estimate of the people and time needed.

For a given scenario let’s think it thru with a role of a well educated developer, whether any project manager planning for a smooth implementation of a plan or a project sponsor on whose decisions a project depends, you cannot escape from the fact that project estimation is essential to its success. In the first place, there are three basic requirements that a project must satisfy: schedule, budget, and quality. The need to work within these essential project boundaries poses a huge challenge to everyone in the central management team.

There are various aspects that affect project estimates, such as team skills and experience levels, available technology, use of full-time or part-time resources, project quality management, risks, iteration, development environment, requirements, and most of all, the level of commitment of all project members.

Moreover, project estimations do not need to be too complicated. There are tools, methodologies, and best practices that can help project management teams, from sponsors to project managers, agree on estimates and push development efforts forward. Some of these include the following:

Project estimates must be based on the application’s solution, scope and architecture. Making estimates based on an application’s architecture should give you a clear idea of the length of the entire development project phase. Moreover, an architecture-based estimation provides you a macro-level view of the resources needed to complete the project.

Project estimations should also come from the ground up. All estimates must add up, and estimating the collective efforts of the production teams that work on the application’s modules helps identify the number of in-house and outsourced consultants that you need to hire for the entire project, as well as have a clear idea of the collective man-hours required to code modules or finish all features of the application. Ground-up estimates are provided by project team members and do not necessarily match top-level estimates exactly. In this case, it is best to add a percentage of architecture-based estimates to give room to possible reworks, risks, and other events that may or may not be within the control of the project staff.

Do not forget modular estimates. Once you have a clear idea of the architecture, it becomes easier to identify the modules that make up the entirety of the application. Knowing the nature of these modules should help you identify which can be done in-house or onshore, or by an offshore development team. Moreover, given the location and team composition of each development team that works on a module, it becomes easier to identify the technical and financial resources needed to work on the codes.

Development language matters. Whether the development language is Java, .Net, C++ or any other popular language used by software engineers, team that will be hired for the project must be knowledgeable in it. Some development efforts require higher skills in these languages, while some only need basic functional knowledge, and the levels of specialization in any of these languages have corresponding rates. Most of the time, the chosen development language depends on the chosen platform, and certain platforms run on specialized hardware.

You cannot promise upper management dramatic costs from offshoring. While there are greater savings from having development work done by offshore teams composed of workers whose rates are significantly lower from onshore staff, you must consider communication, knowledge transfer, technical set-up, and software installation costs in your financial estimates. Estimating costs is often more about managing expectations, but as the project matures, it should be clearer whether the money spent on it was money that was spent well.

Project estimation software and tools help identify “what-if” scenarios. Over the years, project managers have devised ways to automate project schedule, framework, cost, and staffing estimates. Some estimation applications also have sample historical data or models based on real-world examples. If your business has a lot in common with the samples in the estimation tool, it can help you identify what-if scenarios and in turn include risks, buffers, and iteration estimates.

Price break-down helps in prioritization. Breaking down the total cost of the project helps management decide which parts of a system should be prioritized, delayed, or even cancel. Estimating costs for a new project may not be easy, but project sponsors and managers must be able to know and agree on the breakdown of costs of development, technical requirements, and overhead.

These are some guide lines mentioned to understand the need for estimation & take it as part of daily life to get more control over all software process.

Feel free to reach me at ravindrapande@gmail.com to share thoughts & suggestions.