Questions Bank for SPM UNIT - I

Q. 1. Why should project managers follow Project management processes? Ans: Processes represent collective knowledge. Using them increases your chances of success. A process may have some extra steps, but you will not always know beforehand which ones are not needed, and hence you will increase your risks by taking shortcuts. Without processes, you cannot predict much about the outcome of your project. You and the organization cannot learn effectively without having defined processes. And learning and improvement are imperative in today's knowledge-based world. Processes lower your anxiety level. The checklists inevitably cover 80 percent of what needs to be done. Hence, your task reduces to working out the remaining 20 percent. Q. 2. What are the steps of project management? Ans: Understand the four Pspeople, product, process, and project. People must be organized to perform software work effectively. Communication with the customer must occur so that product scope and requirements are understood. A process must be selected that is appropriate for the people and the product. The project must be planned by estimating effort and calendar time to accomplish work tasks: defining work products, establishing quality checkpoints, and establishing mechanisms to monitor and control work defined by the plan. Q.3. Ans: Explain the management spectrum. Effective software project management focuses on the four ps: people, product, process, and project. The People: The "people factor" is so important that the Software Engineering Institute has developed a people Capability Maturity Model (people-CMM). The people capability maturity model defines the following key practice areas for software people: staffing, communication and coordination, work environment, performance management, training, compensation, competency analysis and development, career development, workgroup development, team/culture development, and others. The People-CMM is a companion to the software Capability Maturity/ Model-Integration that guides organizations in the creation of a mature software process. The Product: Before a project can be planned, product objectives and scope should be established, alternative solutions should be considered and technical and management constraints should be identified. Software project scope must be unambiguous and understandable at the management and technical levels. During the scoping activity product will be decomposed in two major areas: (1) the functionality that must be delivered and (2) the process that will be used to deliver it. The Process: The generic phases that characterize the software processdefinition, development, and supportare applicable to all software. The project manager must decide which process model is most appropriate for (1) the customers who have requested the product and the people who will do the work, (2) the characteristics of the product itself, and (3) the project environment in which the software team works. When a process model has been selected, the team then defines a preliminary project plan based on the set of common process framework activities. Once the preliminary plan is established, process decomposition begins. The Project: In order to manage a successful software project, we must understand what can go wrong (so that problems can be avoided) and how to do it right. In order to avoid project failure, a software project manager and the software engineers who build the product must

avoid a set of common warning signs, understand the critical success factors that lead to good project management, and develop a commonsense approach for planning, monitoring and controlling the project. Q. 4. Who participate in the software process to perform effective software engineering? Ans: The Players: The software process (and every software project) is populated by players who can be categorized into one of five constituencies: 1. Senior managers who define the business issues that often have significant influence on the project. 2. Project (technical) managers who must plan, motivate, organize, and control the practitioners who do software work. 3. Practitioners who deliver the technical skills that are necessary to engineer a product or application. 4. Customers who specify the requirements for the software to be engineered and other stakeholders who have a peripheral interest in the outcome. 5. End-users who interact with the software once it is released for production use. Team Leader: To be effective, the project team must be organized in a way that maximizes each persons skills and abilities. And thats the job of the team leader. MOI model of leadership suggests: Motivation: The ability to encourage (by push or pull) technical people to produce to their best ability. Organization: The ability to mold existing processes (or invent new ones) that will enable the initial concept to be translated into a final product. Ideas or innovation: The ability to encourage people to create and feel creative even when they must work within bounds established for a particular software product or application. The Software Team: Four organizational paradigms for software engineering teams: 1. A closed paradigm structures a team along a traditional hierarchy of authority (similar to a CC team). Such teams can work well when producing software that is quite similar to past efforts, but they will be less likely to be innovative when working within the closed paradigm. 2. The random paradigm structures a team loosely and depends on individual initiative of the team members. When innovation or technological breakthrough is required, teams following the random paradigm will excel. But such teams may struggle when orderly performance is required. 3. The open paradigm attempts to structure a team in a manner that achieves some of the controls associated with the closed paradigm but also much of the innovation that occurs when using the random paradigm. Work is performed collaboratively, with heavy communication and consensus-based decision making the trademarks of open paradigm teams. Open paradigm team structures are well suited to the solution of complex problems but may not perform as efficiently as other teams. 4. The synchronous paradigm relies on the natural compartmentalization of a problem and organizes team members to work on pieces of the problem with little active communication among themselves. Agile teams: These teams works as an antidote to many team problems. The main job of the agile team is to provide customer satisfaction and early incremental delivery. These are small teams and

