Managing people Software cost estimation Managing people The

Managing people Software cost estimation

Managing people

The IEEE knowledge areas (2004)

Bloom’s Taxonomy F Bloom’s taxonomy is a well-known and widely used classification of cognitive educational goals. ü Skills in the cognitive domain revolve around knowledge, comprehension, and critical thinking of a particular topic. F It is used as: ü a tool in defining education course materials; ü job descriptions; ü role descriptions within a software engineering process definition; ü professional development paths and professional training programs; ü other needs.

Bloom’s Taxonomy F Knowledge (the lowest level) ü Q: What are the development benefits of using Unix? F Comprehension ü Q: Compare the development benefits of using Unix vs. MS Windows. F Application ü Q: Which OS is best for safety applications, and why? F Analysis ü Q: List five ways of increasing applications security and explain which ones have the highest security benefits. Provide references to support your statements. F Synthesis ü Q: Convert an "unsecured" application to a "secured" by replacing your choice of development techniques. Explain the benefits of using the new techniques vs. the original ones. F Evaluation (the highest level) ü Q: Do you feel that using Linux for basic OS for the project is wellfounded?

Knowledge F Recall of data, i. e. exhibit memory of previously learned materials by recalling facts, terms, basic concepts and answers: ü Knowledge of specifics: terminology, specific facts, etc. ü Knowledge of ways and means of dealing with specifics: conventions, trends and sequences, classifications and categories, criteria, methodology, etc. ü Knowledge of the universals and abstractions in a field: principles and generalizations, theories and structures F Associated Keywords: ü defines, describes, knows, identifies, lists, matches, labels, names, outlines, recalls, recognizes, reproduces, selects, states.

Comprehension F Demonstrative understanding of facts and ideas by organizing, comparing, translating, interpreting, giving descriptions, and stating main ideas. ü State a problem in one's own words. û Translation û Interpretation û Extrapolation F Associated Keywords: ü comprehends, defends, generalizes, distinguishes, estimates, converts, explains, extends, gives examples, infers, interprets, paraphrases, predicts, rewrites, summarizes, translates.

Application F Using new knowledge. ü Solve problems to new situations by applying acquired knowledge, facts, techniques and rules in a different way. ü Use a concept in a new situation or unprompted use of an abstraction. F Associated Keywords: ü applies, computes, demonstrates, constructs, discovers, changes, manipulates, modifies, produces, relates, operates, predicts, prepares, shows, solves, uses.

Analysis F Separates material or concepts into component parts so that its organizational structure may be understood. Make inferences and find evidence to support generalizations : ü Distinguishes between facts and inferences. û Analysis of elements û Analysis of relationships û Analysis of organizational principles F Associated Keywords: ü analyzes, breaks down, compares, contrasts, diagrams, deconstructs, differentiates, discriminates, distinguishes, identifies, illustrates, infers, outlines, relates, selects, separates.

Synthesis F Compile information together in a different way by combining elements in a new pattern or proposing alternative solutions ü Put parts together to form a whole, with emphasis on creating a new meaning or structure. û Production of a unique communication û Production of a plan, or proposed set of operations û Derivation of a set of abstract relations F Associated Keywords: ü categorizes, combines, compiles, composes, creates, devises, designs, explains, generates, modifies, organizes, plans, rearranges, reconstructs, relates, reorganizes, revises, rewrites, summarizes, tells, writes.

Evaluation F Present and defend opinions by making judgments about information, validity of ideas or quality of work based on a set of criteria ü Judgments in terms of internal evidence ü Judgments in terms of external criteria F Associated Keywords: ü appraises, compares, concludes, contrasts, criticizes, critiques, defends, describes, discriminates, evaluates, explains, interprets, justifies, relates, summarizes, supports.

Bloom’s Taxonomy F The University point-of-view

IEEE SWE Bloom’s Taxonomy F The following assumptions were made when specifying the proposed taxonomy levels: ü A software engineer with four years of experience is still at the beginning of their career and would be assigned relatively few management duties, or at least not for major endeavors. û “Management-related topics” are therefore not given priority in the proposed evaluations. û Taxonomy levels tend to be lower for “early-life cycle topics” (such as those related to software requirements) than for more technically-oriented topics (such as those within software design, software construction or software testing).

