Submitted By: Tausif Javed BCS-10134 Fareed Ali Azam BCS-10135 Khizar Javed BCS-10140 Mauzzam Khan BCS-10146

Anas Farooq BCS-10159 Submitted To: Sir Yasar Islam

Table Of Contents:
Software Project Management
1. Factors Influence SPM 1.1 Project Size 1.2 Delivery Deadline 1.3 Application Domain 1.4 System Constraints 1.5 Budgeting 1.6 Technology 1.7 Resources Allocation

2. The Management SPECTRUM (Four Ps Concept)

2.1 The People 2.1.1 The Stakeholders 2.1.1.1 Senior Manager 2.1.1.2 Project Manager 2.1.1.3 Practitioners 2.1.1.4 End User 2.1.2 The Team Leader 2.1.3 MOI MODEL 2.1.3.1 Motivation 2.1.3.2 Organization 2.1.3.3 Innovation 2.1.4 Software Team 2.1.4.1 Democratic Decentralized 2.1.4.2 Controlled Decentralized 2.1.4.3 Controlled Centralized 2.1.4.4 Agile Team

2.2

The Product
Scope

2.2.1

Context Information objectives Function and performance 2.2.2 Problem Decomposition 2.3 The Process 2.4 The Project 2.5 The W5HH Principle

3. Why Project Fails?

3.1 Changes in Customer Requirement (Requirement Engineering) 3.2 Ambiguous Requirements 3.3 Unrealistic Requirement 3.4 Unpredictable 3.5 Technical Difficulties 3.6 Project Management

4. Characteristics of project Manager

4.1 4.2 4.3 4.4 4.5 Problem Solving Managerial identity Achievement Influential Team Building

5. Software Team
5.1 Democratic Decentralized 5.1.1. Management Structure 5.1.2. Communication channels 5.2 5.3 Controlled Decentralized Controlled Centralized Team Structure

6. Critical Practices
6.1 6.2. Formal risk management Empirical Cost and Schedule Estimation

6.3. Metric-bases project management 6.4. Earned value tracking 6.5. Defect tracking against quality target 7. Software Size Estimation 7.1 Objectivity 7.2 Comparable 7.3 Deliverable 7.4 Independent of technology 7.5 Mostly Used Mechanisms 7.5.1 LOC

7.5.2 7.5.3

FP Comparison between LOC and FP

7.5.4 Productivity of H.L.L (high level language):7.5.5 IFPUG (International functional point user group):7.5.6 ILF (internal logic file):7.5.7 EIF (External interface file):7.6 Estimating Software Cost:7.7 Estimation Techniques:7.7.1 Problem:7.7.2 Determining development effort:7.8 Why Estimate Software:7.8.1 Resource:-

8. Bibliography

SOFTWARE PROJECT MANAGEMENT (SPM)

Software Project Management (SPM) is the scientific as well as artistic technique to plan, manage and complete a software project. It Includes the Following:

1. Factors Influence SPM:

1.1 Project Size
The size of the project is always important, the cost estimation and time management also rely on the project. A good project manager should predict the project size. The project manager should be efficient for predicting software size under its analysis phase. If the manager knows the complete and accurate size of the software, then all other phases of software development life cycle will be easy to schedule. The size is also much important for cost estimation. Like we use a method in cost estimation called LOC (Lines of code). For this, we must know the size of project.

1.2 Delivery Deadline

There is always a delivery deadline of the project. We must complete the project in a given time. Generally saying, time and cost are inversely proportional to each other. If we want to decrease the time, we must increase the cost. The higher the cost, the lesser the time it is. If If any software team is not able to deliver the project at the given deadline. It well be resulted as a failure. That failure can be customer dissatisfaction, financial loss and can result as bad impact on customer as well as other stakeholders.

1.4

Application Domain A domain in software engineering is a set of related software systems that share common design features. [19]
In other words, we can say that an application domain refers to the category of applications. Project manager must decide the right application domain and should schedule the project according to that application domain. If the application is not defined, it may cause problems and customer can be satisfied. In the analysis and requirement engineering phase, the application domain should be confirmed.

1.4 System Constraints A constraint is a restriction on the degree of freedom you have in providing a solution. [20]

Constraints are effectively global requirements, such as limited development resources or a decision by senior management that restricts the way you develop a system. [21] Constraints are things that we live within our daily lives, accept them, and move on. With software engineering groups that are well-established and have strong leadership, constraints can get legs of their own and become excuses for not delivering projects on time, not building something correctly, or even stepping outside Enterprise Goals because they do not fit within our design. [22]
Constrains are the restrictions on our projects. Constraints can be political, social, technical, and environmental and can also be dependent on our software project feasibility.