work informally and have simplicity in overall development. The team are self-organizing and adapts their own approach. Q.5. What are basic practices required to assurance good management of successful software project? Ans: Reel suggests a five-part commonsense approach to software projects: 1. Start on the right foot: This is accomplished by working hard (very hard) to understand the problem that is to be solved and then setting realistic objects and expectations for everyone who will be involved in the project. It is reinforced by building the right team and giving the team the autonomy, authority, and technology needed to do the job. 2. Maintain momentum: Many projects get off to a good start and then slowly disintegrate. To maintain momentum, the project manager must provide incentives to keep turnover of personnel to an absolute minimum, the team should emphasize quality in every task it performs, and senior management should do everything possible to stay out of the teams way. 3. Track progress: For a software project, progress is tracked as work products (e.g., specifications, source code, sets of test cases) are produced and approved (using formal technical reviews) as part of a quality assurance activity. In addition, software process and project measures can be collected and used to assess progress against averages developed for the software development organization. 4. Make smart decisions: In essence, the decisions of the project manager and the software team should be to keep it simple. Whenever possible, decide to use commercial off-the-shelf software or existing software components, decide to avoid custom interfaces when standard approaches are available, decide to identify and then avoid obvious risks, and decide to allocate more time than you think is needed to complex or risky tasks (youll need every minute). 5. Conduct a postmortem analysis: Establish a consistent mechanism for extracting lessons learned for each project. Evaluate the planned and actual schedules, collect and analyze software project metrics, get feedback from team members and customers, and record findings in written form. Q.6. List the major activities of the project manager during Project planning phase. Ans: Perform startup and administrative tasks. Create a project plan and schedule. o Define the project objectives. o Identify a suitable standard process for project execution. o Tailor the standard process to meet project requirements. o Define a process for managing changes in requirements. o Estimate the effort. o Plan for human resources and team organization. o Define the project milestones and create a schedule. o Define the quality objectives and a quality plan to achieve them. o Make a defect prevention plan. o Identify risks and make plans to mitigate them. o Define a measurement plan for the project. o Define a training plan for the project. o Define project-tracking procedures. Perform a review of the project plan and schedule. Obtain authorization from senior management. Define and review the configuration management plan. Orient the project team to the project management plan.

Q.7. List the major activities of the project manager during Project execution phase. Ans: Execute the project as per the project plan. Track the project status. Review the project status with senior management. Monitor compliance with the defined project process. Analyze defects and perform defect prevention activities. Monitor performance at the program level. Conduct milestone reviews and replan if necessary. Q. 8. What questions need to be answered in order to develop a project plan? (Explain the W5HH principle) Ans: Barry Boehm states: you need an organizing principle that scales down to provide simple [project] plans for simple projects. Boehm suggests an approach that addresses project objectives, milestones and schedules, responsibilities, management and technical approaches, and required resources. He calls it the WWWWWHH principle, after a series of questions that lead to a definition of key project characteristics and the resultant project plan: Why is the system being developed? The answer to this question enables all parties to assess the validity of business reasons for the software work. Stated in another way, does the business purpose justify the expenditure of people, time, and money? What will be done, by when? The answers to these questions help the team to establish a project schedule by identifying key project tasks and the milestones that are required by the customer. Who is responsible for a function? The role and responsibility of each member of the software team must be defined. The answer to this question helps accomplish this. Where are they organizationally located? Not all roles and responsibilities reside within the software team itself. The customer, users, and other stakeholders also have responsibilities. How will the job be done technically and managerially? Once product scope is established, a management and technical strategy for the project must be defined. How much of each resource is needed? The answer to this question is derived by developing estimates based on answers to earlier questions. Q. 9. Define these terms: measure, metrics, and indicator. Ans: o Measure. provides a quantitative indication of the extent, amount, dimension, capacity, or size of some attributes of a product or process. o Metrics. The IEEE Standard Glossary of Software Engineering Terms defines metric as a quantitative measure of the degree to which a system, component, or process possesses a given attribute. o Indicator. An indicator is a metric or combination of metrics that provide insight into the software process, a software project, or the product itself. An indicator provides insight that enables the project manager or software engineers to adjust the process, the project, or the process to make things better.