IEEE SWE Bloom’s Taxonomy F The following assumptions were made when specifying the proposed taxonomy levels: ü The evaluations are proposed for a “generalist” software engineer and not a software engineer working in a specialized group. ü The evaluations can be adapted for more senior software engineers specializing in certain knowledge areas, no topic is given a taxonomy level higher than Analysis.

Staffing requirements F Staff required can’t be computed by diving the development time by the required schedule. F The number of people working on a project varies depending on the phase of the project. F The more people who work on the project, the more total effort is usually required. F A very rapid build-up of people often correlates with schedule slippage.

People in the process F People are an organisation’s most important assets. F The tasks of a manager are essentially people- oriented. Unless there is some understanding of people, management will be unsuccessful. F Poor people management is an important contributor to project failure.

People management factors F Consistency ü Team members should all be treated in a comparable way without favourites or discrimination. F Respect ü Different team members have different skills and these differences should be respected. F Inclusion ü Involve all team members and make sure that people’s views are considered. F Honesty ü You should always be honest about what is going well and what is going badly in a project.

Selecting staff F An important project management task is team selection. F Information on selection comes from: ü Information provided by the candidates. ü Information gained by interviewing and talking with candidates. ü Recommendations and comments from other people who know or who have worked with the candidates.

Lessons F Managers in a company may not wish to lose people F F F to a new project. Part-time involvement may be inevitable. Skills such as UI design and hardware interfacing are in short supply. Recent graduates may not have specific skills but may be a way of introducing new skills. Technical proficiency may be less important than social skills.

Staff selection factors F F F F F Application domain experience Platform experience Programming language experience Problem solving ability Educational background Communication ability Adaptability Attitude Personality

Motivating people F An important role of a manager is to motivate the people working on a project. F Motivation is a complex issue but it appears that their are different types of motivation based on: ü Basic needs (e. g. food, sleep, etc. ) ü Personal needs (e. g. respect, self-esteem) ü Social needs (e. g. to be accepted as part of a group)

Human needs hierarchy Selfrealization needs Esteem needs Social needs Safety needs Physiological needs

Need satisfaction F Social ü Provide communal facilities; ü Allow informal communications. F Esteem ü Recognition of achievements; ü Appropriate rewards. F Self-realization ü Training - people want to learn more; ü Responsibility.

Personality types F The needs hierarchy is almost certainly an over- simplification of motivation in practice. F Motivation should also take into account different personality types: ü ü ü Task-oriented Self-oriented Interaction-oriented

Personality types F Task-oriented ü The motivation for doing the work is the work itself F Self-oriented ü The work is a means to an end which is the achievement of individual goals - e. g. to get rich, to play tennis, to travel etc. F Interaction-oriented ü The principal motivation is the presence and actions of co-workers. People go to work because they like to go to work

Motivation balance F Individual motivations are made up of elements F F F of each class. The balance can change depending on personal circumstances and external events. However, people are not just motivated by personal factors but also by being part of a group and culture. People go to work because they are motivated by the people that they work with.

Managing groups F Most software engineering is a group activity ü The development schedule for most non-trivial software projects is such that they cannot be completed by one person working alone. F Group interaction is a key determinant of group performance. F Flexibility in group composition is limited ü Managers must do the best they can with available people.

Factors influencing group working F Group composition. F Group cohesiveness. F Group communications. F Group organisation.

Group composition F Group composed of members who share the same motivation can be problematic ü ü ü Task-oriented - everyone wants to do their own thing; Self-oriented - everyone wants to be the boss; Interaction-oriented - too much chatting, not enough work. F An effective group has a balance of all types. F This can be difficult to achieve software engineers are often task-oriented. F Interaction-oriented people are very important as they can detect and defuse tensions that arise.