1.5 Budgeting
Budgeting leads to the software crisis. This definition of software engineering defines importance of budgeting:

Software engineering is the branch of software that deals with development of well developed software that satisfies all the users' requirements and ensures that the software is provided on time and within budget. [23]
So, software engineering is the branch of technology responsible for completing the software within a given (defined) budget. However, this definition tells us about the importance of budgeting. If a project is not completed within a budget which was decided earlier, then it leads the software team to software crisis. So, in the analysis phase the project should be analyzed with i6ts budget as well as time.

1.6

Technology

Technology also influences software project management. Project should be managed as concerned with the appropriate technology according to the time and cost.

Software project must be compatible with the technology that is alive in the market. For example, if software team develops a program which is only compatible with the Intel 16 bit architecture which has been obsolete, then it is useless.

1.7 Resources Allocation Resource allocation is the most important factor. If we allocated resources to the wrong
place or person, it will be resulted in the form of serious danger.

2. The Management Concept)

SPECTRUM

(Four

Ps

Software Project Management is very important part of software engineering. Projects must be managed exactly according to the software engineering standards. Projects must be completed within the organization budget and schedule constraints. Project manager plays a very important role in software project management. Project managers duty is to check whether the project meet exactly according to the predefined specifications and within the budget. Ian Summerville states that Good management cannot guarantee project success. However, bad project management usually results in failure: the software may be delivered late, cost more than the original estimated, or fail to meet the expectations of the customers. The success criteria for project management obviously vary from project to project but, for most projects, important goals are: 1. Deliver the software to the customer at the agreed time. 2. Keep overall cost within the budget. 3. Deliver software that meets the customers satisfaction. 4. Maintain a happy and well functional development team. Software Project Management focuses on four Ps. Project manager is responsible to reinforce the stakeholders, if project manager paying less attention during software development activities or project manager fails to encourage the stakeholders then project may fail. Four Ps of software project management are: 1. 2. 3. 4. People Product Process Product

2.2

The People:

Software Project management is mix of peoples skills. However, leader plays a very essential role in solving the problems. A concrete understanding of the problem is very important because solution must be implemented on root level. Software engineering institute has developed a framework people capability

Every organization needs to continually improve its ability to attract, develop, motivate, organize, and retain the workforce needed to accomplish its strategic business objectives [24]. There are following personalities in the people:
maturity model (PEOPLE-CMM) in recognition of the fact that

2.2.1

The Stakeholders:

Every Software project, stakeholders can be categorized into following five categories. 1. 2. 3. Senior Managers Technical Managers Practitioner

4. Customers 5. End User

2.2.1.1

Senior Manager:

Senior manager has to identify business issues that often have a major influence on a software project. Senior manager is a hub between customer and software.

2.2.1.2 2.2.1.3

Project Manager: Practitioners:

Project Manager who manage, motivate and assign task to practitioners.

Practitioners are fully trained, skilled people who deliver technical skills those are necessary for the application.

2.2.1.4

End User:

End Users are those persons who use software after its development completion.

2.2.2

The Team Leader:

A team leader is a person who has ability to organize and motivate people working on a project. Team leader organize new processes, tools, techniques and provide rewards for software team motivation. Jerry Weinberg suggested an MOI model for leader ship.

MOI MODEL: Motivation: Team leader must motivate programmers to do their best
in form of incentives, good environment, etc.

Organization: Mold existing processes or create new processes to

achieve efficient results.

Innovation: Encourage appropriate level of creativity for each project.

2.2.3 Software Team: 2.2.3.1 Democratic Decentralized:

Software team has not any permanent leader. In this structure coordinator is appointed for a short period. This is recommended approach for a complex and large problems.

2.2.3.2

Controlled Decentralized:

In this structure a team has a project leader. This is again sub-divided and a secondary leader is appointed on sub tasks.

2.2.3.3

Controlled Centralized:

This is managing by team leader the top level problem solving and a team management is performed by a team leader. In this way few benefits are obtained such as: a) b) c) d) e) Difficult problems are solved. The time duration is followed. Software quality is assured. Degree of communication is achieved. Size of the resultant program(s) in lines of code or function points.

To achieve a high performance team: Team members must have in trust with one another. The distribution skills must be appropriate to the problem. Individualists may have to be excluded from the team, if team cohesiveness is to be maintained.

2.2.3.4

Agile Team

Agile software development technique has suggested reliable and provide rapid development for large projects. Agile Team encourage customer satisfaction and early incremental of software, small highly motivated teams, informal methods, minimal software engineering work product, and overall development simplicity.

2.2

The Product:

Software that is built at the request in ordered to meet the objectives and scope of software engineering. This project is referred as software product. Without scope and objectives information it is impossible to estimate accurate cost and effective risk management. Software developers, stakeholders and customer