Q. 10 How should we use metrics during the project itself? Ans: The intent of project metrics is twofold. First, these metrics are used to minimize the development schedule by making the adjustments necessary to avoid delays and mitigate potential problems and risks. Second, project metrics are used to assess product quality on an ongoing basis and, when necessary, modify the technical approach to improve quality. As quality improves, defects are minimized, and as the defect count goes down, the amount of rework required during the project is also reduced. This leads to a reduction in overall project cost.

Q. 11. What is the difference between direct and indirect measures? Ans: Direct Measurement o Direct measurement of an attribute of an entity involves no other attribute or entity. o Following direct measures are commonly used in SE Length of source code (measured by lines of code) Duration of testing process (measured by elapsed time in hours) Number of defects discovered during the testing process (measured by counting defects) Time a programmer spends on a project (measured by months worked) Indirect Measurement o Indirect measurement of an attribute of an entity involves other attribute or entity. o Following indirect measures are commonly used in SE Programmer Productivity (LOC Produced / person months of effort) Module Defect Density (number of defects / module size) Defect detection efficiency (no. of defects detected / total no. of defects) Requirement Stability (no. of initial req. / total no. of req.) Test effectiveness ratio (no. of items covered / total no. of items) System spoilage (efforts spent fixing faults / total project effort) Q.12. List out the applications of Project Metrics. Ans: For Project Estimation. Metrics collected from the past Projects are used as a basis from which Effort and Time Estimates are made for current Software work. to Monitor and Control Progress As a Project proceeds by comparing Measures of Effort and Calendar Time expended (Actual Times) to Original Estimates. Production Rates (represented in terms of Models created), Review Hours, Function Points , Delivered Line of Source Codes (LOC) , and Errors uncovered during each Software Engineering tasks. As the Software evolves from Requirements into Design, Metrics are collected to assess Design Quality and to provide indicators that effect the approach taken to Code Generation and Testing. Q.13 Explain how FP counted for an ongoing project. Compute the function point value for a project with the following information domain characteristics. Number of user inputs = 32 Number of user outputs = 60 Number of user inquiries = 24 Number of files = 8

Number of external interfaces = 2 Assuming the weighting factors values are average. The various complexity adjustment values are average. Ans: Function-oriented software metrics use a measure of the functionality delivered by the application as a normalization value. Since functionality cannot be measured directly, it must be derived indirectly using other direct measures. These metrics are measured by function points. Function points are derived using an empirical relationship based on countable (direct) measures of software's information domain and assessments of software complexity. Function points are computed by completing the table shown in Figure. Five information domain characteristics are determined and counts are provided in the appropriate table location. Information domain values are defined in the following manner:

Number of user inputs: Each user input that provides distinct application oriented data to the software is counted. Inputs should be distinguished from inquiries, which are counted separately. Number of user outputs: Each user output that provides application oriented information to the user is counted. In this context output refers to reports, screens, error messages, etc. Individual data items within a report are not counted separately. Number of user inquiries: An inquiry is defined as an on-line input that results in the generation of some immediate software response in the form of an on-line output. Each distinct inquiry is counted. Number of files: Each logical master file (i.e., a logical grouping of data that may be one part of a large database or a separate file) is counted. Number of external interfaces: All machine readable interfaces (e.g., data files on storage media) that are used to transmit information to another system are counted. Once these data have been collected, a complexity value is associated with each count. Organizations that use function point methods develop criteria for determining whether a particular entry is simple, average, or complex. Nonetheless, the determination of complexity is somewhat subjective. To compute function points (FP), the following relationship is used: FP = count total _ [0.65 + 0.01 * (Fi)] where count total is the sum of all FP entries obtained from Figure. The Fi (i = 1 to 14) are "complexity adjustment values" based on responses to the following questions [ART85]: 1. Does the system require reliable backup and recovery? 2. Are data communications required? 3. Are there distributed processing functions? 4. Is performance critical? 5. Will the system run in an existing, heavily utilized operational environment? 6. Does the system require on-line data entry?