Group composition: Example F In creating a group for assistive technology development, Alice is aware of the importance of selecting members with complementary personalities. ü When interviewing people, she tried to assess whether they were task oriented, self-oriented and interaction oriented. ü She felt that she was primarily a self-oriented type as she felt that this project was a way in which she would be noticed by senior management and promoted. ü She therefore looked for 1 or perhaps 2 interaction-oriented personalities with the remainder task oriented. ü The final assessment that she arrived at was: û Alice – self-oriented û Brian – task-oriented û Bob – task-oriented û Carol – interaction-oriented û Dorothy – self-oriented û Ed – interaction-oriented û Fred – task-oriented

Group leadership F Leadership depends on respect not titular status. F There may be both a technical and an administrative leader. F Democratic leadership is more effective that autocratic leadership.

Group cohesiveness F In a cohesive group, members consider the group to be more important than any individual in it. F The advantages of a cohesive group are: ü Group quality standards can be developed; ü Group members work closely together so inhibitions caused by ignorance are reduced; ü Team members learn from each other and get to know each other’s work; ü Egoless programming where members strive to improve each other’s programs can be practised.

Team spirit: Example F Alice is an experienced project manager and understands the importance of creating a cohesive group. F As the product development is new, she takes the opportunity of involving all group members in the product specification and design by getting them to discuss possible technology with elderly members of their families and to bring these to the weekly group lunch. F The group lunch is an opportunity for all team members to meet informally, talk around issues of concern and, generally, get to know each other.

Team spirit: Example F The lunch is organised as an information session: ü Alice tells the group members what she knows about organisational news, policies, strategies, etc. ü Each team member then briefly summarises what they have been doing and the group then discusses some general topic such as new product ideas from elderly relatives. F Every few months, Alice organises an ‘away day’ for the group where the team spend two days on ‘technology updating’. ü Each team members prepares an update on some relevant technology and presents it to the group. ü This is an off-site meeting in a good hotel and plenty time is scheduled for discussion and social interaction.

Developing cohesiveness F Cohesiveness is influenced by factors such as the organisational culture and the personalities in the group. F Cohesiveness can be encouraged through ü ü ü Social events Developing a group identity and territory Explicit team-building activities F Openness with information is a simple way of ensuring all group members feel part of the group.

Group loyalties F Group members tend to be loyal to cohesive groups. F 'Groupthink' is preservation of group irrespective of technical or organizational considerations. F Management should act positively to avoid groupthink by forcing external involvement with each group.

Group communications F Good communications are essential for effective group working. F Information must be exchanged on the status of work, design decisions and changes to previous decisions. F Good communications also strengthens group cohesion as it promotes understanding.

Group communications F Group size ü The larger the group, the harder it is for people to communicate with other group members. F Group structure ü Communication is better in informally structured groups than in hierarchically structured groups. F Group composition ü Communication is better when there are different personality types in a group and when groups are mixed rather than single sex. F The physical work environment ü Good workplace organisation can help encourage communications.

Group organisation F Small software engineering groups are usually organised informally without a rigid structure. F For large projects, there may be a hierarchical structure where different groups are responsible for different sub-projects.

Informal groups F The group acts as a whole and comes to a consensus on decisions affecting the system. F The group leader serves as the external interface of the group but does not allocate specific work items. F Rather, work is discussed by the group as a whole and tasks are allocated according to ability and experience. F This approach is successful for groups where all members are experienced and competent.

Extreme programming groups F Extreme programming groups are variants of an informal, democratic organisation. F In extreme programming groups, some ‘management’ decisions are devolved to group members. F Programmers work in pairs and take a collective responsibility for code that is developed.

Chief programmer teams F Consist of a kernel of specialists helped by others added to the project as required. F The motivation behind their development is the wide difference in ability in different programmers. F Chief programmer teams provide a supporting environment for very able programmers to be responsible for most of the system development.

Problems F This chief programmer approach, in different forms, has been successful in some settings. F However, it suffers from a number of problems ü Talented designers and programmers are hard to find. Without exceptional people in these roles, the approach will fail; ü Other group members may resent the chief programmer taking the credit for success so may deliberately undermine his/her role; ü There is a high project risk as the project will fail if both the chief and deputy programmer are unavailable. ü The organisational structures and grades in a company may be unable to accommodate this type of group.

