This action might not be possible to undo. Are you sure you want to continue?
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 P’s—people, 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 p’s: 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 process—definition, development, and support—are 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
understand the critical success factors that lead to good project management. Organization: The ability to mold existing processes (or invent new ones) that will enable the initial concept to be translated into a final product. 4. 2. But such teams may struggle when “orderly performance” is required. Open paradigm team structures are well suited to the solution of complex problems but may not perform as efficiently as other teams. The main job of the agile team is to provide customer satisfaction and early incremental delivery. but they will be less likely to be innovative when working within the closed paradigm. Project (technical) managers who must plan. These are small teams and . When innovation or technological breakthrough is required. Q. Senior managers who define the business issues that often have significant influence on the project. 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. 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. Agile teams: These teams works as an antidote to many team problems. Practitioners who deliver the technical skills that are necessary to engineer a product or application. and develop a commonsense approach for planning. A closed paradigm structures a team along a traditional hierarchy of authority (similar to a CC team). organize. 3. 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. teams following the random paradigm will excel. 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 random paradigm structures a team loosely and depends on individual initiative of the team members. motivate. 4. and control the practitioners who do software work. MOI model of leadership suggests: Motivation: The ability to encourage (by “push or pull”) technical people to produce to their best ability. End-users who interact with the software once it is released for production use. Customers who specify the requirements for the software to be engineered and other stakeholders who have a peripheral interest in the outcome. Team Leader: To be effective. The Software Team: Four “organizational paradigms” for software engineering teams: 1. 3. with heavy communication and consensus-based decision making the trademarks of open paradigm teams. Such teams can work well when producing software that is quite similar to past efforts. And that’s the job of the team leader. the project team must be organized in a way that maximizes each person’s skills and abilities. 5. 2. monitoring and controlling the project. Work is performed collaboratively. 4.avoid a set of common warning signs.
software process and project measures can be collected and used to assess progress against averages developed for the software development organization.work informally and have simplicity in overall development. • Orient the project team to the project management plan. o Tailor the standard process to meet project requirements. get feedback from team members and customers. Make smart decisions: In essence. decide to avoid custom interfaces when standard approaches are available. and decide to allocate more time than you think is needed to complex or risky tasks (you’ll need every minute). Q. the team should emphasize quality in every task it performs.g. List the major activities of the project manager during Project planning phase. • Create a project plan and schedule. o Define a process for managing changes in requirements. Maintain momentum: Many projects get off to a good start and then slowly disintegrate. o Define project-tracking procedures. In addition. It is reinforced by building the right team and giving the team the autonomy. and senior management should do everything possible to stay out of the team’s way. progress is tracked as work products (e. o Define the project milestones and create a schedule. 2. the decisions of the project manager and the software team should be to “keep it simple.5. o Identify risks and make plans to mitigate them. o Identify a suitable standard process for project execution. Q. o Define a measurement plan for the project. 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. o Define the quality objectives and a quality plan to achieve them. collect and analyze software project metrics. specifications. o Define a training plan for the project. Track progress: For a software project.6. 5. To maintain momentum. Conduct a postmortem analysis: Establish a consistent mechanism for extracting lessons learned for each project.. source code. . o Plan for human resources and team organization. 3. decide to identify and then avoid obvious risks. o Define the project objectives. Evaluate the planned and actual schedules. Define and review the configuration management plan. Ans: • Perform startup and administrative tasks. and record findings in written form. authority.” Whenever possible. • Obtain authorization from senior management. sets of test cases) are produced and approved (using formal technical reviews) as part of a quality assurance activity. and technology needed to do the job. The team are self-organizing and adapts their own approach. decide to use commercial off-the-shelf software or existing software components. • Perform a review of the project plan and schedule. o Make a defect prevention plan. the project manager must provide incentives to keep turnover of personnel to an absolute minimum. o Estimate the effort. 4. 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.
The customer. Q. or the process to make things better.7. a management and technical strategy for the project must be defined. the project. • An indicator is a metric or combination of metrics that provide insight into the software process. • Conduct milestone reviews and replan if necessary. amount. • The IEEE Standard Glossary of Software Engineering Terms defines metric as “a quantitative measure of the degree to which a system. component. 9. or size of some attributes of a product or process. does the business purpose justify the expenditure of people. How much of each resource is needed? The answer to this question is derived by developing estimates based on answers to earlier questions. responsibilities. • provides a quantitative indication of the extent. . metrics. capacity. and money? What will be done. Q. 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. or the product itself. List the major activities of the project manager during Project execution phase. and indicator. and other stakeholders also have responsibilities. 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. • Monitor compliance with the defined project process. 8. • Review the project status with senior management.” Boehm suggests an approach that addresses project objectives. o Metrics. Define these terms: measure. How will the job be done technically and managerially? Once product scope is established. Who is responsible for a function? The role and responsibility of each member of the software team must be defined. Ans: o Measure. or process possesses a given attribute. • Monitor performance at the program level. a software project. milestones and schedules. • Track the project status. Ans: • Execute the project as per the project plan. Stated in another way. management and technical approaches.Q. The answer to this question helps accomplish this.” o Indicator. users. • Analyze defects and perform defect prevention activities. time. and required resources. 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. dimension. Where are they organizationally located? Not all roles and responsibilities reside within the software team itself. An indicator provides insight that enables the project manager or software engineers to adjust the process.
This leads to a reduction in overall project cost. modify the technical approach to improve quality. of items covered / total no. Metrics are collected to assess Design Quality and to provide indicators that effect the approach taken to Code Generation and Testing. / total no. Number of user inputs = 32 Number of user outputs = 60 Number of user inquiries = 24 Number of files = 8 . Second. • As the Software evolves from Requirements into Design. of defects detected / total no. defects are minimized. of initial req. Review Hours. First. Function Points .Q.12. List out the applications of Project Metrics. and Errors uncovered during each Software Engineering tasks.13 Explain how FP counted for an ongoing project. Metrics collected from the past Projects are used as a basis from which ‘‘Effort and Time Estimates’’ are made for current Software work. Compute the function point value for a project with the following information domain characteristics. and as the defect count goes down. the amount of rework required during the project is also reduced. when necessary. these metrics are used to minimize the development schedule by making the adjustments necessary to avoid delays and mitigate potential problems and risks. of items) • System spoilage (efforts spent fixing faults / total project effort) Q. 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. As quality improves. of defects) • Requirement Stability (no. Ans: • For “Project Estimation’’. • Production Rates (represented in terms of Models created). • to Monitor and Control Progress As a Project proceeds by comparing Measures of Effort and Calendar Time expended (Actual Times) to Original Estimates. 11. project metrics are used to assess product quality on an ongoing basis and.) • Test effectiveness ratio (no. Q. 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. of req. Q. 10 How should we use metrics during the project itself? Ans: The intent of project metrics is twofold. Delivered Line of Source Codes (LOC) . 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.
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. Ans: Function-oriented software metrics use a measure of the functionality delivered by the application as a normalization value.e. Number of files: Each logical master file (i. the determination of complexity is somewhat subjective.01 * Σ(Fi)] where count total is the sum of all FP entries obtained from Figure. 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. The various complexity adjustment values are average. Will the system run in an existing. a complexity value is associated with each count. it must be derived indirectly using other direct measures.Number of external interfaces = 2 Assuming the weighting factors values are average. Does the system require on-line data entry? . which are counted separately. Once these data have been collected. or complex. Is performance critical? 5.. Five information domain characteristics are determined and counts are provided in the appropriate table location.65 + 0. the following relationship is used: FP = count total _ [0. The Fi (i = 1 to 14) are "complexity adjustment values" based on responses to the following questions [ART85]: 1. Are there distributed processing functions? 4. etc. data files on storage media) that are used to transmit information to another system are counted. heavily utilized operational environment? 6. Each distinct inquiry is counted. These metrics are measured by function points. Number of external interfaces: All machine readable interfaces (e. Are data communications required? 3. Function points are derived using an empirical relationship based on countable (direct) measures of software's information domain and assessments of software complexity. average. Since ‘functionality’ cannot be measured directly. Function points are computed by completing the table shown in Figure. Inputs should be distinguished from inquiries. a logical grouping of data that may be one part of a large database or a separate file) is counted. Organizations that use function point methods develop criteria for determining whether a particular entry is simple.. Nonetheless. To compute function points (FP). In this context output refers to reports. screens. error messages. Number of user outputs: Each user output that provides application oriented information to the user is counted. Does the system require reliable backup and recovery? 2.g.
development method. a language is more productive compared with others within an organization or among organizations. Is the system designed for multiple installations in different organizations? 14. then all Fi’s values are 3. . Ans: Advantages Function Point Analysis provides the best objective method for sizing software projects.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.07 = 661. €(Fi) = 14 * 3 = 42 The complexity adjustment factor (CAF) = 0. and for managing the size during development. The only variable is the amount of effort needed to deliver a given set of FP. F1 = F2 = F3 = ……. = F14 = 3 So.65 + 0. Regardless of language. Does the on-line data entry require the input transaction to be built over multiple screens or operations? 8.. Are the inputs. (a) Helps Comparison: Since Function Points measures systems from a functional perspective they are independent of technology. This is a critical point and one of the greatest values of Function Point Analysis. Are the master files updated on-line? 9. an environment.7. Following are some of the many advantages that FPA offers. outputs.14 List out the pros and cons of Function point. therefore. 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. or hardware/platform used.65 + 0. Are conversion and installation included in the design? 13.01 * €(Fi) = 0. files.42 = 1.01 * 42 = 0. Is the code designed to be reusable? 12. 32 60 24 8 2 128 300 96 80 14 618 Function point = Count_total * CAF = 618 * 1. 4. 3. 5. Computation of the function point for the given project data As various complexities adjustment values are average. or inquiries complex? 10.65 + 0. Function Point Analysis can be used to determine whether a tool. 2.07 Now. Is the internal processing complex? 11.26 Q. the number of FP for a system will remain constant. to find the count total we follow the table S.
there has been scope creep. requiring more test cases. or physical code. and other costs can be computed by using historic data. As new features are added. testing and deployment can be compared. development methodology. the function point metric can also handle this situation very well. and to develop objective measures of cost-effectiveness and quality. technical aspects. the number of interrelationships within the application becomes more complex. unlike Lines of Code data which is much tightly tied to languages requiring many other parameters to be taken into account. FPA does have some disadvantages. . From a vendor perspective. data from similar past projects can be used to produce consistent results. programming practices. Function Points are easily understood by the non-technical user. Effort. (g) Enables Better Communication: FP can help improve communications with senior management since it talks in terms of functionality rather than any implementation details. test cases grow at a faster rate than Function Points. projects using FP become better candidates for benchmarking across organizations and geographies. FP counts at the end of requirements. (c) Ease of Contract Negotiations: From a customer view point. maintenance effort which can help pinpoint opportunities for improvement. Caper Jones estimates that Function Points raised to the 1. Disadvantages Function Points offer vast number of benefits by capturing the size of the software from its functionality standpoint. analysis. This is logically valid because as an application grows. Many empirical formulae have been suggested by Caper Jones which are in wide use among FP practitioners. (e) Use of Historic Data: Once project size has been determined in Function Points. Function Points can be used to help specify to a vendor. Function Points have to be counted manually.2) estimates the number of test cases. Further more. LOC pertains to and is an outcome of only one of the phases. and reflect true state. organizations can easily overcome these problems by practicing FPA consistently over a period of time. (a) Requires Manual Work: Due to its very nature. and technology domain. If the project has grown. However. (h) Offers Better Benchmarking: Since FP is independent of language. Note: Here. (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. FP can be used more effectively to develop many predictive formulae such as defect potential. The counting process cannot be automated. the function point total will go up accordingly. (f) Availability of Empirical Formulae: Unlike lines of code.(b) Helps Monitor Scope Creep: Function Point Analysis can provide a mechanism to track and monitor scope creep. Whereas.2 power (FP1. If the organization decides to remove features or defer them to a subsequent release. to ensure appropriate levels of functionality will be delivered. The FP count at the end of requirements and/or designs can be compared to FP actually delivered. code. 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. successful management of fixed price contracts depends absolutely on accurate representations of effort. The amount of growth is an indication of how well requirements were gathered by and/or communicated to the project team. They are most effectively used with fixed price contracts as a means of specifying exactly what will be delivered. Since FP is independent of languages or tools. If the amount of growth of projects declines over time it is a natural assumption that communication with the user has improved. the key deliverables. 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. This helps communicate sizing information to a user (or customer) as well. design. estimates for Duration. That is.
the overall value of DRE begins to approach 1. As E increases (for a given value of D). DRE encourages a software project team to institute techniques for finding as many errors as possible before delivery. Q. (c) Simple to measure Disadvantages 1. That is. For example it cannot measure the size of specification. database tables. It characterize only one specific view of size. no defects are found in the software. It is language dependent 5. it exists only in the logical space. 16 What is defect removal efficiency? Ans: DRE is a measure to detect defects before delivery. Realistically. It is defined on code. outputs. which are comparatively difficult to understand. manual counting effort can be easily eliminated by automating the counting process. Bad software design may cause excessive line of code 4. 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. When considered for a project as a whole. it takes no account of functionality or complexity 3. (c) Requires Experience: Function Point Analysis requires good deal of experience if it were to be done precisely. Thus. screens. a code counting utility developed for a specific language cannot be used for other languages due to the syntactical and structural differences among languages. In fact. D will be greater than 0. 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. DRE is the percentage of bugs eliminated by reviews. and even records and fields will be required to perform FPA accurately. as E increases. inspections. FPA inherently requires sufficient knowledge of the counting rules. Small utilities may be developed for counting the LOC in a program. tests etc. The ideal value for DRE is 1. LOC comes in handy to express the size of software among programmers with low levels of experience. it is likely that the final value of D will decrease (errors are filtered out before they become defects). Typically this is not the case with any development project where the requirements are not clear to this level of detail. namely length. If used as a metric that provides an indicator of the filtering ability of quality control and assurance activities. . Ans: Advantages (a) Scope for Automation of Counting: Since Line of Code is a physical entity. 2. in the beginning. Users cannot easily understand it Q. However. (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. but the value of DRE can still approach 1. This way. Information on inputs.15 List out the pros and cons of LOC metrics used for estimation. Function Point is more of an objective metric which cannot be imagined as being a physical entity.(b) Necessitates Significant Level of Detail: A great level of detail is required to estimate the software size in terms of Function Points.
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). . 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. the requirements analysis task produces an analysis model that can be reviewed to find and correct errors. When used in this context. That is. A quality objective for a software team (or an individual software engineer) is to achieve DREi that approaches 1.DRE can also be used within the project to assess a team’s ability to find errors before they are passed to the next framework activity or software engineering task. For example. errors should be filtered out before they are passed on to the next activity.