7. Does the on-line data entry require the input transaction to be built over multiple screens or operations? 8. Are the master files updated on-line? 9. Are the inputs, outputs, files, or inquiries complex? 10. Is the internal processing complex? 11. Is the code designed to be reusable? 12. Are conversion and installation included in the design? 13. Is the system designed for multiple installations in different organizations? 14. Is the application designed to facilitate change and ease of use by the user? Each of these questions is answered using a scale that ranges from 0 (not important or applicable) to 5 (absolutely essential). The constant values in Equation and the weighting factors that are applied to information domain counts are determined empirically. Computation of the function point for the given project data As various complexities adjustment values are average, then all Fis values are 3. F1 = F2 = F3 = .. = F14 = 3 So, (Fi) = 14 * 3 = 42 The complexity adjustment factor (CAF) = 0.65 + 0.01 * (Fi) = 0.65 + 0.01 * 42 = 0.65 + 0.42 = 1.07 Now, to find the count total we follow the table
S.No Measurement Parameter Number of user inputs Number of user inputs Number of user inquiries Number of files Number of external interfaces Count_Total Count Weighting Factor (Average) 4 5 4 10 7 Total

1. 2. 3. 4. 5.

32 60 24 8 2

128 300 96 80 14 618

Function point = Count_total * CAF = 618 * 1.07 = 661.26

Q.14 List out the pros and cons of Function point. Ans: Advantages Function Point Analysis provides the best objective method for sizing software projects, and for managing the size during development. Following are some of the many advantages that FPA offers. (a) Helps Comparison: Since Function Points measures systems from a functional perspective they are independent of technology. Regardless of language, development method, or hardware/platform used, the number of FP for a system will remain constant. The only variable is the amount of effort needed to deliver a given set of FP; therefore, Function Point Analysis can be used to determine whether a tool, an environment, a language is more productive compared with others within an organization or among organizations. This is a critical point and one of the greatest values of Function Point Analysis.

(b) Helps Monitor Scope Creep: Function Point Analysis can provide a mechanism to track and monitor scope creep. FP counts at the end of requirements, analysis, design, code, testing and deployment can be compared. The FP count at the end of requirements and/or designs can be compared to FP actually delivered. If the project has grown, there has been scope creep. The amount of growth is an indication of how well requirements were gathered by and/or communicated to the project team. If the amount of growth of projects declines over time it is a natural assumption that communication with the user has improved. (c) Ease of Contract Negotiations: From a customer view point, Function Points can be used to help specify to a vendor, the key deliverables, to ensure appropriate levels of functionality will be delivered, and to develop objective measures of cost-effectiveness and quality. They are most effectively used with fixed price contracts as a means of specifying exactly what will be delivered. From a vendor perspective, successful management of fixed price contracts depends absolutely on accurate representations of effort. Estimation of this effort (across the entire life cycle) can occur only when a normalized metric such as the one provided by Function Points is applied. Note: Here, my meaning of the word normalized metric is that Function Point truly accounts for the entire gamut of software development spreading across all the phases from Requirements through Testing. Whereas, LOC pertains to and is an outcome of only one of the phases. (d) Handling Volatility: The advantage that Function Points bring to early estimation is the fact that they are derived directly from the requirements and hence show the current status of requirements completeness. As new features are added, the function point total will go up accordingly. If the organization decides to remove features or defer them to a subsequent release, the function point metric can also handle this situation very well, and reflect true state. (e) Use of Historic Data: Once project size has been determined in Function Points, estimates for Duration, Effort, and other costs can be computed by using historic data. Since FP is independent of languages or tools, data from similar past projects can be used to produce consistent results, unlike Lines of Code data which is much tightly tied to languages requiring many other parameters to be taken into account. (f) Availability of Empirical Formulae: Unlike lines of code, FP can be used more effectively to develop many predictive formulae such as defect potential, maintenance effort which can help pinpoint opportunities for improvement. Caper Jones estimates that Function Points raised to the 1.2 power (FP1.2) estimates the number of test cases. That is, test cases grow at a faster rate than Function Points. This is logically valid because as an application grows, the number of interrelationships within the application becomes more complex, requiring more test cases. Many empirical formulae have been suggested by Caper Jones which are in wide use among FP practitioners. (g) Enables Better Communication: FP can help improve communications with senior management since it talks in terms of functionality rather than any implementation details, technical aspects, or physical code. Further more, Function Points are easily understood by the non-technical user. This helps communicate sizing information to a user (or customer) as well. (h) Offers Better Benchmarking: Since FP is independent of language, development methodology, programming practices, and technology domain, projects using FP become better candidates for benchmarking across organizations and geographies. Disadvantages Function Points offer vast number of benefits by capturing the size of the software from its functionality standpoint. FPA does have some disadvantages. However, organizations can easily overcome these problems by practicing FPA consistently over a period of time. (a) Requires Manual Work: Due to its very nature, Function Points have to be counted manually. The counting process cannot be automated.