Working environments F The physical workplace provision has an important effect on individual productivity and satisfaction ü Comfort ü Privacy ü Facilities F Health and safety considerations must be taken into account ü ü ü Lighting Heating Furniture

Environmental factors F Privacy - each engineer requires an area for uninterrupted work. F Outside awareness - people prefer to work in natural light. F Personalization - individuals adopt different working practices and like to organize their environment in different ways.

Workspace organisation F Workspaces should provide private spaces where people can work without interruption ü Providing individual offices for staff has been shown to increase productivity. F However, teams working together also require spaces where formal and informal meetings can be held.

Office layout Meeting room Office Communal area Window Office Office Shared documentation

P-CMM Objectives F To improve organisational capability by improving workforce capability. F To ensure that software development capability is not reliant on a small number of individuals. F To align the motivation of individuals with that of the organisation. F To help retain people with critical knowledge and skills.

P-CMM levels F Five stage model ü Initial. Ad-hoc people management ü Repeatable. Policies developed for capability improvement ü Defined. Standardised people management across the organisation ü Managed. Quantitative goals for people management in place ü Optimizing. Continuous focus on improving individual competence and workforce motivation

Software Cost Estimate

Fundamental estimation questions F How much effort is required to complete an activity? F How much calendar time is needed to complete an activity? F What is the total cost of an activity? F Project estimation and scheduling are interleaved management activities.

Software cost components F Hardware and software costs. F Travel and training costs. F Effort costs (the dominant factor in most projects) ü The salaries of engineers involved in the project ü Social and insurance costs ü They must take overheads into account û û û Costs of building, heating, lighting Costs of networking and communications Costs of shared facilities (e. g library, staff restaurant, etc. )

Costing and pricing F Estimates are made to discover the cost, to the developer, of producing a software system. ü There is not a simple relationship between the development cost and the price charged to the customer. F Broader organisational, economic, political and business considerations influence the price charged. F Software pricing factors ü ü ü Market opportunity Cost estimate uncertainty Contractual terms Requirements volatility Financial health

Software productivity F A measure of the rate at which individual engineers involved in software development produce software and associated documentation. F Not quality-oriented although quality assurance is a factor in productivity assessment. F Essentially, we want to measure useful functionality produced per time unit.

Productivity measures F Size-related measures ü They based on some output from the software process. This may be lines of delivered source code, object code instructions, etc. F Function-related measures ü They based on an estimate of the functionality of the delivered software. Function-points are the best known of this type of measure.

Measurement problems F Estimating the size of the measure (e. g. how many function points). F Estimating the total number of programmer months that have elapsed. F Estimating contractor productivity (e. g. documentation team) and incorporating this estimate in overall estimate.

Lines of code F What's a line of code (LOC) ? ü The measure was first proposed when programs were typed on cards with one line per card; ü How does this correspond to statements as in C#/C++/Java which can span several lines or where there can be several statements on one line. F What programs should be counted as part of the system? F This model assumes that there is a linear relationship between system size and volume of documentation.

Productivity comparisons F The lower level the language, the more productive the programmer ü The same functionality takes more code to implement in a lower-level language than in a high-level language. F The more verbose the programmer, the higher the productivity ü Measures of productivity based on lines of code suggest that programmers who write verbose code are more productive than programmers who write compact code.

System development times

Function points F Based on a combination of program characteristics ü external inputs and outputs ü user interactions ü external interfaces ü files used by the system F A weight is associated with each of these and the function point count is computed by multiplying each raw count by the weight and summing all values.

Function points F The function point count is modified by complexity of the project F FPs can be used to estimate LOC depending on the average number of LOC per FP for a given language ü LOC = AVC * number of function points; F FPs are very subjective. They depend on the estimator ü Automatic function-point counting is impossible.

Object points F Object points (alternatively named application points) are an alternative function-related measure to function points when 4 Gls or similar languages are used for development. F Object points are NOT the same as object classes. F The number of object points in a program is a weighted estimate of ü The number of separate screens that are displayed ü The number of reports that are produced by the system ü The number of program modules that must be developed to supplement the database code