must define project scope.

2.2.1 Scope: Scope is defined by answering following questions: Context: How does the software to be built fit into a larger system,
product, or business context, and what constraints are imposed as a result of the context?

Information objectives: What customer-visible data objects are

produced as output from the software? What data objects are required for input?

Function and performance. What function does the software

perform to transform input data into output? performance characteristics to be addressed? Are any special

2.2.2

Problem Decomposition:

Problem decomposition some time called a portioning or problem elaboration is an activity that considered the core of software requirement analysis. Ian Summerville states that during project scoping no attempt is made to decompose the problem. Decomposition is applied in two major areas: 1. The functionality must be delivered. 2. The process that will be used to deliver it. We apply the Divide and Conquer strategy to partition a Product into smaller pieces so that can be managed better, as Project Planning begins.

2.3

The Process:

A process is defined as a collection of activities like work, actions, and task are pefromed when the work product is created. Ian summerville states that each of these activities, actions, and task reside within a framework or model that defines their relationship with the process with one another. A generic process framework for software engineering defines five framework activities:

1. Communication 2. Planning

In addition, a set of umbrella activitiesprojecttracking and control, risk management, quality assurance, configuration management, technical reviews, and othersare applied throughout the process. Below is the diagram of software processes:

3. Modeling 4. Construction 5. Deployment

Melding the Product and the Process:

Project planning starts with the merging of the product and the process. Every that is engineering by your team must pass through set of framework activities that are defined for software organization. Below diagram shows the melding the product and the process.

In process there are too many models available like water fall model, prototype model, iterative model, RAD (Rapid application Development), Extreme Programming, RUP (Rational Unified Process). We can use any model according to the requirement.

2.4

The Project:

To make successful project you must understand that problems will cause the errors. In an excellent paper on software projects, John Reel [Ree99] defines 10 signs that indicate that an information systems project is in jeopardy: 1. Software people dont understand their customers needs. 2. The product scope is poorly defined. 3. Changes are managed poorly. 4. The chosen technology changes. 5. Business needs change [or are ill defined]. 6. Deadlines are unrealistic. 7. Users are resistant. 8. Sponsorship is lost [or was never properly obtained]. 9. The project team lacks people with appropriate skills. 10. Managers [and practitioners] avoid best practices and lessons learned.

2.5

The W5HH Principle:

BOEHM suggests an organizing Principle that scales down to provide simple Project Plans for simple Projects. (WWWWWHH: why, what, when, who, where, how, how much). 1. Project Objectives 2. Milestones and Schedules 3. Responsibilities 4. Management and Technical approaches 5. Required Resources

3. Why Project Fails?

Many projects fail due to many causes which affects software and IT industry from growing. We can prevent those failures with effective requirement engineering and analysis phase in software development life cycle. Some causes of project failures are described below:

Changes Engineering)
3.1

in

Customer

Requirement