(b) Necessitates Significant Level of Detail: A great level of detail is required to estimate the software size in terms of Function Points. Information on inputs, outputs, screens, database tables, and even records and fields will be required to perform FPA accurately. Typically this is not the case with any development project where the requirements are not clear to this level of detail, in the beginning. (c) Requires Experience: Function Point Analysis requires good deal of experience if it were to be done precisely. FPA inherently requires sufficient knowledge of the counting rules, which are comparatively difficult to understand. Q.15 List out the pros and cons of LOC metrics used for estimation. Ans: Advantages (a) Scope for Automation of Counting: Since Line of Code is a physical entity; manual counting effort can be easily eliminated by automating the counting process. Small utilities may be developed for counting the LOC in a program. However, a code counting utility developed for a specific language cannot be used for other languages due to the syntactical and structural differences among languages. (b) An Intuitive Metric: Line of Code serves as an intuitive metric for measuring the size of software due to the fact that it can be seen and the effect of it can be visualized. Function Point is more of an objective metric which cannot be imagined as being a physical entity, it exists only in the logical space. This way, LOC comes in handy to express the size of software among programmers with low levels of experience. (c) Simple to measure Disadvantages 1. It is defined on code. For example it cannot measure the size of specification. 2. It characterize only one specific view of size, namely length, it takes no account of functionality or complexity 3. Bad software design may cause excessive line of code 4. It is language dependent 5. Users cannot easily understand it

Q. 16 What is defect removal efficiency? Ans: DRE is a measure to detect defects before delivery. It is calculated as a percentage of the defects identified and corrected internally with respect to the total defects in the complete project life cycle. Thus, DRE is the percentage of bugs eliminated by reviews, inspections, tests etc. When considered for a project as a whole, DRE is defined in the following manner: DRE = E/(E + D) where E is the number of errors found before delivery of the software to the end-user and D is the number of defects found after delivery. The ideal value for DRE is 1. That is, no defects are found in the software. Realistically, D will be greater than 0, but the value of DRE can still approach 1. As E increases (for a given value of D), the overall value of DRE begins to approach 1. In fact, as E increases, it is likely that the final value of D will decrease (errors are filtered out before they become defects). If used as a metric that provides an indicator of the filtering ability of quality control and assurance activities, DRE encourages a software project team to institute techniques for finding as many errors as possible before delivery.

DRE can also be used within the project to assess a teams ability to find errors before they are passed to the next framework activity or software engineering task. For example, the requirements analysis task produces an analysis model that can be reviewed to find and correct errors. Those errors that are not found during the review of the analysis model are passed on to the design task (where they may or may not be found). When used in this context, we redefine DRE as DREi = Ei/(Ei + Ei+1) where Ei is the number of errors found during software engineering activity i and Ei+1 is the number of errors found during software engineering activity i+1 that are traceable to errors that were not discovered in software engineering activity i. A quality objective for a software team (or an individual software engineer) is to achieve DREi that approaches 1. That is, errors should be filtered out before they are passed on to the next activity.