Productivity estimates F Real-time embedded systems, 40 -160 LOC/P-month. F Systems programs , 150 -400 LOC/P-month. F Commercial applications, 200 -900 LOC/P-month. F In object points, productivity has been measured between 4 and 50 object points/month depending on tool support and developer capability. F Factors affecting productivity ü ü Application domain experience Process quality Project size Technology support

Quality and productivity F All metrics based on volume/unit time are flawed because they do not take quality into account. F Productivity may generally be increased at the cost of quality. F It is not clear how productivity/quality metrics are related. F If requirements are constantly changing then an approach based on counting lines of code is not meaningful as the program itself is not static.

Estimation techniques F There is no simple way to make an accurate estimate of the effort required to develop a software system ü Initial estimates are based on inadequate information in a user requirements definition ü The software may run on unfamiliar computers or use new technology ü The people in the project may be unknown F Project cost estimates may be self-fulfilling ü The estimate defines the budget and the product is adjusted to meet the budget.

Changing technologies F Changing technologies may mean that previous estimating experience does not carry over to new systems ü ü ü ü Distributed object systems rather than mainframe systems Use of web services Use of ERP or database-centred systems Use of off-the-shelf software Development for and with reuse Development using scripting languages The use of CASE tools and program generators

Estimation techniques F Algorithmic cost modelling F Expert judgement F Estimation by analogy F Parkinson’s Law F Pricing to win A model based on historical cost information that relates some Several experts on the proposed software metric (usually its size) Parkinson’s Law states that work software development techniques to the project cost is used. An This technique is applicable when expands to fill the time available. and the application domain are estimate is made of that metric other projects in the same The cost is determined by consulted. They each estimate and the model predicts the effort The software cost is estimated to application domain have been available resources rather than by the project cost. These estimates required. be whatever the customer has completed. The cost of a new objective assessment. If the are compared and discussed. The available to spend on the project is estimated by analogy software has to be delivered in 12 estimation process iterates until The estimated effort depends on with these completed projects. months and 5 people are an agreed estimate is reached. the customer’s budget and not on Myers (Myers 1989) gives a very available, the effort required is the software functionality. clear description of this approach. estimated to be 60 person-months.

Estimation’s techniques F Top-down ü Start at the system level and assess the overall system functionality and how this is delivered through subsystems. F Bottom-up ü Start at the component level and estimate the effort required for each component. Add these efforts to reach a final estimate.

Estimation methods F Each method has strengths and weaknesses. F Estimation should be based on several methods. F If these do not return approximately the same result, then you have insufficient information available to make an estimate. F Some action should be taken to find out more in order to make more accurate estimates. F Pricing to win is sometimes the only applicable method.

Algorithmic cost modelling F Cost is estimated as a mathematical function of product, project and process attributes whose values are estimated by project managers: Effort = A ´ Size. B ´ M F The most commonly used product attribute for cost estimation is code size. ü ü ü A: it is an organisation-dependent constant B: it reflects the disproportionate effort for large projects M: it is a multiplier reflecting product, process and people attributes. F Most models are similar but they use different values for A, B and M.

Estimation accuracy F The size of a software system can only be known accurately when it is finished. F Several factors influence the final size ü Use of COTS and components ü Programming language ü Distribution of system F As the development process progresses then the size estimate becomes more accurate.

The COCOMO model F An empirical model based on project experience. F Well-documented, ‘independent’ model which is not tied to a specific software vendor. F Long history from initial version published in 1981 (COCOMO -81) through various instantiations to COCOMO 2. ü COCOMO 81 was developed with the assumption that a waterfall process would be used and that all software would be developed from scratch. ü Since its formulation, there have been many changes in software engineering practice and COCOMO 2 is designed to accommodate different approaches to software development. F COCOMO 2 takes into account different approaches to software development, reuse, etc.

COCOMO 81

COCOMO 2 models F COCOMO 2 incorporates a range of sub-models that produce increasingly detailed software estimates. F The sub-models in COCOMO 2 are: ü Application composition model - Used when software is composed from existing parts. ü Early design model - Used when requirements are available but design has not yet started. ü Reuse model - Used to compute the effort of integrating reusable components. ü Post-architecture model - Used once the system architecture has been designed and more information about the system is available.

