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