The All-rounders
As today's professional world is adopting a knowledge-intensive culture, it is tough to find a right combination that covers the depth and the breadth of a specific area of knowledge. Conventionally, we relied on deep, explicit, documented knowledge as in the case of research and development projects. But in recent times knowledge acquisition has become broader because of mainly two reasons.
Firstly, technology has helped distributing information wide and far and power of knowledge has become evident in activities beyond research and development. People then needed to acquire knowledge from more than one domain and were restricted in the depth while expanding their breadth of knowledge. Secondly, people who followed the rapid advancements in technology made shallow impressions everywhere while spreading over larger area.
We have two sets of people now: the specialists and the generalists. Generalists existed even before the above-mentioned reasons forced many and that was because of personal traits - some people find it easier to deal with multiple subjects while others like to dig deeper in one subject. I find J Scott Armstrong's description of specialists and generalists very striking. According to him a specialist is the one who knows more and more about less and less until eventually he knows everything about nothing! A generalist is the one who knows less and less about more and more until eventually he knows nothing about everything!
Today's world needs both specialists and generalists, and the challenge is to find the right balance between the two. Certainly a team of generalists is not going to be of much help. A team of specialists may lack creativity or may miss out the inter-relationships between multiple parts.
There are various hypotheses and propositions on structuring a team with specialists and generalists. But I like to draw an analogy from sports in this matter. In all the team-sports, there are some people who are all-rounders or playmakers; though they are not many. A generalist holds this position in a project team. This is especially true when the environment/scope is not too small. Obviously in a very small team/project, specialists always dominate.
Value Addition
Howard Artrip - a manager in Toyota - knows what he does. He knows when he gets up, how long he takes to get ready and get to work. He smiles when he says "I've maximized my sleep time". Toyota's philosophy of continuous improvement is his personal statement.
Sometime back, I was talking to an engineer from a highly capable and mature company about what he thinks about quality. At the end of a very colorful description about the practices and processes, he confessed that it is difficult to follow them all. It was a burden on him, and in his opinion an overhead to the system.
It is a fashion to adapt and implement the processes and techniques that are proven in some organizations. In a frenzy to implement and report the return-on-investments, most managers fail to get the spirit - and most importantly the thinking - behind these processes. One of the common mistakes is that we try to replicate the processes without understanding the context and culture in which these were set and became successful.
Value addition is the promise of most processes and techniques. At the end of the day we search for added value in the process, in the end-product, in the pile of documentation, reports, and presenations. What I find often is that we miss out in searching for the added value in our people. It may be that we think they are just techies or skilled workers, we think they appreciate the processes themselves, we think the processes have nothing to do with people and vice versa!
People need to understand the reason behind every activity, the benefits and a bit of history to enjoy their work. It is important to infuse the spirit behind the process into people, so that value is first added to them - and they realize it. They will in turn add value to products and even back to those processes.
Well Begun Is Half Done
It is a very old saying of Aristotle - well begun is half done. We find this true in many fields, especially when it comes to accomplish a certain goal - whether it is in studies, sports or projects.
We have developed and mastered many techniques and processes to execute a project. But we deal with project initiation with a bit of laxity. In the height of dramatic events involved in realizing a project, we sometimes fail to see the fine cracks that are being developed - in terms of missing out details, under-estimating functionalities, setting aggressive timelines etc. It then becomes a fight for the team to hold the project from falling apart during its course to completion.
It is good to estimate, and it is better to re-estimate. There are many techniques which are developed to encourage multiple estimates - quick/detailed estimates, optimistic/pessimistic estimates, low-confidence/high-confidence estimates and so on. It is also important to work out estimation parameters from the final estimate that is used to win the project. One aspect which is overlooked frequently in estimation is dependency. The project dependencies normally drive the schedules and idle-times and it is crucial to understand it early on. A good work-breakdown-structure can solve this easily.
It is also good to create a visual representation of the project and its environment, something like a map. Words can be hazy; numbers can become tough to follow; visual representations are easy to comprehend and remember. It is good to note that all military operations start with a study the area to be conquered, usually represented by a map. It is good if the project map includes not only the deliverables, but also other details such as schedule, size, assignment, risk etc.
Training and team-building are some aspects that are taken lightly. It is important for the team to understand the terrain - environment, existing systems, work-flow, domain knowledge, business rules, tools, techniques, limitations of technology - before starting a project. Building a knowledge-base is a best-practice in most of the execution frameworks. The earlier and faster we build it, the easier will be the project execution.
If we take Aristotle's words literally, it is fine to devote half the project duration just to initiate. If you are worried about a possible time-crunch, return to some past projects and see the productivity during the last few weeks.
Pygmalion Effect
I knew a boy who had the abilities to excel, but did not have the motivation. His teachers advised him and expected him to come first. He did. I know a man on whom his managers put their trust. They expected him to work wonders. And he did.
Often, performance follows sincere expectations.
Manufacturing Software
Various books about software engineering usually compares software development to manufacturing. The comparisons often highlight the differences so as to establish a separate set of processes and methodologies for software development. While it is true to a larger extent in the current scenario, the future of software development may blur the line between manufacturing goods and manufacturing software. What makes software unique could be the replicable nature of end products.
The common conception (or misconception) on the difference between software development and manufacturing is that software development is more intellectual than manufacturing. This was true in the nascent and adolescent stages of software industry. In the current mature scenario, industry recognizes right aptitude and training as the most important qualifiers for software workforce - as it is in manufacturing.
Mature tools and processes enable software to be created and managed with less sophistication from the developers. In my opinion, this brings out the most striking similarity between software development and manufacturing. Manufactured goods are often differentiated by the company or location. There is also a certain brand value generated from the quality and process of manufacturing (take the classic example - Toyota). As the software industry is also growing into a similar mould, the tools and processes will be key differentiators in coming days. A mature software company is more likely to produce quality work-products than others, consistently.
The grey areas in the above statement cannot be overlooked. While the weightings of the words likely and consistently are important in decision making the key challenge will be in assessing the maturity of a company. Certainly software has been following manufacturing in establishing maturity levels (refer Quality Management Maturity Grid). As the awareness builds, customers will be more equipped to discern maturity and there is more to learn then.
Microsoft Word 2003 Annoyances
A few steps to prevent Word from over-assisting you...
- Always show full menus
- Go to Tools - Customize - Options
- Check 'Always show full menus'
- Disable Reading Layout
- Goto Tools - Options - General
- Uncheck 'Allow starting in Reading Layout'
- Prevent Word documents from bloating up
- Goto Tools - Options - Save
- Uncheck 'Allow fast saves'
- Uncheck 'Allow background saves'
- Disable startup task pane
- Go to Tools - Options - View
- Uncheck 'Startup Task Pane'
- Hide Office Clipboard (AcbControl does not work for me)
- Goto View - Task Pane - Clipboard
- Click Option
- Uncheck 'Show Office Clipboard Automatically'
- Uncheck 'Show Office Clipboard When Ctrl+C Pressed Twice''
- Uncheck 'Show Office Clipboard Icon on Taskbar'
- Uncheck 'Show Status Near Taskbar When Copying'
- Check 'Collect Without Showing Office Clipboard'
- Prevent Normal style (or any other style) from getting "automatically updated"
- Goto Format - Styles and Formatting
- Click on Normal (on the combo option) - Modify
- Uncheck "Automatically Update"
- You may need to do this for individual documents
29 January 2007
Function Point Analysis
NOTES FROM LONGSTREET'S TRAINING BOOKLET
http://www.softwaremetrics.com/freemanual.htm
INTRODUCTION
Developed first by Allan J. Albrecht in the mid 1970s
- FPA is a method to break systems into smaller components, so they can be better understood and analyzed
- Function points are a unit measure for software
- much like an hour is to measuring time, miles are to measuring distance or Celsius is to measuring temperature
- One of the largest misconceptions of function points is understanding what functionality is being exposed to an end user versus the delivered functionality.
- When we size software applications we want to understand what is exposed and what is under the surface.
- There are two basic types of elementary processes in a software application.
- Data in motion and data at rest
- Data in motion has the characteristic of moving data inside to outside the application boundary or outside to inside the application boundary.
- Data in motion
- External Inputs
- External Outputs
- External Inquiries
- Data at rest
- Internal Logical Files
- External Interface Files
Function points are not a very good measure when sizing maintenance efforts (fixing problems) or when trying to understand performance issues. Much of the effort associated with fixing problems (production fixes) is due to trying to resolve and understand the problem (detective work). Another inherent problem with measuring maintenance work is that much of maintenance programming is done by one or two individuals. Individual skill sets become a major factor when measuring this type of work. The productivity of individual maintenance programmers can vary as much as 1,000 percent.
Performance tuning may or may not have anything to do with functionality. Performance tuning is more a result of trying to understand application throughput and processing time. There are better metrics to utilize when measuring this type of work.
- Three types of Function Point Counts
- Development Project Function Point Count (a.k.a Baseline Function Point Count)
- Enhancement Project Function Point Count
- Application Function Point Count
- Productivity of the Language
- Hours per Function Point
- Productivity of the Programmer
Frederick W. Taylor believed that application of scientific methods, instead of custom and rules of thumb could yield higher productivity. A century after Frederick Taylor most software managers use rules of thumb instead of systematic study.
- Productivity = outputs/inputs (within a time period, quality considered)
- Software Productivity = Function Points / Inputs
- Software productivity is defined as hours/function points or function points/hours
- Industry data shows is the unit cost of software goes up with size
- Unit Costs
- The unit cost for external inputs may not be the same as the unit cost of external outputs
- The online external inputs and the batch external inputs do not have the same unit cost
- The cost per unit to build and implement internal logical files is not the same per unit cost as the building and implementing of online reports
FUNCTION POINT COUNTING PROCESS
The overall objective is to determine adjusted function point count
- Determine type of function point count
- Determine the application boundary
- Identify and rate transactional function types to determine their contribution to the unadjusted function point count.
- Identify and rate data function types to determine their contribution to the unadjusted function point count.
- Determine the value adjustment factor (VAF)
- Calculate the adjusted function point count.
- FPA can be broken into three major parts
- FPA for transactinal function types
- FPA for data function types
- FPA for GSCs
- Since the rating of transactions is dependent on both information contained in the transactions and the number of files referenced, it is recommended that transactions are counted first.
- Every FTR must have at least one or more transactions
- Each transaction must be an elementary process.
- An elementary process is the smallest unit of activity that is meaningful to the end user in the business. It must be self-contained and leave the business in consistent state.
ESTABLISHING THE BOUNDARY
- The boundary indicates the border between the project or application being measured and the external applications or user domain
- A Boundary must be drawn according to the sophisticated user’s point of view
- There is a tendency to create a "new" application for the Internet/Intranet extension, but this approach is incorrect.
- The boundaries for client/server applications need to be drawn around client and server together.
IDENTIFYING RET’S, DET’S, FTR’S
- Record Element Type (RET): A RET is user recognizable sub group of data elements within an ILF or an EIF
- File Type Referenced (FTR): A FTR is a file type referenced by a transaction. An FTR must also be an internal logical file or external interface file.
- Data Element Type (DET): A DET is a unique user recognizable, non-recursive (non-repetitive) field. A DET is information that is dynamic and not static. A dynamic field is read from a file or created from DET’s contained in a FTR. Additionally, a DET can invoke transactions or can be additional information regarding transactions. If a DET is recursive then only the first occurrence of the DET is considered not every occurrence.
- All of the components are rated based upon DET’s, and either RET’s or FTR’s.
- EI: FTR, DET
- EO: FTR, DET
- EQ: FTR, DET
- ILF: RET, DET
- EIF: RET, DET
- Transaction DET’s
- External Inputs: Data Input Fields, Error Messages, Calculated Values, Buttons
- External Outputs: Data Fields on a Report, Calculated Values, Error Messages, and Column Headings that are read from an ILF. Like an EQ and EO can have an input side and output sides.
- External Inquiries: Input Side - field used to search by, the click of the mouse. Output side displayed fields on a screen.
For example, a simple application to track distributors could have fields for Distributor Name, Address, City, State, Zip, Phone Number, and Fax Number. This would represent seven fields or (seven data elements) and the add command button would represent the eighth data element. In short, the “add” external input represent a one external input with eight data elements, the “change” external input represents another external input with eight (seven data elements plus the “change” command button), and the “delete” external input represents the last external input with eight data elements (seven fields plus the “delete” command button).
- DET’s for GUI
- Radio Buttons are treated as data element types
- one data element type is counted for all the radio buttons contained in the frame
- Each check box, within a frame, that can be selected should be treated as a data element
- According to IFPUG counting rules each command button would be counted as a data element for the action it invokes
- A display of a graphical image is simply another data element
- Many GUI applications have a sound byte attached. This represents one data element.
- A photographic image is another data element, and is counted as one. (e.g. HR Application with employee photo)
- Messages
- error messages and confirmation messages
- are not an elementary or independent process alone, but they are part of another elementary process
- notification messages
- are treated as External Outputs
- DET’s For Real Time Systems
- time of diagnostics, hardware state during diagnostics, temperature, voltage, so on and so forth would all be examples of data elements.
- Real Time Systems may not have any “traditional user interface.” That is, the stimulus for the Real Time System may be it’s own output – or state.
- Record Element Types (RET’s)
- one of the most difficult concepts in function point analysis
- Most record element types are dependent on a parent - child relationship
- Navigation
- is moving from one transaction to another
EXTERNAL INPUTS
- is an elementary process in which data crosses the boundary from outside to inside
- data may come from a data input screen or another application
- data may be used to maintain one or more internal logical files
- data can be either control information or business information
- If an external input adds, changes and deletes (maintains) information on an internal logical file, then this represents three external inputs
- External inputs (especially change & delete) may be preceded by an external inquiry (see the section on external inquiries)
- An FTR can be either an Internal Logical File and/or External Interface File
- Any internal logical file or external interface file that is referenced by an external input as part of the elementary process of maintaining an internal logical file would be considered an FTR also
- For example, an External Input may update an internal logical file, but must also reference a “security file” to make sure that the user has appropriate security levels. This would be an example of two FTR’s.
- A unique set of data elements, and/or a different set of FTR’s, and/or a unique set of calculations make one external input unique or different from other external inputs.
- That is, one of the following must be true:
- Unique or different set of data elements
- Unique or different set of FTR’s
- Unique or different calculations
- Modification of any of the items, which make an External Input unique from other external inputs, causes the EI to be “enhanced.”
- DET’s added to an EI
- DET’s modified on an EI. The DET was included in the last FP Count.
- A New FTR
- Modifications to a calculation that appears on an EI
- Some sources of information to determine external inputs are
- Screen Layouts
- Screen Dialogs
- Design Documentation
- Functional Specifications
- User Requirements
- Any Input Forms
- Context Diagrams
- Data Flow Diagrams
EXTERNAL OUTPUTS
- an elementary process in which derived data passes across the boundary from inside to outside
- Derived Data is data that is processed beyond direct retrieval and editing of information from internal logical files or external interface files
- Derived data occurs when one or more data elements are combined with a formula to generate or derive an additional data element(s)
- This derived data does not appear in any FTR
- The rating is based upon the total number of unique (combined unique input and out sides) data elements (DET’s) and the file types referenced (FTR’s)
- A unique set of data elements, and/or a different set of FTR’s, and/or a unique set of calculations makes one external output unique or different from other external outputs.
- That is, one of the following must be true:
- Unique or different set of data elements
- Unique or different set of FTR’s
- Unique or different calculations
- Unique processing logic
- Modification of any of the items, which make an External Output unique from other external outputs, causes the EO to be “enhanced.”
- DET’s added to an EO
- DET’s modified on an EO. The DET was included in the last FP Count.
- A New FTR
- Modifications to a calculation that appears on an EO.
- Some sources of information to determine external outputs are
- Report Layouts
- Design Documentation
- Functional Specifications
- User Requirements
- Database descriptions
- Field Sizes and Formats
- Graphical Report Layouts
- External Output have an input side if the input side is not stand-alone and required by external output process
- The FTR’s and DET’s used to search should be included in the count
- An external output can update an internal logical file, but it is incorrect to say that an external output can maintain an internal logical file.
EXTERNAL INQUIRIES
- an elementary process with both input and output components that result in data retrieval from one or more internal logical files and external interface files
- the input process does not update or maintain any FTR’s and the output side does not contain derived data
- A unique set of data elements, and/or a different set of FTR’s make one external inquiry unique or different from other external inquiry.
- That is, one of the following must be true:
- Unique or different set of data elements
- Unique or different set of FTR’s
- Unique processing logic
- Modification of any of the items, which make an External Inquiry unique from other external inquiries, causes the EQ to be “enhanced.”
- DET’s added to an EQ
- DET’s modified on an EQ. The DET was included in the last FP Count.
- A New FTR
- Some sources of information to determine external inquiries are
- Screen Layouts
- Design Documentation
- Functional Specifications
- Table Layouts
- User Requirements
- Database descriptions
- Pick lists
- Field sizes and formats
- all external inquiries have an input side
- an external inquiry may update an internal logical file, but it is incorrect to say that an external inquiry can maintains an internal logical file
INTERNAL LOGICAL FILES
- a user identifiable group of logically related data that resides entirely within the application boundary and is maintained through External Inputs
- an ILF can consist of multiple physical files with different record types
- Some sources of information to determine internal logical files are
- Table Layouts
- Database descriptions
- Logical data models
- Field sizes and formats
- Design Documentation
- Functional Specifications
- User Requirements
EXTERNAL INTERFACE FILES
- a user identifiable group of logically related data that is used for reference purposes only.
- data resides entirely outside the application boundary.
- pull theory
- external application “reaching into” another applications and retrieving data
- push theory
- applications to create interfaces (EO or EQ) which other applications read
- Some sources of information to determine internal logical files are
- Table Layouts
- Interface Diagrams
- Database descriptions
- Logical data models
- Field sizes and formats
- Design Documentation
- Functional Specifications
- User Requirements
GENERAL SYSTEM CHARACTERISTICS
- to rate the general functionality of the application being counted
- 14 general system characteristics
- each characteristic has associated descriptions to determine the degrees of influence.
- the degrees of influence range on a scale of zero to five, from no influence to strong influence.
- 0 Not present, or no influence
- 1 Incidental influence
- 2 Moderate influence
- 3 Average influence
- 4 Significant influence
- 5 Strong influence throughout
- General System Characteristics
- Data communications
- How many communication facilities are there to aid in the transfer or exchange of information with the application or system?
- Distributed data processing
- How are distributed data and processing functions handled?
- Performance
- Did the user require response time or throughput?
- Heavily used configuration
- How heavily used is the current hardware platform where the application will be executed?
- Transaction rate
- How frequently are transactions executed daily, weekly, monthly, etc.?
- On-Line data entry
- What percentage of the information is entered On-Line?
- End-user efficiency
- Was the application designed for end-user efficiency?
- On-Line update
- How many ILF’s are updated by On-Line transaction?
- Complex processing
- Does the application have extensive logical or mathematical processing?
- Reusability
- Was the application developed to meet one or many user’s needs?
- Installation ease
- How difficult is conversion and installation?
- Operational ease
- How effective and/or automated are start-up, back up, and recovery procedures?
- Multiple sites
- Was the application specifically designed, developed, and supported to be installed at multiple sites for multiple organizations?
- Facilitate change
- Was the application specifically designed, developed, and supported to facilitate change?
- the Value Adjustment Factor (VAF) is based on general system characteristics
- VAF = 0.65 + SUM(GSC[1:14])/100
Function Point Count
- Function Point Count (FPC) is the product of Unadjusted Function Point Count (UFC) and Value Adjustment Factor (VAF)
- FPC = UFC * VAF
30 January 2007
References
http://www.softwaremetrics.com/freemanual.htm
Qualify Qualitatively
Quality is one of the evergreen topics for discussion in business world. I attended yet another session on quality a few days back and that made me think a bit deeper - more on concept and perceptions. Our instructor described quality as conformance to requirements and fitness for use, the common definitions from Philip Crosby and Joseph Juran. Next, our instructor mentioned that the need for quality is to survive in competition and to get repeat business - with heavy overtones from sales and marketing.
Many talk about product and process qualities further complicating the matter. They point out the competing objectives in product and process qualities (e.g. beyond a point an increase in efficiency of product decreases efficiency of process). It is much easier consider quality of product alone, and create a scope based on limitations in the process - such as budget, schedule, resources or techniques. The concept cost of quality is more useful than dealing with multiple perspectives of quality. I also prefer the word maturity over quality when talking about processes.
In my opinion, the word qualification suits better to the descriptions of quality mentioned above. It's high time we should differentiate quality and 'quality management/control/assurance'. The latter is more associated with qualification - ensuring that the product/process is qualified according to the requirements.
The dictionary defines quality as An essential and distinguishing attribute of something or someone, A degree or grade of excellence or worth, A characteristic property that defines the apparent individual nature of something or Of superior grade. A few synonyms for quality are caliber, character and select. These phrases and words give a more accurate definition - devoid of sales and marketing pressures - making us understand that quality is more of a character of products and processes than a set of methodologies and tools. ISO defines quality as degree to which a set of inherent characteristic fulfills requirements.
In my opinion, achieving quality thus becomes part of work-culture. Methods and tools are important because it is difficult and time-consuming to permeate the concepts and organizational philosophies into individuals. However, those are just some means to and end, and the importance of quality as part of organization's culture should not be overlooked. The success of Toyota is not their methods or lean tools, but the quality that is instilled into organization's culture.
Thus I would say, "make quality as the character of your organization or product and qualify your services (and products) to suit customer's requirements".
Systems Approach
Currently I am reading a book named Long-Range Forecasting - From Crystal Ball To Computer (LRF). The author - J Scott Armstrong - begins by introducing a simple idea which he calls systems approach as the first lesson to be learned in forecasting. The approach is an elementary technique for analysis and planning. Many such important techniques in management have been known for decades or even centuries. We keep reinventing, repackaging and reselling!!!
The systems approach helps in developing, evaluating & implementing projects (programs) with a holistic perspective. Quoting from LRF:
"The systems approach uses two basic ideas. First, one should examine objective before considering ways of solving a problem; and second, one should begin by describing the system in general terms before proceeding to the specific."
It helps to break down a problem into four generic steps: 1. Identify objectives, 2. Develop indicators of success, 3. Generate alternative strategies, and 4. Develop and select programs.
It is often found that the projects are executed without finalizing or understanding the objectives, postponing the definition of validation mechanisms and not considering the alternative strategies and designs. I have seen this happening among managers while estimation and planning, designers while creating systems architectures, and software developers while coding the foundation modules (I was also a partaker). I have worked in a couple of projects that did not have any purpose but to exhaust the budget or justify some previous mistakes/investment.
These real experiences helped me to appreciate the basic steps illustrated by Armstrong in a very simple, but striking manner. Here's an analogy for easy recollection.
- Rainmaker Theory Number One: "The rainmaker gets so involved with the dance that he sometimes forgets that he has to make rain."
- Rainmaker Theory Number Two: "Yes, I know it didn't rain - but didn't you like the dance?" In other words, the successful rainmaker is the one who can convince his client that he really didn't want rain - he wanted to watch the dance.
- Rainmaker Theory Number Three: "Who cares why it rains?" The science of rainmaking evolves into the science of rainmaking dances.
Negotiate The Value
One of the confounding terms in the business world is value. Outside the business world the term poses difficult questions to philosophers, economists, religious thinkers in the sense it matters to them. One of the main challenges is to define whether the value of an object/service is absolute or relative. For example, neoclassical economists perceive value as relative while classical folks try to measure it as innate worth, and an objectivist acknowledges the worth, but play it down with reason.
In a world, where value seems to be driven by perceptions of individuals, it is difficult to assess the true value of anything - that too, only if a true value exists for one! And, we often come to the table negotiating our perceptions of value. We have created processes, methodologies and systems to minimize the negotiations; especially to save the carps from negotiation sharks. But these systems are not foolproof, and loopholes are easily exploited.
In most of our day-to-day transactions value of a substance/service is often understood by its objective and subjective elements. It helps if we separate objective and subjective elements and their contributions to the assessed value, with the context of subjectivity well understood. There could be some delicate interdependencies between these elements, which may need to be dealt with care and tact.
When the systems fail, processes become inadequate, value tilts out of balance. At that point negotiation starts and fairness of the deal depends a lot on the parties involved. A good and principled negotiation helps in establishing value in a realistic manner. It is also good to remember that there is value in building relationships as well, through healthy negotiations.