Application composition model F Supports prototyping projects and projects where there is F F F extensive reuse. Based on standard estimates of developer productivity in application (object) points/month. Takes CASE tool use into account. Formula is ü PM = ( NAP ´ (1 - %reuse/100 ) ) / PROD ü PM is the effort in person-months, NAP is the number of application points and PROD is the productivity.

Early design model F Estimates can be made after the requirements have been agreed. F Based on a standard formula for algorithmic models ü PM = A ´ Size. B ´ M where ü M = PERS ´ RCPX ´ RUSE ´ PDIF ´ PREX ´ FCIL ´ SCED; ü A = 2. 94 in initial calibration, Size in KLOC, B varies from 1. 1 to 1. 24 depending on novelty of the project, development flexibility, risk management approaches and the process maturity.

Multipliers F Multipliers reflect the capability of the developers, the non-functional requirements, the familiarity with the development platform, etc. ü ü ü ü RCPX - product reliability and complexity; RUSE - the reuse required; PDIF - platform difficulty; PREX - personnel experience; PERS - personnel capability; SCED - required schedule; FCIL - the team support facilities.

The reuse model F Takes into account black-box code that is reused without change and code that has to be adapted to integrate it with new code. F There are two versions: ü Black-box reuse where code is not modified. An effort estimate (PM) is computed. ü White-box reuse where code is modified. A size estimate equivalent to the number of lines of new source code is computed. This then adjusts the size estimate for new code. F For generated code: ü PM = (ASLOC * AT/100)/ATPROD F When code has to be understood and integrated û ESLOC = ASLOC * (1 -AT/100) * AAM

Post-architecture level F Uses the same formula as the early design model but with 17 rather than 7 associated multipliers. F The code size is estimated as: ü Number of lines of new code to be developed; ü Estimate of equivalent number of lines of new code computed using the reuse model; ü An estimate of the number of lines of code that have to be modified according to requirements changes.

The exponent term F This depends on 5 scale factors (see next slide). Their sum/100 is added to 1. 01 F A company takes on a project in a new domain. The client has not defined the process to be used and has not allowed time for risk analysis. The company has a CMM level 2 rating. ü ü ü Precedenteness - new project (4) Development flexibility - no client involvement - Very high (1) Architecture/risk resolution - No risk analysis - V. Low. (5) Team cohesion - new team - nominal (3) Process maturity - some control - nominal (3) F Scale factor is therefore 1. 17.

Multipliers F Product attributes ü Concerned with required characteristics of the software product being developed. F Computer attributes ü Constraints imposed on the software by the hardware platform. F Personnel attributes ü Multipliers that take the experience and capabilities of the people working on the project into account. F Project attributes ü Concerned with the particular characteristics of the software development project.

Project planning F Algorithmic cost models provide a basis for project planning as they allow alternative strategies to be compared. F Embedded spacecraft system ü ü ü Must be reliable; Must minimise weight (number of chips); Multipliers on reliability and computer constraints > 1. F Cost components ü Target hardware; ü Development platform; ü Development effort.

Management options F Use existing hardware, development system, development team ü Processor and memory upgrade: Hardware cost increase; Experience decrease û New development system û Staff with hardware experience ü Memory upgrade only: Hardware cost increase ü More experienced staff

Option choice F Option D (use more experienced staff) appears to be the best alternative ü However, it has a high associated risk as experienced staff may be difficult to find. F Option C (upgrade memory) has a lower cost saving but very low risk. F Overall, the model reveals the importance of staff experience in software development.

Project duration and staffing F As well as effort estimation, managers must estimate the calendar time required to complete a project and when staff will be required. F Calendar time can be estimated using a COCOMO 2 formula ü TDEV = 3 ´ (PM)(0. 33+0. 2*(B-1. 01)) ü PM is the effort computation and B is the exponent computed as discussed above (B is 1 for the early prototyping model). This computation predicts the nominal schedule for the project. F The time required is independent of the number of people working on the project.

The Copyright Law

The Copyright Law F Copyright law protects any work, including computer software, that is "fixed in a tangible medium of expression" and which contains a "modicum of originality. " ü While making a copy of an original work generally constitutes copyright infringement, the very nature of computer software requires the making of a copy of original elements every time a program runs. ü In order to solve this problem, USA Congress included specific exemptions within copyright law outlining the permitted uses of a computer program.