(Requirement

Usually customers are not able to tell their requirements or the software team is not able to translate them. In both of cases it causes failure of project. Some customers change their requirement after once they clarify them; it causes loss of time as well as cost. To prevent that failure, requirement engineering must me effective because we have to get the requirements completely before the other steps. The person responsible for requirement gathering is known as requirement analyst. 3.2

Ambiguous Requirements

Requirement engineering is the most important phase of software engineering. If we are not clear with the requirements, we cannot continue because if we cant describe and translate requirements of customer, we cannot continue. 3.3

Unrealistic Requirement

Sometimes customers tells the requirements which are not feasible somehow these requirements are not feasible in time, it can also be case of cost, economy, technology, environment and social factors. If the requirements are not real (feasible), then it should be told to the customer in the analysis phase of software development life cycle. 3.4

Unpredictable

One serious cause of failure is the factor that cannot be predicted, these may be disasters. Such threats have two types, one is logical another is physical threat. Logical threats are the failure occurs from viruses, spywares, malwares, Trojan horses, root kits etc. The physical threats can be natural disasters like sand storm, thunder storm, lightening, theft etc. Pakistan and Asia for years. There can be many other causes that are unpredictable using the Project Management rules. 3.5

Technical Difficulties

Another cause of failure is technical difficulty. If we are not able to work with a different or specific technology, then we cannot complete our project that requires such technology. Sometimes project managers try to fraud with customers on the basis of their technical expertise, but it will degrade project manager as well as software team. 3.6

Project Management

If the project is not managed effectively, then it can cause failure. It is the responsibility of the project manager to manager project and schedules it according to right perspective of software project management.

4. Characteristics of project Manager:

A project manager is very vital or key-role of project management, who should have to follow a system approach because system approach will help to view things in a holistic manner or in macro-level as we cannot miss any single piece of task in system approach that are strongly coupled to each other for producing significant results. So, a project manager should have the ability to put many pieces of interconnected and tightly coupled tasks together to form a coherent model or unified system. As far as the responsibilities of a project manager are concerned we can see in figure 4.1 that for a successful completion of a project a manager should not be a specialist of a single field but he or she would have to be a generalist so that he/she can handle all aspects of project management as a good project manager.

Fig-4.1 Keeping in the view above discussed value of project manager and his responsibilities we can issue a checklist of major characteristics of a project manager, that is Problem Solving Skills Managerial Identity Achievement

 Influential Teambuilding Now we discuss these characteristics in a little bit detail to clarify and to verify the importance of these characteristics.

4.1 Problem Solving

Problem solving is a combination of problem definition and alternative identification and analysis to resolve the problems before they may spoil the whole recipe to achieve the final goal. Problem solving skill is one of the most powerful weapons of project manager for the successful completion of the project. Problem solving is the compound of some other skills that are vigilance, esteem analytical power, forecasting and sound experience. The more perfect in these sub skills, more efficient in problem solving which in turn is a big deal.
If there were no problem people there'd problems. Unknown author be no need for people who solve

As a project manager cant leave problem in the way without resolving it. A picture showing this capability of project manager in funny way is shown in figure 4.2[25]

Fig-s4.2

4.2 Managerial identity

An important characteristic of a project manager is his/her ability to know the managerial perspectives. He/she should have full command on assigning right tasks to right persons with appropriate instructions so that loss of time, cost

and quality should be prevented. He/she should know his own authority and command line and he/she should be good in communication with all the team members as well as stakeholders and end users so that any ambiguity or missunderstanding could be avoided. The project manager has authority for coordinating and controlling the job. He/she acts like an umbrella under which all actors are performing their actions in the guidance of project manager to meet the deadline efficiently. Fig4.3 shows the entire responsibility and importance managerial identity of a project manager. [26]

Fig-4.3

4.3 Achievement
Need for achievement (N-Ach) refers to an individual's desire for significant [1] accomplishment, mastering of skills, control, or high standards. Henry Murray

For effective output from team members it is necessary technique for a project manager to allow the subordinates to accomplish their tasks with reasonable incentives, allowances and backups. This technique not only increase the morale of workers it also creates competition among them. It is also necessary that for a fine control over work quality and risk avoidance this technique must

be used in an appropriate manner. Inappropriate rewards for a task completion creates greed among the workers and they try to complete their tasks for their rewards leaving the quality and expected risks far behind. To avoid this situation project manger should have to define the overall objective of each task assigned to the team members in context of quality, risk avoidance and time management.
When a project manager gives out tasks based on achievement there are a number of things he will accomplish.

First, the members of your team will know exactly what he wants. In addition to this, he will give the team members the opportunity to develop a commitment towards the task [28].
The most important aspect of this strategy is that the team members will be satisfied, because they know exactly what is expected of them.

4.4 Influential:
Successful project managers require support from their teams. However, this support cannot be delegated or simply wished into existence. Acquiring the authority to effectively lead a team demands a specific approach. [29] Although a project manager is assigned with many responsibilities along with enough authorities over the project handling and team members but it is not quite enough for a project manager to be an influential project manager. Along with responsibilities and decision making powers some extra qualities are also required for being an influential project manager. A project manager should be humble at times and assertive in others, and know when to take a charge in a situation and when to assign roles to other team members. It is also necessary to assign roles in different team members in such a way that they dont put them self in inferiority or superiority complex. Infallible leader often inspire team members as resistive and rigid leader which spreads desperation among them and low work productivity. It is important for a project manager to understand exactly when and to whom power can be entrusted. Not everyone is cut out for a management role, and some are much happier with strict oversight rather than free reign. Overall essence of an influential project manager is that he is one who knows the strengths and weaknesses of team members and how to deal with them in a way to take an efficient output without losing his influence from the team members in any circumstances.

4.5. Team Building:

For working in a stressed and pressurized environment building a good team is the single most important thing a Project Manager can do to achieve a successful project. With the right attitude, a team will overcome almost any difficulty to succeed in its goals. In most projects there will be times when only the determination of the team can overcome the difficulties and carry the initiative through to success. Even when there is no pressure, the team's spirit and enthusiasm will be reflected in the quality of the solution and the extent to which other people buy-in to it.

The reality is that a sensible balance achieves the best results:[6]

reward vs punishment pleasure vs pain encouragement vs coercion opportunity vs threat

Fig-4.4

5. Software Team:
"[The trick in software engineering is to find out] how to do intellectually-intensive work in teams.]" - R. E. Fairley
Software team structure is vital to study as it holds a driving seat while a software project is on the road of completion. Usually there are three important software team organization methods that are mostly adopted by different groups according to their requirements. All of these three approaches are fair in different situations. Let us discuss three of these for developing our concepts in this regard. We shell discuss: Democratic Decentralized Structure Controlled Decentralization Structure Controlled Centralized Structure

5.1

Democratic Decentralized:
Decentralization means a structure of authorities where a permanent or specific leader or power is not present to handle or to solve all the problems but all of the issues are handled in a combined or collective manner. Democracy means to choose an authority with mutual understanding for a given time period.

Combining these two concepts develops a structure in which an authority is selected with mutual understanding for a specific time to solve the issues and to look after the whole project process. In democratic decentralized structure all problems and relevant issues are discussed and with the help of effective communication, development and research all expected and present problems are solved.

All individuals have varying skills levels and area of expertise.

5.1.1. 5.1.2. Communication channels

Management

Structure

Fig-5.1. An egoless team structure; where authority is dispersed and communication linkages decentralized. [30]

5.2

Controlled Decentralized:

In Controlled Decentralized (CD) team Structure has a permanent leader who primarily coordinates tasks. It has a secondary leader responsible for subtasks. Decisions are solved by group consensus but the implementation is done by subgroups. The communication during implementation is horizontal but control is vertical. [31]

Fig-5.2 5.2.1 Management structure in Controlled Decentralization.

5.2.2. Communication Channels

Fig5.2: Controlled Decentralized team structure. Authority is vested in project manager and senior programmers but communication at each level is decentralized. [32]

5.3

Controlled Centralized Team Structure:

In controlled centralized team str uctur e there is a team leader who makes co-or dination among team member s and take t op level decisions. T h e communication between leader and team members is vertical. The decision on what team struct ure t o employ would depend on the project characteristics. [8, 9]

6. Critical Practices
Critical Practice is the methodology used by a critic or observer to understand and evaluate a field of knowledge. While sometimes the fields of knowledge studied are academic, non-academic fields such as merchandising, law enforcement and medical clinical practice have been extensively studied. Critical practice is grounded in the concepts of critical theory. [14]
A team of Software Engineering experts has developed a list of Critical Software Practices for Performance-based Management; These practices are consistently used by , and considered critical by , highly successful Software Projects and Organizations whose bottom line performance is consistently much better than industry averages.

Critical Practices include the followings

1. 2. 3. 4. 5. 6. Formal Risk Management Empirical Costs and Schedule Estimation Metric-based Project Management Earned Value Tracking Defect Tracking Against Quality Targets People Aware Management
Consultants employing critical practice skills aim to help people improve outcomes. Analysis is applied to groups working in a particular area of expertise and with identifiable practice skills, and usually to a defined range of problems and situations. Thus practice tends be based on a restricted view of people and their problems, with a limited range of values applied in that practice.

The Critical Practices is also known as QUICK LOOK QUESTIONS.

6.1

Formal risk management:

Formal risk management is a policy or program that works to prevent all types of problems arising from risk and uncertainty. Although the actual risk management processes may be different in small and large companies, the problems that arise as a result of poor risk management are the same. Unmanaged risk creates inadequate security and safety measures, which can cause financial loss, erode profits and create unnecessary liabilities. Inadequate risk management can even scare away venture capital funding and lower your bank rating status.
Effective implementation of formal risk management is based on the following set of benefits resulting from the process:

Appropriately tailored risk management strategies are defined and implemented

Potential problems (risks) that could impact project success are identified The likelihood and consequences of these risks are understood A priority order in which risks should be addressed is established Mitigation alternatives appropriate for each potential problem are carefully considered based on project circumstances Optimized mitigation techniques for all risks above their thresholds are selected Contingency plans in case the risk mitigates are developed proactively, rather than as a result of fire -fighting Information to improve risk management policies is captured, analyzed and acted upon Risk management processes/procedures are systematically and periodically reviewed and improved to further reduce risk.

6.2.

Empirical Cost and Schedule Estimation:

Cost models were derived from the collection and analysis of large collections of project data. Modelers would fit a curve to the data and analyze those parameters that affected the curve. Early models applied to custom-developed software systems. New software development philosophies and technologies have emerged in the 1980s and 1990s to reduce development costs and improve quality of software products. These new approaches frequently involve the use of Commercial-Off-The-Shelf (COTS) software, software reuse, application generators, and fourth generation languages.

6.3.

Metric-bases project management:

Metric is a quantitative measure of the degree to which a system, a component, or a process possesses a given attribute. Software process and projects metrics are quantitative measure that enables software engineers to gain insight into the efficiency of the software process and the projects conducted using the process framework. In software Successful implementation of Earned Value project management, we are primarily concerned with productivity Management principles can result in metrics. The Better Visibility into Program

6.4.

Earned value tracking:

Performance Reduced Cycle Time to Deliver a Product Increased Accountability Reduced Risk

Earned value management, which is used to track earned value, is an integrated system of project management and control that enables a Contractor and their customer to monitor the progress of a project in terms of integrated cost, schedule, and technical performance measures. The Contractor/developer owns the process but the Acquirer/customer has full and timely visibility of the information contained within it. Traditional project management practice tends to compare actual costs with planned expenditures, and confuses actual costs with actual progress. EVM provides a third reference point that is an objective view of the status of the effort, i.e., the value to the end goal of the work completed to date.

6.5.

Defect tracking against quality target:

Defects should be tracked according to a planned, documented process, measured against established targets, and systematically tracked through to removal or resolution.

Defect tracking against quality targets entails recording defects in a database; following a documented process to analyze, resolve, and remove them; tracking the process; measuring defects against quality targets; and reporting metrics on the process to program management. [15]

Questionnaire To Determine If You Are Practicing Defect Tracking Against Quality Targets
1.What kind of defects do you track (faults, failures or both)? 2. What is your delivered quality target? What evidence do you have that you are currently managing

toward that target? 3. What kind of analysis do you perform on defect data? How are results used (e.g., tracking

improvement, prediction)? 4. How many defects are currently open? What are their priorities? 5. How are metrics on defect data gathered and analyzed to provide feedback to management?

The Airline Council is a team of Software engineering experts chartered by the U.S. Department of Defense to help develop guidelines for the best practices in software project management and software engineering.

6. How do you project expected defects?

If a software project team cannot answer the questions or answered them inadequately, a thorough review of project practice is indicated. [16]

Quick Look Questions Presented by [Air99]

Question Related with Formal risk management:

What are the top ten risks for this project? For each risk , what is the chance that the risk will become a problem and what is the impact if it does.

Question Related with Empirical Cost and Schedule Estimation:

What is the current estimated size of the application software that will be delivered into operation? How was it derived?

Question Related with Metric-bases project management:

Do you have in place a metrics program to give an early indication of evolving problems? If so, what is the current requirement volatility?

Question Related with Earned value tracking:

Do you report monthly earned value metrics? If so, are these matrices computed from an activity network of task for the entire effort to the next delivery?

Question Related with Defect tracking against quality target:

Do you track and periodically report the number of defects found by each inspection and execution test from inception and the number of defects currently closed and open?

People-aware program management: What is the average staff turnover for the past three months for each of the
suppliers/developers involved in the development of software for this system?

[17]

16 Critical Software Practices

(Latest Research)

The SPMN was established in 1992 by the Assistant Secretary of the Navy to identify proven industry and government software best practices and convey these practices to managers of large-scale system acquisition programs. The SPMN Practices TM specifically address underlying cost and schedule drivers that have caused many software intensive systems to be delivered over budget, behind schedule and with significant performance shortfalls. The "16 Critical Software Practices TM for Performance-based Management" and Templates contain the 16 practices (9 best and 7 sustaining) that are the key to avoiding significant problems for software development projects. These practices have been gathered from the crucible of real-world, large-scale, software development and maintenance projects. Together they constitute a set of high-leverage disciplines that are focused on improving a project's bottom line. These practices are the starting point for structuring and deploying an effective process for managing large-scale software development and maintenance. They may be tailored to the particular culture, environment, and program phases of a program. Of course, these practices cannot help "death march" programs that are expected to deliver under impossible schedule deadlines with inadequate funding and without the required staffing with essential skills. PROJECT INTEGRITY 1. ADOPT CONTINUOUS PROGRAM RISK MANAGEMENT 2. ESTIMATE COST AND SCHEDULE EMPIRICALLY 3. USE METRICS TO MANAGE 4. TRACK EARNED VALUE 5. TRACK DEFECTS AGAINST QUALITY TARGETS 6. TREAT PEOPLE AS THE MOST IMPORTANT RESOURCE CONSTRUCTION INTEGRITY
MostThe Airline Council has developed a listStandish software projects fail. In fact, the of group reports that over 80% performance are critical software practices for of projects unsuccessful either because they are are time based management. These practices over budget, after time whose bottom line performance is late, missing function, or a combination. Moreover, consistently much are so poorly executed that 30% of software projects better than industry averages. In an effort before completion they are canceled to enable a software
organization to determine whether a specific project has implemented critical practices, the Airline Council has developed a set of quick Look questions [Air99] for a project.

7. ADOPT LIFE CYCLE CONFIGURATION MANAGEMENT 8. MANAGE AND TRACE REQUIREMENTS 9. USE SYSTEM-BASED SOFTWARE DESIGN 10. ENSURE DATA AND DATABASE INTEROPERABILITY 11. DEFINE AND CONTROL INTERFACES 12. DESIGN TWICE, CODE ONCE 13. ASSESS REUSE RISKS AND COSTS

PRODUCT STABILITY 14. INSPECT REQUIREMENTS 15. MANAGE TESTING AS A 16. COMPILE AND SMOKE TEST FREQUENTLY [18]

AND AND CONTINUOUS

INTEGRITY DESIGN PROCESS

7. Software Size Estimation:In todays era most of the organization used their past experience to estimate the size of their projects, which are not that much quantitative. The real life example of software size estimation is that you are going develop a new house then first you have to determine that how much expenditure you have to put on labor, bricks, infrastructure and on architect design then finally you sum up the whole cost and reached on accurate conclusion that you should have put the that amount which is required, similarly while developing a software you should have to recognize its size under the consideration of LOC and FP etc. However, it is very important to adopt an assessment mechanism. Which are the following? Objectivity Acceptable standard with wide spread used Comparable Deliverable Independent of technology

7.1 Objectivity:The scope and vision of software should be determined under the consideration of software size estimation because if the objective of software is not focusing then an organization will not estimate the cost of the software appropriately. Acceptable standard with wide spread used:The size of software should be according to the given standard providing by ISO (International standard Organization). Also software has an ability that it will be modifiable at according the requirement specification.

7.2 Comparable:Software has some uniqueness so on the bases of that it will be comparable to other software.

7.3 Deliverable:This section determines what the project will deliver and outline of all the work require completing the tasks.

7.4 Independent of technology:-

It means which technological factors your software uses. It helps you to estimate the software size in term of technology is used during the software development process.

7.5 Mostly Used Mechanisms:The mostly used mechanisms are: Line of code (LOC) Functional point (FP)

7.5.1 LOC:It is software metric which is used to calculate the size of the software programs in the context of lines which are type by the programmer during the developing process of programs source code file. It is also used to measure the amount of effort that is needed to create a program, simultaneously to estimate the programming productivity and maintainability of the software.

7.5.2 FP:It is a unit of measurement that is used to determine the amount of business functionality and information system present to a user. In functional point the expense of the single unit is estimated from the past practices. In functional point there are five types of externals to count: 1. External inputs: - data or control inputs (input files, tables, forms, screens, messages, etc.) to the system. 2. External outputs: - data or control outputs from the system 3. External inquiries: - I/O queries which require a response (prompts, interrupts, calls, etc.) 4. External interfaces: - libraries or programs which are approved into and out of the system (I/O routines, sorting procedures, math libraries, runtime libraries, etc.) 5. Internal data files - groupings of data stored internally in the system (entities, internal control files, directories).

Apply these steps to calculate the size of a project: 1. Count or estimate all the occurrences of each type of external. 2. Assign each occurrence a complexity weight. 3. Multiply each occurrence by its complexity weight, and total the results to obtain a function count.

7.5.3 Comparison between LOC and FP:1. Line of code focuses on existing source code as compare to functional point. 2. Line of code is dependent on programming techniques where as functional point is not dependent on programming techniques. 3. Line of code is dependent on the technology while functional point is not dependent on technology. 4. Line of code is a mixture of languages as compare to functional points.

7.5.4 Productivity of H.L.L (high level language):Productivity of high level languages means some languages requires a lot of effort to deliver the required functionality whereas the same functionality is easily deliver by other languages such as assembly and c++ etc . History of FPA (functional point analysis):It includes the following factors: IFPUG ILF EIF

7.5.5 IFPUG (International functional point user group):It is introduced by IBM in 1970s and after that it gain fame and has been adopted as a standard in several organizations.

Example: IEEE recommend is for use in efficiency measurement. UK government recommend functional point analysis standard for the estimation of software size. Australias state agencies adopt this standard. US huge govt. department use functional point analysis. Large companies such as IBM are using this standard from many years.

7.5.6 ILF (internal logic file):Internal logic file is a user restricted group which is linked with logical related data. Its responsibility to control the information within the defined limit of an application also organized the creating, maintaining and delete functions.

7.5.7 EIF (External interface file):External interface file is also a user identifiable group which is linked with logical related data. The most important thing external interfaces file (EIF) is that it holds data reference developed by one or more than one reference within the limit of an application. EIF for an application is must be ILF for another application.

7.6 Estimating Software Cost:The price of the contact mediums and huge software projects are evaluated by the cost of creating the software included the price of equipment and materials. The cost of the developing the software is simply the calculated effort, multiply by most probably the labor cost which is fixed.

7.7 Estimation Techniques:There is no simple way to build an accurate estimate of the effort for a software system. The following techniques are used: Initial estimates based on insufficient information. User requirements definition.

Software may run on unusual environments. Different computers or new technology. The people in the project may be unknown. Project cost estimates may be self-fulfilling. The estimate defines the budget and the product is adjusted to meet the budget.

7.7.1 Problem:The following problems occur during the software size estimation process: The accuracy of the previous equation depends on what? Project Cost = Time X Unit Cost Accuracy of the development effort estimate. Accuracy of the cost per unit. Which one do we normally know?

7.7.2 Determining development effort:It includes the following factors: Person-Month LOC per Hour Function point per hour Requirement per hour Most common is person-months (or hours)

7.8 Why Estimate Software:The following are the reasons which identify that why software should have to be estimated: 30% of project never completes. 100-200% cost overruns not uncommon Average project exceeds cost by 90%;

Schedule by 120% 15% of large project never deliver anything Only 16.2% of projects are successful

7.8.1 Resource:Resource is the very important factor of software size estimation. It means how greater the resource the size of the software is also very large. The most imp resource requires developing software is HRM (human resource management) which includes programmers, managers and administrators etc. It is the responsibility of an organization to manage all the resources on time as well as estimate the cost on those resources during the managing process so that the software will be develops within given budget.

Bibliography
[1] http://en.wikipedia.org/wiki/Application_domain 01:24 PM [2] http://www.agilemodeling.com/artifacts/constraint.htm 01:36 PM [3] http://www.agilemodeling.com/artifacts/constraint.htm 01:38 PM [4] http://danilogurovich.wordpress.com/2007/08/12/software-engineeringconstraints-taking-responsiblity-and-delivering/ 01:40 PM [5] http://voices.yahoo.com/software-engineering-characteristics-well-engineered2930151.html?cat=15 01:46 PM 18-Apr-2012 18-Apr-2012 18-Apr-2012 18-Apr-2012 18-Apr-2012

[6] Curtis, B., W. Hefley, and S. Miller, People Capability Maturity Model, Addison-Wesley, 2001. [7] Chapter 24 Project Management Concept Roger .S. Pressman, (2010), SOFTWARE ENGINEERING: A PRACTITIONERS APPROACH, SEVENTH EDITION Published by McGraw-Hill, a business unit of The McGraw-Hill Companies, Inc., 1221 Avenue of the Americas, New York, NY 10020.

[8] Ian Summerville (2011), SOFTWARE ENGINEERING, Ninth Edition, Pearson Education, Inc., Permissions Department, 501 Boylston Street, Suite 900, Boston, Massachusetts 02116. [9] Project Management Concepts http://sct.emu.edu.tr/gursev/ITEC346/SE%20Lecture%20notes/PP%20 SLIDES/PROJECT%20MANAGEMEN%20CONCEPT.ppt [10] Software Project Management http://www.sei.cmu.edu/reports/89cm021.pdf [11] Four Ps of Software Engineering http://fie-conference.org/fie2007/papers/1029.pdf

[12] Software Project Management http://www.csc.liv.ac.uk/~mjw/teaching/soft-eng/lect05.pdf

[13] Ref: Henry Alexander Murray (May 13, 1893 June 23, 1988) was an American psychologist who taught for over 30 years at Harvard University. [14] Self search over www.google.com/images http://www.exforsys.com/career-center/projectmanagement/achievements-vs-activities-in-project-management.html

[15] http://www.informationmanagement.com/newsletters/project_managem ent_business_rules_BI_ROI-10020851-1.html [16] Article: The Effect of Programming Team Structures on Programming Tasks by Marilyn Mantei, The University of Michigan. Page #107 [17] http://www.epmbook.com/team.htm [18] Article: The Effect of Programming Team Structures on Programming Tasks by Marilyn Mantei, The University of Michigan. Page #109 [19] Article: The Effect of Programming Team Structures on Programming Tasks by Marilyn Mantei, The University of Michigan. Page #111 [20] http://www.allbusiness.com/glossaries/decentralization/49525071.html [21] Article written by Brechin, H. Brown and M. Eby Critical Practice in Health and Social Care (eds) Sage 2000. (http://en.wikipedia.org/wiki/Critical_Practice) [22] SOFTWARE ACQUISITION GOLD PRACTICE (The Data and Analysis Center for Software) https://goldpractice.thedacs.com/practices/frm/index.php

[23]

BOOK: Software Engineering A Practitioners Approach

[24]

Software Programs Network est. 1992

http://www.spmn.com/www2/16CSP.html#cost

[25] http://www.spc.ca/resources/metrics/software_estimation.pdf [26] http://www.cs.cmu.edu/~aldrich/courses/413/slides/4-estimation.pdf [27] http://en.wikipedia.org/wiki/Source_lines_of_code [28] Book: Software Engineering A Practitioners approach (seventh edition), chp#26, pg#691