The Copyright Law F Section 117 of the Copyright Act provides that: ü It is not an infringement for the owner of a copy of a computer program to make or authorize the making of another copy or adaptation of that computer program provided: û that such a new copy or adaptation is created as an essential step in the utilization of the computer program in conjunction with a machine and that it used in no other manner, or û that such new copy or adaptation is for archival purposes only and that all archival copies are destroyed in the event that continued possession of the computer program should cease to be rightful.

The Copyright Law F About an intermediate copy in the reverse engineering: ü The USA appellate court determined that reverse engineering is a fair use when "no alternative means of gaining an understanding of those ideas and functional concepts exists. " ü The court held that forbidding reverse engineering in this context would defeat "the fundamental purpose of the Copyright Act -- to encourage the production of original works by protecting the expressive elements of those works while leaving the ideas, facts, and functional concepts in the public domain for others to build on. "

The Copyright Law F Copyright protects the expression of an idea but not the idea itself is fundamental to copyright law. ü Commonly referred to as the "idea/expression dichotomy, " this distinction is particularly complicated in the context of computer programs. û A software program must include many elements of computer code that are external to its particular use in order to function properly, including the specifications of the operating system, the computer on which the program runs, compatibility with other programs, and other widely accepted standards. û These functional elements of a software program as well as those aspects of the software code that are in the public domain are considered ideas not protected by copyright law.

The Copyright Law F The difference between the ideas and expressions in a computer program - the following steps to determine whether copyright infringement occurred: ü Retrace the designer's steps in the reverse order of its creation into manageable components in order to identify the unprotected ideas at each level of abstraction. ü Filter out the non-protectable elements, including those dictated by efficiency (the most efficient implementation of any given task) , merger (when there is only one way to express an idea), external factors (necessity of matching standards), and elements taken from the public domain (expressions not protected by intellectual property). ü Compare the allegedly infringing work and the initial work to determine whether a sufficient similarity exists in the protectable elements of the initial work.

The Copyright Law F Copyright protection does not extend over the elements of a program's software code that relate to its basic function. ü The fact that such aspects of a program become industry standards is considered in the determination of whether they are functional elements not protected by copyright. F Reverse engineering is generally not necessary to discover the method or process necessary to the independent creation of that invention. ü However, many integrated systems contain many components, some of which may be patentable, which may implicate a reverse engineer in a patent infringement lawsuit. F Software developers are generally not affected by a company's trademark when reverse engineering software. ü Trademark law protects words, names, symbols, or devices that identify the source of goods and services.

The Copyright Law F The difference between a license and a sale of a product ü As opposed to the transfer of ownership of property when a consumer buys a product, a licensee enters into a relationship with the manufacturer where the permitted uses of the product are defined in a contract and the manufacturer still retains ownership. ü The software industry generally makes end-user license agreements, which define these permitted uses in the form of: û a shrink-wrap agreement û a click-wrap agreement û a browse-wrap agreement

The Copyright Law F Shrink-wrap licenses ü They refer to the cellophane wrapping that seals boxes of mass marketed software commonly called "shrinkwraps. " ü Software manufacturers generally attach license agreements inside the packaging of their products, which bind the consumer to the terms of the agreement upon removal of the shrink-wrap.

The Copyright Law F Click-wrap licenses ü They are another form of creating an electronic agreement, except that the license is included on the computer screen before installation rather than on the box. û By clicking on a button that says "I agree" or "I accept, " the licensee agrees to the terms of use of the contract. ü An important difference between click-wrap agreements and shrink-wrap agreements is the fact that the user actually has an opportunity to read the contract before using or installing the program.

The Copyright Law F Browse-wrap agreements ü They are contracts in which the terms of use are listed on a web site page. In such contracts, manufacturers presume to bind the user to the license terms merely by their visit to the web site or downloading software from that site. ü Courts are generally reluctant to hold such contracts enforceable because of the lack of assent, or explicit agreement, on the part of the user.

Questions ?