Software Project Management by IIMP MCA

CHAPTER 1 PROJECT MANAGEMENT FRAMEWORK WHAT IS A PROJECT? Organizations perform work. Work generally involves either operations or projects,although the two may overlap. Operations and projects share many characteristics;for example, they are: • Performed by people. • Constrained by limited resources. • Planned, executed, and controlled. Operations and projects differ primarily in that operations are ongoing and repetitive while projects are temporary and unique. A project can thus be defined in terms of its distinctive characteristics—a project is a temporary endeavor undertaken to create a unique product or service. Temporary means that every project has a definite beginning and a definite end. Unique means that the product or service is different in some distinguishing way from all similar products or services.Projects are undertaken at all levels of the organization. They may involve a single person or many thousands. They may require less than 100 hours to complete or over 10,000,000. Projects may involve a single unit of one organization or may cross organizational boundaries as in joint ventures and partnering. Projects are often critical components of the performing organization‘s business strategy. Examples of projects include: • Developing a new product or service. • Effecting a change in structure, staffing, or style of an organization. • Designing a new transportation vehicle. • Developing or acquiring a new or modified information system. • Constructing a building or facility. • Running a campaign for political office. • Implementing a new business procedure or process. WHAT IS PROJECT MANAGEMENT? Project management is the application of knowledge, skills, tools, and techniques to project activities in order to meet or exceed stakeholder needs and expectations from a project. Meeting or exceeding stakeholder needs and expectations invariably involves balancing competing demands among: • Scope, time, cost, and quality. • Stakeholders with differing needs and expectations. • Identified requirements (needs) and unidentified requirements (expectations). The term project management is sometimes used to describe an organizational approach to the management of ongoing operations. This approach, more properly called management by projects, treats many aspects of ongoing operations as projects in order to apply project management to them. Although an understanding of project management is obviously critical to an organization that is managing by projects, a detailed discussion of the approach itself is outside the scope of this document. Knowledge about project management can be organized in many ways. [1] ________________________________________________________________________________________________________ Copyright © 2011 by Indira Institute of management (MCA), Pune. {IIMP (MCA)} This online tutorial is compiled with the help of Referred References by Faculty of IIMP (MCA) with the help of ISSUU. For any Query of Copyright Contact: itlibrary@indiraiimp.edu.in

Project management framework (PM framework) is a subset of tasks, processes, tools and templates used in combination by the management team to get insight into the major structural elements of the project in order to initiate, plan, execute, control, monitor, and terminate the project activities throughout the management life-cycle. PM framework allows using various methodologies and approaches to plan and schedule the major phases of the lifecycle. Regardless of the type, size and nature of project, a typical PM framework includes micro & macro phases, templates and checklists, processes and activities, roles and responsibilities, training material and work guidelines â&#x20AC;&#x201C; all this information is organized and systematized into a structure allowing managers and planners to control progress of their projects throughout the lifecycle. The idea behind the project framework is to create and share a clear understanding of the basis of a project and share this understanding among all stakeholders, including the team. The idea should be followed by all the stakeholders throughout the whole management lifecycle, thereby the project will be accomplished according to a chosen methodology and delivering expected results. Basic Elements We tried to create a detailed description of the project framework to allow individuals and groups involved in their projects to review the content of the framework and investigate its basic elements. Following project management best practices, we made a description of PM framework showing the elements in hierarchical order. With reference to the given PM framework definition, there are several basic elements: Initiation. Planning. Execution. Control. Closure. The purpose of PM framework is to: Simplify and assist with sharing information on project management best practices, approaches, tools, templates and samples. Create and share an understanding of the best practices for planning & management for all types and kinds of project, including IT projects, construction projects, etc. Improve the level of competence Contribute to setting common standards and requirements for various projects and establishing common terminology.[2]

________________________________________________________________________________________________________ Copyright ÂŠ 2011 by Indira Institute of management (MCA), Pune. {IIMP (MCA)} This online tutorial is compiled with the help of Referred References by Faculty of IIMP (MCA) with the help of ISSUU. For any Query of Copyright Contact: itlibrary@indiraiimp.edu.in

Project Management Life Cycle Project Management Life Cycle comprises four phases... Initiation involves starting up the project, by documenting a business case, feasibility study, terms of reference, appointing the team and setting up a Project Office. Planning involves setting out the roadmap for the project by creating the following plans: project plan, resource plan, financial plan, quality plan, acceptance plan and communications plan. Execution involves building the deliverables and controlling the project delivery, scope, costs, quality, risks and issues. Closure involves winding-down the project by releasing staff, handing over deliverables to the customer and completing a post implementation review. A more detailed description of the MPMM Project Management Methodology and Life Cycle follows: Project Initiation Project Initiation is the first phase in the Project Life Cycle and essentially involves starting up the project. You initiate a project by defining its purpose and scope, the justification for initiating it and the solution to be implemented. You will also need to recruit a suitably skilled project team, set up a Project Office and perform an end of Phase Review. The Project Initiation phase involves the following six key steps:

Project Planning After defining the project and appointing the project team, you're ready to enter the detailed Project Planning phase. This involves creating a suite of planning documents to help guide the team throughout the project delivery. The Planning Phase involves completing the following 10 key steps:

Project Execution With a clear definition of the project and a suite of detailed project plans, you are now ready to enter the Execution phase of the project. This is the phase in which the deliverables are physically built and presented to the customer for acceptance. While each deliverable is being constructed, a suite of management processes are undertaken to monitor and control the deliverables being output by the project.These processes include managing time, cost, quality, change, risks, issues, suppliers, customers and communication. ________________________________________________________________________________________________________ Copyright ÂŠ 2011 by Indira Institute of management (MCA), Pune. {IIMP (MCA)} This online tutorial is compiled with the help of Referred References by Faculty of IIMP (MCA) with the help of ISSUU. For any Query of Copyright Contact: itlibrary@indiraiimp.edu.in

Once all the deliverables have been produced and the customer has accepted the final solution, the project is ready for closure. Project Closure Project Closure involves releasing the final deliverables to the customer, handing over project documentation to the business, terminating supplier contracts, releasing project resources and communicating project closure to all stakeholders. The last remaining step is to undertake a Post Implementation Review to identify the level of project success and note any lessons learned for future projects.[3] Project Planning Project Planning is an aspect of Project Management that focuses a lot on Project Integration. The project plan reflects the current status of all project activities and is used to monitor and control the project. The Project Planning tasks ensure that various elements of the Project are coordinated and therefore guide the project execution. Project Planning helps Facilitating communication Monitoring/measuring the project progress, and -Provides overall documentation of assumptions/planning decisions The Project Planning Phases can be broadly classified as follows: Development of the Project Plan Execution of the Project Plan Change Control and Corrective Actions Project Planning is an ongoing effort throughout the Project Lifecycle. Typically Project Planning can include the following types of project Planning: 1) Project Scope Definition and Scope Planning 2) Project Activity Definition and Activity Sequencing 3) Time, Effort and Resource Estimation 4) Risk Factors Identification 5) Cost Estimation and Budgeting 6) Organizational and Resource Planning 7) Schedule Development 8) Quality Planning 9) Risk Management Planning 10) Project Plan Development and Execution 11) Performance Reporting 12) Planning Change Management [4]

RISK MANAGEMENT Risk analysis and management are a series of steps that help a software team to understand and manage uncertainty. Many problems can plague a software project. A risk is a potential problem—it might happen, it might not. But, regardless of the outcome, it‘s a really good idea to identify it, assess its probability of occurrence, estimate its impact, and establish a contingency plan should the problem actually occur Risk identification One method for identifying risks is to create a risk item checklist. The checklist can be used for risk identification and focuses on some subset of known and predictable risks in the following generic subcategories: • Product size—risks associated with the overall size of the software to be built or modified. • Business impact—risks associated with constraints imposed by management or the marketplace. • Customer characteristics—risks associated with the sophistication of the customer and the developer's ability to communicate with the customer in a timely manner. • Process definition—risks associated with the degree to which the software process has been defined and is followed by the development organization. • Development environment—risks associated with the availability and quality of the tools to be used to build the product. • Technology to be built—risks associated with the complexity of the system to be built and the "newness" of the technology that is packaged by the system. • Staff size and experience—risks associated with the overall technical and project experience of the software engineers who will do the work. RISK PROJECTION Risk projection, also called risk estimation, attempts to rate each risk in two ways—the likelihood or probability that the risk is real and the consequences of the problems associated with the risk, should it occur. The project planner, along with other managers and technical staff, performs four risk projection activities: (1) establish a scale that reflects the perceived likelihood of a risk, (2) delineate the consequences of the risk, (3) Estimate the impact of the risk on the project and the product, and (4) note the overall accuracy of the risk projection so that there will be no misunderstandings.

Risk Planning and Monitoring All of the risk analysis activities presented to this point have a single goal—to assist the project team in developing a strategy for dealing with risk. An effective strategy must consider three issues: • risk avoidance • risk monitoring • risk management and contingency planning If a software team adopts a proactive approach to risk, avoidance is always the best strategy. This is achieved by developing a plan for risk mitigation. For example, assume that high staff turnover is noted as a project risk, r1. Based on past history and management intuition, the ________________________________________________________________________________________________________ Copyright © 2011 by Indira Institute of management (MCA), Pune. {IIMP (MCA)} This online tutorial is compiled with the help of Referred References by Faculty of IIMP (MCA) with the help of ISSUU. For any Query of Copyright Contact: itlibrary@indiraiimp.edu.in

likelihood, l1, of high turnover is estimated to be 0.70 (70 percent,rather high) and the impact, x1, is projected at level 2. That is, high turnover will have a critical impact on project cost and schedule. To mitigate this risk, project management must develop a strategy for reducing turnover. Among the possible steps to be taken are • Meet with current staff to determine causes for turnover (e.g., poor working conditions, low pay, competitive job market). • Mitigate those causes that are under our control before the project starts. • Once the project commences, assume turnover will occur and develop techniques to ensure continuity when people leave. • Organize project teams so that information about each development activity is widely dispersed. • Define documentation standards and establish mechanisms to be sure that documents are developed in a timely manner. • Conduct peer reviews of all work (so that more than one person is "up to speed‖). • Assign a backup staff member for every critical technologist. As the project proceeds, risk monitoring activities commence. The project manager monitors factors that may provide an indication of whether the risk is becoming more or less likely. In the case of high staff turnover, the following factors can be monitored: • General attitude of team members based on project pressures. • The degree to which the team has jelled. • Interpersonal relationships among team members. • Potential problems with compensation and benefits. • The availability of jobs within the company and outside it. In addition to monitoring these factors, the project manager should monitor the effectiveness of risk mitigation steps. For example, a risk mitigation step noted here called for the definition of documentation standards and mechanisms to be sure that documents are developed in a timely manner. This is one mechanism for ensuring continuity,should a critical individual leave the project. The project manager should monitor documents carefully to ensure that each can stand on its own and that each imparts information that would be necessary if a newcomer were forced to join the software team somewhere in the middle of the project.Risk management and contingency planning assumes that mitigation efforts have failed and that the risk has become a reality. Continuing the example, the project is well underway and a number of people announce that they will be leaving. If the mitigation strategy has been followed, backup is available, information is documented, and knowledge has been dispersed across the team. In addition, the project manager may temporarily refocus resources (and readjust the project schedule) to those functions that are fully staffed, enabling newcomers who must be added to the team to ―get up to speed.‖ Those individuals who are leaving are asked to stop all work and spend their last weeks in ―knowledge transfer mode.‖ This might include video-based knowledge capture, the development of ―commentary documents,‖ and/or meeting with other team members who will remain on the project.It is important to note that RMMM steps incur additional project cost. For example,spending the time to "backup" every critical technologist costs money. Part of risk management, therefore, is to evaluate when the benefits accrued by the RMMM steps are outweighed by the costs associated with implementing them. In essence,the project planner performs a classic cost/benefit analysis. If risk aversion steps for high turnover will increase both ________________________________________________________________________________________________________ Copyright © 2011 by Indira Institute of management (MCA), Pune. {IIMP (MCA)} This online tutorial is compiled with the help of Referred References by Faculty of IIMP (MCA) with the help of ISSUU. For any Query of Copyright Contact: itlibrary@indiraiimp.edu.in

project cost and duration by an estimated 15 percent, but the predominant cost factor is "backup," management may decide not to implement this step. On the other hand, if the risk aversion steps are projected to increase costs by 5 percent and duration by only 3 percent management will likely put all into place. For a large project, 30 or 40 risks may identified. If between three and seven risk management steps are identified for each, risk management may become a project in itself! For this reason, we adapt the Pareto 80â&#x20AC;&#x201C;20 rule to software risk. Experience indicates that 80 percent of the overall project risk (i.e., 80 percent of the potential for project failure) can be accounted for by only 20 percent of the identified risks. The work performed during earlier risk analysis steps will help the planner to determine which of the risks reside in that 20 percent (e.g., risks that lead to the highest risk exposure). For this reason, some of the risks identified, assessed, and projected may not make it into the RMMM planâ&#x20AC;&#x201D;they don't fall into the critical 20 percent (the risks with highest project priority). Developing a Risk Table A risk table provides a project manager with a simple technique for risk projection. A sample risk table is illustrated in Figure

A project team begins by listing all risks (no matter how remote) in the first column of the table. This can be accomplished with the help of the risk item checklists referenced in Section 6.3. Each risk is categorized in the second column (e.g., PS implies a project size risk, BU implies a business risk). The probability of occurrence of each risk is entered in the next column of the table. The probability value for each risk can be estimated by ________________________________________________________________________________________________________ Copyright ÂŠ 2011 by Indira Institute of management (MCA), Pune. {IIMP (MCA)} This online tutorial is compiled with the help of Referred References by Faculty of IIMP (MCA) with the help of ISSUU. For any Query of Copyright Contact: itlibrary@indiraiimp.edu.in

team members individually. Individual team members are polled in round-robin fashion until their assessment of risk probability begins to converge. Next, the impact of each risk is assessed. Each risk component is assessed using the characterization presented in Figure 6.1, and an impact category is determined.The categories for each of the four risk componentsâ&#x20AC;&#x201D; performance, support, cost, and scheduleâ&#x20AC;&#x201D;are averaged to determine an overall impact value. Once the first four columns of the risk table have been completed, the table is sorted by probability and by impact. High-probability, high-impact risks percolate to the top of the table, and low-probability risks drop to the bottom. This accomplishes first-order risk prioritization. The project manager studies the resultant sorted table and defines a cutoff line. The cutoff line (drawn horizontally at some point in the table) implies that only risks that lie above the line will be given further attention. Risks that fall below the line are re-evaluated to accomplish secondorder prioritization. Referring to Figure , risk impact and probability have a distinct influence on management concern. A risk factor that has a high impact but a very low probability of occurrence should not absorb a significant amount of management time. However, high-impact risks with moderate to high probability and low-impact risks with high probability should be carried forward into the risk analysis steps that follow.All risks that lie above the cutoff line must be managed. The column labeled RMMM contains a pointer into a Risk Mitigation, Monitoring and Management Plan or alternatively, a collection of risk information sheets developed for all risks that lie above the cutoff. Risk probability can be determined by making individual estimates and then developing a single consensus value. Although that approach is workable, more sophisticated techniques for determining risk probability have been developed . Risk drivers can be assessed on a qualitative probability scale that has the following values:impossible, improbable, probable, and frequent. Mathematical probability can then be associated with each qualitative value (e.g., a probability of 0.7 to 1.0 implies a highly probable risk). [5]Software Engineering Roger S Pressman

Reference [1].http://www.softwareresearch.net/fileadmin/src/docs/teaching/SS05/PM/PMBOK1.pdf [2]http://www.mymanagementguide.com/project-management-framework-definition-andelements/ [3]http://www.mpmm.com/project-management-methodology.php [4]http://www.exforsys.com/tutorials/testing/software-project-planning.html BOOK Software Engineering by Roger S Pressman ________________________________________________________________________________________________________ Copyright ÂŠ 2011 by Indira Institute of management (MCA), Pune. {IIMP (MCA)} This online tutorial is compiled with the help of Referred References by Faculty of IIMP (MCA) with the help of ISSUU. For any Query of Copyright Contact: itlibrary@indiraiimp.edu.in

CHAPTER 2 SOFTWARE PROJECT ESTIMATION Software project management begins with a set of activities that are collectively called project planning. Before the project can begin, the manager and the software team must estimate the work to be done, the resources that will be required, and the time that will elapse from start to finish.Whenever estimates are made, we look into the future and accept some degree of uncertainty as a matter of course MEASURES, METRICS, AND INDICATORS Although the terms measure, measurement, and metrics are often used interchangeably,it is important to note the subtle differences between them. Because measure can be used either as a noun or a verb, definitions of the term can become confusing.Within the software engineering context, a measure provides a quantitative indication of the extent, amount, dimension, capacity, or size of some attribute of a productor process. Measurement is the act of determining a measure. The IEEE Standard Glossary of Software Engineering Terms [IEE93] defines metric as ―a quantitative measure of the degree to which a system, component, or process possesses a given attribute.‖ When a single data point has been collected (e.g., the number of errors uncovered in the review of a single module), a measure has been established. Measurement occurs as the result of the collection of one or more data points (e.g., a number of module reviews are investigated to collect measures of the number of errors for each).A software metric relates the individual measures in some way (e.g., the average number of errors found per review or the average number of errors found per person-hour expended on reviews. A software engineer collects measures and develops metrics so that indicators will be obtained. An indicator is a metric or combination of metrics that provide insight into the software process, a software project, or the product itself [RAG95]. 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. Project Metrics Software process metrics are used for strategic purposes. Software project measures are tactical. That is, project metrics and the indicators derived from them are used by a project manager and a software team to adapt project work flow and technical activities. Another model of software project metrics [HET93] suggests that every project should measure: • Inputs—measures of the resources (e.g., people, environment) required to do the work. • Outputs—measures of the deliverables or work products created during the software engineering process. • Results—measures that indicate the effectiveness of the deliverables. SOFTWARE MEASUREMENT Size-Oriented Metrics In order to develop metrics that can be assimilated with similar metrics from other projects, we choose lines of code as our normalization value. From the rudimentary data contained in the table, a set of simple size-oriented metrics can be developed for each project: • Errors per KLOC (thousand lines of code). ________________________________________________________________________________________________________ Copyright © 2011 by Indira Institute of management (MCA), Pune. {IIMP (MCA)} This online tutorial is compiled with the help of Referred References by Faculty of IIMP (MCA) with the help of ISSUU. For any Query of Copyright Contact: itlibrary@indiraiimp.edu.in

• Defects4 per KLOC. • $ per LOC. • Page of documentation per KLOC. In addition, other interesting metrics can be computed: • Errors per person-month. • LOC per person-month. • $ per page of documentation. Function-Oriented Metrics 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. Function-oriented metrics were first proposed by Albrecht [ALB79], who suggested a measure called the function point. 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 user inputs. Each user input that provides distinct applicationoriented 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 applicationoriented 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. To compute function points (FP), the following relationship is used: FP = count total _ [0.65 + 0.01 * (Fi)] 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? ________________________________________________________________________________________________________ Copyright © 2011 by Indira Institute of management (MCA), Pune. {IIMP (MCA)} This online tutorial is compiled with the help of Referred References by Faculty of IIMP (MCA) with the help of ISSUU. For any Query of Copyright Contact: itlibrary@indiraiimp.edu.in

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?

Different methods of estimation Project Estimation Techniques The estimation of various project parameters is a basic project planning activity.The important project parameters that are estimated include: project size, effort required to develop the software, project duration, and cost. These estimates not only help in quoting the project cost to the customer, but also prove useful in resource planning and scheduling. There are three broad categories of estimation techniques: Empirical estimation techniques Heuristic techniques Analytical estimation techniques

Empirical Estimation Techniques Empirical estimation techniques are based on making an educated guess of the project parameters. While using this technique, prior experience with the development of similar products is helpful. Although empirical estimation techniques are based on common sense different activities involved, in estimation have been formalized over the years. Two popular empirical estimation techniques are: Expert judgment and Delphi estimation techniques. Expert judgment â&#x20AC;&#x201C; Expert judgment is one of the most widely used estimation techniques. In this approach, an expert makes an educated guess of the problem size after analyzing the problem thoroughly. Usually, the expert estimates the cost of the different components (i.e. modules or subsystems) of the system and then combines them to arrive at the overall estimate.However, this technique is subject to human errors and individual bias. Also, it is possible that the expert may overlook some factors inadvertently. Further, an expert making an estimate may not have experience and knowledge of all aspects of a project. A more refined form of expert judgment is the estimation made by a group of experts. Estimation by a group of experts minimizes factors such as individual oversight, lack of familiarity with a particular aspect of a project, personal bias, and the desire to win contract through overly optimistic estimates. However, the estimate made by a group of experts may still exhibit bias on issues where the entire group of experts is biased due to reasons such as political considerations. Also, the decision made by the group may be dominated by overly assertive members. ________________________________________________________________________________________________________ Copyright ÂŠ 2011 by Indira Institute of management (MCA), Pune. {IIMP (MCA)} This online tutorial is compiled with the help of Referred References by Faculty of IIMP (MCA) with the help of ISSUU. For any Query of Copyright Contact: itlibrary@indiraiimp.edu.in

Delphi Cost EstimationDelphi cost estimation approach tries to overcome some of the shortcomings of the expert judgment approach. Delphi estimation is carried out by a team composed of a group of experts and a coordinator. In this approach, the coordinator provides each estimator with a copy of the software requirements specification (SRS) document and a form for recording his cost estimate. Estimators complete their individual estimates anonymously and submit it to the coordinator. In their estimates, the estimators mention any unusual characteristic of the product, which has influenced their estimation. The coordinator prepares and distributes the summary of the responses of all the estimators, and includes any unusual rationale noted by any of the estimators. Based on this summary, the estimators re-estimate. This process is iterated for several rounds . However, no discussion among the estimators is allowed during the entire estimation process. The idea behind this is that if any discussion is allowed among the estimators, then many estimators may easily get influenced by the rationale of an estimator who may be more experienced or senior. After the completion of several iterations of estimations, the coordinator takes the responsibility of compiling the results and preparing the final estimate. Heuristic Techniques Heuristic techniques assume that the relationships among the different project parameters can be modeled using suitable mathematical expressions. Once the basic (independent) parameters are known, the other (dependent) parameters can be easily determined by substituting the value of the basic parameters in the mathematical expression. Different heuristic estimation models can be divided into the following two classes: single variable model and multivariable model. Single variable estimation models provide a means to estimate the desired characteristics of a problem, using some previously estimated basic (independent) characteristic of the software product such as its size. A single variable estimation model takes the following form: Estimated Parameter = cl * e ^d1 In the above expression, e is a characteristic of the software, which has already been estimated(independent variable). Estimated Parameter is the dependent parameter to be estimated. The dependent parameter to be estimated could be effort; project duration, staff size, etc. cl and d1 are constants. The values of the constants cl and d1 are usually determined using the data collected from past projects (historical data). *The basic COCOMO model is an example of a single-variable cost estimation model. A multivariable cost estimation model takes the following form: Estimated Resource = cl * e1 ^d1 + c2 * e2 ^d2+………. Where el, e2, ... are the basic (independent) characteristics of the software already estimated, and cl, c2, d1, d2, ... are constants. Multivariable estimation models are expected to give more accurate estimates compared to the single variable models, since a project parameters is typically influenced by several independent parameters. The independent parameter influence the dependent parameter to different extents. This is modeled by the constants c1, c2, d1, d2,... The values of these constants are usually determined from historical data. *The intermediate COCOMO model can be considered to be example of a multivariable estimation model.

________________________________________________________________________________________________________ Copyright © 2011 by Indira Institute of management (MCA), Pune. {IIMP (MCA)} This online tutorial is compiled with the help of Referred References by Faculty of IIMP (MCA) with the help of ISSUU. For any Query of Copyright Contact: itlibrary@indiraiimp.edu.in

The Constructive Cost Model (COCOMO) This model gained rapid popularity following the publication of B.W. Boehm's excellent book Software Engineering Economics in 1981. COCOMO is a hierarchy of software cost estimation models, which include basic, intermediate and detailed sub models. Basic Model The basic model aims at estimating, in a quick and rough fashion, most of the small to medium sized software projects. Three modes of software development are considered in this model: 1. Organic, 2.Semi-detached and 3. Embedded The comparison of three COCOMO modes Mode Project Nature of Innovation Deadline of Development Size Project the project Environment Organic Small Small team of Little Not tight Familiar & In (Typically experienced house 2-50 developers and KLOC) low communication overhead are the main characteristics of organic mode projects. For example, personnel systems project for an organization, which is located on a single building with Local Area Network facilities only. Semi Medium Semi-detached Medium Medium Medium Detached (Typically mode projects 50-300 are KLOC) intermediate projects between organic mode and ________________________________________________________________________________________________________ Copyright ÂŠ 2011 by Indira Institute of management (MCA), Pune. {IIMP (MCA)} This online tutorial is compiled with the help of Referred References by Faculty of IIMP (MCA) with the help of ISSUU. For any Query of Copyright Contact: itlibrary@indiraiimp.edu.in

Embedded

Large (Typically over 300 KLOC)

embedded mode. Such projects partially show both characteristics. Semi detach mode projects made up staff have average previous experience in similar projects i.e., the team consists of both experienced and Inexperienced staff. For example, a software project for a large bank, including daily customer operations and the ATM machine activities on a Wide Area Network can be Considered as of type semidetached. In the Significant embedded mode projects, developer team has very little previous

Tight

Complex hardware/ Customer interfaces required.

experience in similar projects because most projects are one of a kind. In the embedded mode, projects has tight constrains, more than one processor and various types of peripherals exist. Uncertainties in the problem definition are other Characteristics of such projects. Embedded mode projects are those that develop a software which is strongly coupled to complex hardware software systems. For Example: ATMs, Air Traffic Control etc. Hardware driving ________________________________________________________________________________________________________ Copyright ÂŠ 2011 by Indira Institute of management (MCA), Pune. {IIMP (MCA)} This online tutorial is compiled with the help of Referred References by Faculty of IIMP (MCA) with the help of ISSUU. For any Query of Copyright Contact: itlibrary@indiraiimp.edu.in

projects are good examples of embedded Types. For example, a software project related to control the production of various automobile parts is of embedded type.

If we look to the above Table it is mentioned that for over 300 KLOC projects embedded mode is the right choice. The selection of a mode is not only dependent on size, but also on other parameters as mentioned in. We should be utmost careful about the selection of mode for the project. The software estimator will have to assess by himself/herself which mode is the most appropriate. The basic COCOMO equations take the form E = ab (KLOC)^bb D = cb(E)^db Where, E is effort applied in Person-Months, and D is the development time in months. The coefficients ab, bb, cb and db are given in Table 1. Table 1 - Basic COCOMO coefficients Project ab bb cb db Organic 2.4 1.05 2.5 0.38 Semi-detached 3.0 1.12 2.5 0.35 Embedded 3.6 1.20 2.5 0.32 When effort and development time are known, the average staff size/ number of the people required to complete the project may be calculated as: Average staff size (SS) =E/D Persons. When project size is known, the productivity level may be calculated as: Productivity (P) = KLOC/E= KLOC/PM Advantage of Basic COCOMO Model-With the basic model, the software estimator has a useful tool for estimating quickly, by two runs on a pocket calculator, the cost and development time of a software project, once the size is estimated. Disadvantage of Basic COCOMO Model-Basic COCOMO is good for quick, early, rough order of magnitude estimates of software costs, but its accuracy is necessarily limited because of its

lack of factors to account for differences in hardware constraints, personnel quality and experience, use of modern tools and techniques, and other product attributes known to have a significant influence on software costs.[5]

References [5]http://mca2.zerimtechnoz.com/dl/isad/The%20Constructive%20Cost%20Model%203.pdf BOOK Software Engineering by Roger S Pressman

CHAPTER 3 Project Management Tools and Techniques Pert and Gantt Charts The Program (or Project) Evaluation and Review Technique, commonly abbreviated PERT, is a statistical tool, used in project management, that is designed to analyze and represent the tasks involved in completing a given project. First developed by the United States Navy in the 1950s, it is commonly used in conjunction with the critical path method or CPM. A PERT chart is a project management tool used to schedule, organize, and coordinate tasks within a project. PERT stands for Program Evaluation Review Technique, a methodology developed by the U.S. Navy in the 1950s to manage the Polaris submarine missile program. A similar methodology, the Critical Path Method (CPM), which was developed for project management in the private sector at about the same time, has become synonymous with PERT, so that the technique is known by any variation on the names: PERT, CPM, or PERT/CPM.

A or rectangles) representing events, or milestones in the project linked by labelled vectors (directional lines) PERT chart presents a graphic illustration of a project as a network diagram consisting of numbered nodes (either circles representing tasks in the project. The direction of the arrows on the lines indicates the sequence of tasks. In the diagram, for example, the tasks between nodes 1, 2, 4, 8, and The tasks between nodes 1 and 2, and nodes 1 10 must be completed in sequence. These are called dependent or serial tasks.and 3 are not dependent on the completion of one to start the other and can be undertaken simultaneously. These tasks are called parallel or concurrent tasks. Tasks that must be completed in sequence but that don't require resources or completion time are considered to have event dependency. These are represented by dotted lines with arrows and are called dummy activities. For example, the dashed arrow linking nodes 6 and 9 indicates that the system files must be converted before the user test can take place, but that the resources and time required to prepare for the user test (writing the user manual and user training) are on another path. Numbers on the opposite sides of the vectors indicate the time allotted for the task. A Gantt chart is a type of bar chart that illustrates a project schedule. Gantt charts illustrate the start and finish dates of the terminal elements and summary elements of a project. Terminal elements and summary elements comprise the work breakdown structure of the project. Some Gantt charts also show the dependency (i.e., precedence network) relationships between activities (In the following example there are seven tasks, labeled A through G. Some tasks can be done concurrently (A and B) while others cannot be done until their predecessor task is complete (C cannot begin until A is complete). Additionally, each task has three time estimates: the optimistic time estimate (O), the most likely or normal time estimate (M), and the pessimistic time estimate (P). The expected time (TE) is computed using the formula (O + 4M + P) ÷ 6. Activity Predecessor A B C D E F G

— — A A B, C D E

Time estimates Expected time Opt. (O) Normal (M) Pess. (P) 2 4 6 4.00 3 5 9 5.33 4 5 7 5.17 4 6 10 6.33 4 5 7 5.17 3 4 8 4.50 3 5 8 5.17

Once this step is complete, one can draw a Gantt chart or a network diagram.

A Gantt chart created using Microsoft Project (MSP). Note (1) the critical path is in red, (2) the slack is the black lines connected to non-critical activities, (3) since Saturday and Sunday are not work days and are thus excluded from the schedule; some bars on the Gantt chart are longer if they cut through a weekend.

An Introduction to Microsoft Project

Microsoft Project is the world's most popular project management software developed and sold by Microsoft. The application is designed to assist project managers in developing plans, assigning resources to tasks, tracking progress, managing budgets and analysing workloads. Microsoft Project creates critical path schedules, although a critical chain third-party add-ons is available from ProChain and Spherical Angle. Schedules can be resource levelled. The chain is visualised in a Gantt chart. Resource definitions (people, equipment and materials) can be shared between projects using a shared resource pool. Each resource can have its own calendar which defines what days and shifts a resource is available. Resource rates are used to calculate resource assignment costs which are rolled up and summarised the resource level. Each resource can be assigned to multiple tasks in multiple plans and each task can be assigned multiple resources. Microsoft Project schedules task work based on the resource availability as defined in the resource calendars. All resources can be defined in an enterprise resource pool. Microsoft Project creates budgets based on assignment work and resource rates. As resources are assigned to tasks and assignment work estimated, Microsoft Project calculates the cost equals the work times the rate. This rolls up to the task level, then to any summary tasks and finally to the project level.Microsoft Project has been extended with Microsoft Office Project Server and Microsoft Project Web Access. Project server stores Project data in a central database. ________________________________________________________________________________________________________ Copyright ÂŠ 2011 by Indira Institute of management (MCA), Pune. {IIMP (MCA)} This online tutorial is compiled with the help of Referred References by Faculty of IIMP (MCA) with the help of ISSUU. For any Query of Copyright Contact: itlibrary@indiraiimp.edu.in

Project Web Access allows user to display and update this data over the Internet. Web Access allows authorised users to access a Project Server database across the Internet. Web Access includes timesheets, graphical analysis of resource workloads and administrative tools. Microsoft recognises different classes of users. These different classes of users can have differing access levels to projects, views and other data. Custom objects such as calendars, views, tables, filters and fields are stored in an enterprise global database, which is shared by all users

Reference http://www.vceit.com/ganttpert/index.htm http://en.wikipedia.org/wiki/Gantt_chart http://www.projectsmart.co.uk/introduction-to-microsoft-project.html

Chapter 4 SOFTWARE QUALITY MANAGEMENT AND TESTING SOFTWARE QUALITY ASSURANCE It‘s not enough to talk the talk by saying that software quality is important, you have to (1) Explicitly define what is meant when you say ―software quality,‖ (2) Create a set of activities that will help ensure that every software engineering work product exhibits high quality, (3) Perform quality assurance activities on every software project, (4) Use metrics to develop strategies for improving your software process and, as a consequence, the quality of the end product. Quality The American Heritage Dictionary defines quality as ―a characteristic or attribute of something.‖ As an attribute of an item, quality refers to measurable characteristics—things we are able to compare to known standards such as length, color, electrical properties, and malleability. However, software, largely an intellectual entity, is more challenging to characterize than physical objects. When we examine an item based on its measurable characteristics, two kinds of quality may be encountered: quality of design and quality of conformance. Quality of design refers to the characteristics that designers specify for an item. The grade of materials, tolerances, and performance specifications all contribute to the quality of design. As higher-grade materials are used, tighter tolerances and greater levels of performance are specified, the design quality of a product increases, if the product is manufactured according to specifications. Quality of conformance is the degree to which the design specifications are followed during manufacturing. Again, the greater the degree of conformance, the higher is the level of quality of conformance. In software development, quality of design encompasses requirements, specifications, and the design of the system. Quality of conformance is an issue focused primarily on implementation. If the implementation follows the design and the resulting system meets its requirements and performance goals, conformance quality is high.But are quality of design and quality of conformance the only issues that software engineers must consider? Robert Glass argues that a more ―intuitive‖ relationship is in order:User satisfaction = compliant product + good quality +delivery within budget and schedule ________________________________________________________________________________________________________ Copyright © 2011 by Indira Institute of management (MCA), Pune. {IIMP (MCA)} This online tutorial is compiled with the help of Referred References by Faculty of IIMP (MCA) with the help of ISSUU. For any Query of Copyright Contact: itlibrary@indiraiimp.edu.in

At the bottom line, Glass contends that quality is important, but if the user isn‘t satisfied, nothing else really matters. reinforces this view when he states: ―A product‘s quality is a function of how much it changes the world for the better.‖ This view of quality contends that if a software product provides substantial benefit to its end-users, they may be willing to tolerate occasional reliability or performance problems. Quality Control Variation control may be equated to quality control. But how do we achieve quality control? Quality control involves the series of inspections, reviews, and tests used throughout the software process to ensure each work product meets the requirements placed upon it. Quality control includes a feedback loop to the process that created the work product. The combination of measurement and feedback allows us to tune the process when the work products created fail to meet their specifications. This approach views quality control as part of the manufacturing process. Quality control activities may be fully automated, entirely manual, or a combination of automated tools and human interaction. A key concept of quality control is that all work products have defined, measurable specifications to which we may compare the output of each process. The feedback loop is essential to minimize the defects produced. Quality Assurance Quality assurance consists of the auditing and reporting functions of management.The goal of quality assurance is to provide management with the data necessary to be informed about product quality, thereby gaining insight and confidence that product quality is meeting its goals. Of course, if the data provided through quality assurance identify problems, it is management‘s responsibility to address the problems and apply the necessary resources to resolve quality issues. Cost of Quality The cost of quality includes all costs incurred in the pursuit of quality or in performing qualityrelated activities. Cost of quality studies are conducted to provide a baseline for the current cost of quality, identify opportunities for reducing the cost of quality,and provide a normalized basis of comparison. The basis of normalization is almost always dollars. Once we have normalized quality costs on a dollar basis, we have the necessary data to evaluate where the opportunities lie to improve our processes. Furthermore, we can evaluate the effect of changes in dollar-based terms. Quality costs may be divided into costs associated with prevention, appraisal, and failure. Prevention costs include • quality planning ________________________________________________________________________________________________________ Copyright © 2011 by Indira Institute of management (MCA), Pune. {IIMP (MCA)} This online tutorial is compiled with the help of Referred References by Faculty of IIMP (MCA) with the help of ISSUU. For any Query of Copyright Contact: itlibrary@indiraiimp.edu.in

• formal technical reviews • test equipment • training Appraisal costs include activities to gain insight into product condition the ―first time through‖ each process. Examples of appraisal costs include • in-process and interprocess inspection • equipment calibration and maintenance • testing Failure costs are those that would disappear if no defects appeared before shipping a product to customers. Failure costs may be subdivided into internal failure costs and external failure costs. Internal failure costs are incurred when we detect a defect in our product prior to shipment. Internal failure costs include • rework • repair • failure mode analysis External failure costs are associated with defects found after the product has been shipped to the customer. Examples of external failure costs are • complaint resolution • product return and replacement • help line support • warranty work As expected, the relative costs to find and repair a defect increase dramatically as we go from prevention to detection to internal failure to external failure costs. based on data collected by Boehm and others, illustrates this phenomenon.Anecdotal data reported by Kaplan, Clark, and Tang reinforces earlier cost statistics and is based on work at IBM‘s Rochester development facility:

SOFTWARE REVIEWS Software reviews are a "filter" for the software engineering process. That is, reviews are applied at various points during software development and serve to uncover errors and defects that can then be removed. Software reviews "purify" the software engineering activities that we have called analysis, design, and coding. Freedman and Weinberg discuss the need for reviews this way: Technical work needs reviewing for the same reason that pencils need erasers: To err is human. The second reason we need technical reviews is that although people are good at catching some of their own errors, large classes of errors escape the originator more easily than they escape anyone else. Defect Amplification and Removal A defect amplification model can be used to illustrate the generation and detection of errors during the preliminary design, detail design, and coding steps of the software engineering process. The model is illustrated chematically in Figure . A box represents a software development step. During the step, errors may be inadvertently generated. Review may fail to uncover newly generated errors and errors from previous steps, resulting in some number of errors that are passed through. In some cases, errors passed through from previous steps are amplified (amplification factor, x) by current work. The box subdivisions represent each of these characteristics and the percent of efficiency for detecting errors, a function of the thoroughness of the review. Figure illustrates a hypothetical example of defect amplification for a software development process in which no reviews are conducted. Referring to the figure, each test step is assumed to uncover and correct 50 percent of all incoming errors without introducing any new errors (an optimistic assumption). Ten preliminary design defects are amplified to 94 errors before testing commences. Twelve latent errors are released to the field. Figure considers the same conditions except that design and code reviews are conducted as part of each development step. In this case, ten initial preliminary design errors are amplified to 24 errors before testing commences.Only three latent errors exist. Recalling the relative costs associated with the discovery and correction of errors, overall cost (with and without review for our hypothetical example) can be established. The number of errors uncovered during each of the steps noted in Figures is multiplied by the cost to remove an error (1.5 cost units for design, 6.5 cost units before test, 15 cost units during test, and 67 cost units after release). Using these data, the total cost for development and maintenance when reviews are conducted is 783 cost units. When no reviews are conducted, total cost is 2177 units窶馬early three times more costly. To conduct reviews, a software engineer must expend time and effort and the development organization must spend money. However, the ________________________________________________________________________________________________________ Copyright ﾂｩ 2011 by Indira Institute of management (MCA), Pune. {IIMP (MCA)} This online tutorial is compiled with the help of Referred References by Faculty of IIMP (MCA) with the help of ISSUU. For any Query of Copyright Contact: itlibrary@indiraiimp.edu.in

results of the preceding example leave little doubt that we can pay now or pay much more later. Formal tech-

nical reviews (for design and other technical activities) provide a demonstrable cost benefit. They should be conducted. FORMAL TECHNICAL REVIEWS A formal technical review is a software quality assurance activity performed by softwareengineers (and others). The objectives of the FTR are (1) to uncover errors in function, logic, or implementation for any representation of the software. (2) to verify that the software under review meets its requirements; (3) to ensure that the software has been represented according to predefined standards; (4) to achieve software that is developed in a uniform manner; and (5) to make projects more manageable. In addition,the FTR serves as a training ground, enabling junior engineers to observe different approaches to software analysis, design, and implementation. The FTR also serves to promote backup and continuity because a number of people become familiar with parts of the software that they may not have otherwise seen.The FTR is actually a class of reviews that includes walkthroughs, inspections,round-robin reviews and other small group technical assessments of software. Each FTR is conducted as a meeting and will be successful only if it is properly planned,controlled, and attended. In the sections that follow, guidelines similar to those for a walkthrough are presented as a representative formal technical review. The Review Meeting Regardless of the FTR format that is chosen, every review meeting should abide by the following constraints: • Between three and five people (typically) should be involved in the review. • Advance preparation should occur but should require no more than two hours of work for each person. • The duration of the review meeting should be less than two hours. Given these constraints, it should be obvious that an FTR focuses on a specific (and small) part of the overall software. For example, rather than attempting to review an entire design, walkthroughs are conducted for each component or small group of components. By narrowing focus, the FTR has a higher likelihood of uncovering errors. The focus of the FTR is on a work ________________________________________________________________________________________________________ Copyright © 2011 by Indira Institute of management (MCA), Pune. {IIMP (MCA)} This online tutorial is compiled with the help of Referred References by Faculty of IIMP (MCA) with the help of ISSUU. For any Query of Copyright Contact: itlibrary@indiraiimp.edu.in

product (e.g., a portion of a requirements specification, a detailed component design, a source code listing for a component). The individual who has developed the work productâ&#x20AC;&#x201D;the producerâ&#x20AC;&#x201D;informs the project leader that the work product is complete and that a review is required. The project leader contacts a review leader, who evaluates the product for readiness, generates copies of product materials, and distributes them to two or three reviewers for advance preparation. Each reviewer is expected to spend between one and two hours reviewing the product, making notes, and otherwise becoming familiar with the work. Concurrently, the review leader also reviews the product and establishes an agenda for the review meeting, which is typically scheduled for the next day.The review meeting is attended by the review leader, all reviewers, and the producer.One of the reviewers takes on the role of the recorder; that is, the individual who records (in writing) all important issues raised during the review. The FTR begins with an introduction of the agenda and a brief introduction by the producer. The producer then proceeds to "walk through" the work product, explaining the material,while reviewers raise issues based on their advance preparation. When valid problems or errors are discovered, the recorder notes each.

Review Reporting and Record Keeping During the FTR, a reviewer (the recorder) actively records all issues that have been raised. These are summarized at the end of the review meeting and a review issues list is produced. In addition, a formal technical review summary report is completed.A review summary report answers three questions: 1. What was reviewed? 2. Who reviewed it? 3. What were the findings and conclusions? The review summary report is a single page form (with possible attachments). It becomes part of the project historical record and may be distributed to the project leader and other interested parties.The review issues list serves two purposes: (1) to identify problem areas within the product and (2) to serve as an action item checklist that guides the producer as corrections are made. An issues list is normally attached to the summary report. ________________________________________________________________________________________________________ Copyright ÂŠ 2011 by Indira Institute of management (MCA), Pune. {IIMP (MCA)} This online tutorial is compiled with the help of Referred References by Faculty of IIMP (MCA) with the help of ISSUU. For any Query of Copyright Contact: itlibrary@indiraiimp.edu.in

It is important to establish a follow-up procedure to ensure that items on the issues list have been properly corrected. Unless this is done, it is possible that issues raised can ―fall between the cracks.‖ One approach is to assign the responsibility for followup to the review leader. Review Guidelines

1. Review the product, not the producer 2. Set an agenda and maintain it. 3. Limit debate and rebuttal. 4. Enunciate problem areas, but don't attempt to solve every problem noted. 5. Take written notes. 6. Limit the number of participants and insist upon advance preparation. 7. Develop a checklist for each product that is likely to be reviewed. 8. Allocate resources and schedule time for FTRs. 9. Conduct meaningful training for all reviewers. 10. Review your early reviews.

Reference BOOK Software Engineering by Roger S Pressman

CHAPTER 5 CONFIGURATION MANAGEMENT The art of coordinating software development to minimize . . . confusion is called configuration management. Configuration management is the art of identifying, organizing,and controlling modifications to the software being built by a programming team. The goal is to maximize productivity by minimizing mistakes. When you build computer software, change happens. And because it happens, you need to control it effectively. Software configuration management (SCM) is a set of activities designed to control change by identifying the work products that are likely to change, establishing relationships among them, defining mechanisms for managing different versions of these work products, controlling the changes imposed, and auditing and reporting on the changes.

What is the origin of these changes? The answer to this question is as varied as the changes themselves. However, there are four fundamental sources of change: • New business or market conditions dictate changes in product requirements or business rules. • New customer needs demand modification of data produced by information systems, functionality delivered by products, or services delivered by a computer-based system. •Reorganization or business growth/downsizing causes changes in project priorities or software engineering team structure. • Budgetary or scheduling constraints cause a redefinition of the system or product. Baselines A baseline is a software configuration management concept that helps us to control change without seriously impeding justifiable change. The IEEE defines a baseline as: A specification or product that has been formally reviewed and agreed upon, that thereafter serves as the basis for further development, and that can be changed only through formal change control procedures.

Software Configuration Items We have already defined a software configuration item as information that is created as part of the software engineering process. In the extreme, a SCI could be considered to be a single section of a large specification or one test case in a large suite of tests. More realistically, an SCI is a document, a entire suite of test cases, or a named program component (e.g., a C++ function or an Ada package). In addition to the SCIs that are derived from software work products, many software engineering organizations also place software tools under configuration control. That is, specific versions of editors, compilers, and other CASE tools are "frozen" as part of the software configuration. Because these tools were used to produce documentation, source code, and data, they must be available when changes to the software configuration are to be made. Although problems are rare, it is possible that a new version of a tool (e.g., a compiler) might produce different results than the original version. For this reason, tools, like the software that they help to produce, can be baselined as part of a comprehensive configuration management process. In reality, SCIs are organized to form configuration objects that may be cataloged in the project database with a single name. A configuration object has a name, attributes,and is "connected" to other objects by relationships. Referring to Figure , theconfiguration objects, Design Specification, data model, component N, source code and Test Specification are each ________________________________________________________________________________________________________ Copyright ÂŠ 2011 by Indira Institute of management (MCA), Pune. {IIMP (MCA)} This online tutorial is compiled with the help of Referred References by Faculty of IIMP (MCA) with the help of ISSUU. For any Query of Copyright Contact: itlibrary@indiraiimp.edu.in

defined separately. However, each of the objects is related to others as the shown by the arrows. A curved arrow indicates a compositional relation. That is, data model and component N are part of the object Design Specification. A double-headed straight arrow indicates an interrelationship. If a change were made to the source code object, the interrelationships enable a software engineer to determine what other objects (and SCIs) might be affected

VERSION CONTROL Version control combines procedures and tools to manage different versions of configuration objects that are created during the software process. describes version control in the context of SCM:Configuration management allows a user to specify alternative configurations of the software system through the selection of appropriate versions. This is supported by associating attributes with each software version, and then allowing a configuration to be specified [and constructed] by describing the set of desired attributes.

These "attributes" mentioned can be as simple as a specific version number that is attached to each object or as complex as a string of Boolean variables (switches) that indicate specific types of functional changes that have been applied to the system . One representation of the different versions of a system is the evolution graph presented in Figure Each node on the graph is an aggregate object, that is, a complete version of the software. Each version of the software is a collection of SCIs (source code, documents, data), and each version may be composed of different variants. To illustrate this concept, consider a version of a simple program that is comobj posed of entities 1, 2, 3, 4, and 5.3 Entity 4 is used only when the software is implemented using color displays. Entity 5 is implemented when monochrome displays are available. Therefore, two variants of the version can be defined: (1) entities 1, 2, 3, and 4; (2) entities 1, 2, 3, and 5. To construct the appropriate variant of a given version of a program, each entity can be assigned an "attribute-tuple"â&#x20AC;&#x201D;a list of features that will define whether the entity should be used when a particular variant of a software version is to be constructed.One or more attributes is assigned for each variant. For example, a color attribute could be used to define which entity should be included when color displays are to be supported. Another way to conceptualize the relationship between entities, variants and versions (revisions) is to represent them as an object pool , the relationship between configuration objects and entities, variants and versions can be represented in a three-dimensional space. An entity is composed of a collection of objects at the same revision level. A variant is a different collection of objects at the same revision level and therefore coexists in parallel with other variants. A new version is defined when major changes are made to one or more objects.A number of different automated approaches to version control have been proposed over the past decade. The primary difference in approaches is the sophistication of the attributes that are used to construct specific versions and variants of a system and the mechanics of the process for construction.

Reference BOOK Software Engineering by Roger S Pressman

CHAPTER 6 SOFTWARE TEAM MANAGEMENT Characteristics of performance management Performance management is a process on performance measurement approaches, such as the balanced scorecard. While the balanced scorecard offers a framework for the collection of strategic information, performance management ensures that results are used to influence the selection of planned actions and to foster the renewal of dynamic, competitive strategy. Unlike most tools and techniques, performance management is a continuous, enterprise-wide process, rather than a one-time, isolated event. Six Performance Management imperatives are Compliance Management, Profitability Management, Cost Management, Performance Improvement, and Business Innovation. Performance management is a set of functions that evaluate and report the behavior of telecommunications equipment and the effectiveness of the network or network element and a set of various sub functions, such as gathering statistical information, maintaining and examining historical logs, determining system performance under natural and artificial conditions, and altering system modes of operation. Performance Management Challenges Present in Many Ways: Shareholders have demanded that you provide more accountability and transparency in your organization. You have business units in many different regions, each working towards their own goals and purpose. [6]

Team Structure Team structures Team structure addresses the issue of organization of the individual project teams. There are some possible ways in which the individual project teams can be organized. There are mainly three formal team structures: chief programmer, democratic, and the mixed team organizations although several other variations to these structures are possible. Problems of different complexities and sizes often require different team structures for chief solution. Chief Programmer Team In this team organization, a senior engineer provides the technical leadership and is designated as the chief programmer. The chief programmer partitions the task into small activities and assigns them to the team members. He also verifies and integrates the products developed by different team members. The structure of the chief programmer team is shown in fig. 12.2. The chief programmer provides an authority, and this structure is arguably more efficient than the democratic team for well-understood problems. However, the chief programmer team leads to lower team morale, since team-members work under the constant supervision of the chief programmer. This also inhibits their original thinking. The chief programmer team is subject to single point failure since too much responsibility and authority is assigned to the chief programmer.

The chief programmer team is probably the most efficient way of completing simple and small projects since the chief programmer can work out a satisfactory design and ask the programmers to code different modules of his design solution. For example, suppose an organization has successfully completed many simple MIS projects. Then, for a similar MIS project, chief programmer team structure can be adopted. The chief programmer team structure works well when the task is within the intellectual grasp of a single individual. However, even for simple and well-understood problems, an organization must be selective in adopting the chief programmer structure. The chief programmer team structure should not be used unless the importance of early project completion outweighs other factors such as team morale, personal developments, life-cycle cost etc. Democratic Team The democratic team structure, as the name implies, does not enforce any formal team hierarchy (as shown in fig. 12.3). Typically, a manager provides the administrative leadership. At different times, different members of the group provide technical leadership. The democratic organization leads to higher morale and job satisfaction. Consequently, it suffers from less man-power turnover. Also, democratic team structure is appropriate for less understood problems, since a group of engineers can invent better solutions than a single individual as in a chief programmer team. A democratic team structure is suitable for projects requiring less than five or six engineers and for research-oriented projects. For large sized projects, a pure democratic organization tends to become chaotic. The democratic team organization encourages egoless programming as programmers can share and review one anotherâ&#x20AC;&#x2DC;s work. Mixed Control Team Organization The mixed team organization, as the name implies, draws upon the ideas from both the democratic organization and the chief-programmer organization. The mixed control team organization is shown pictorially in fig. 12.4. This team organization incorporates both hierarchical reporting and democratic set up. In fig. 12.4, the democratic connections are shown as dashed lines and the reporting structure is shown using solid arrows. The mixed control team organization is suitable for large team sizes. The democratic arrangement at the senior engineers level is used to decompose the problem into small parts. Each democratic setup at the programmer level attempts solution to a single part. Thus, this team organization is eminently suited to handle large and complex programs. This team structure is extremely popular and is being used in many software development companies. Egoless programming technique Ordinarily, the human psychology makes an individual take pride in everything he creates using original thinking. Software development requires original thinking too, although of a different type. The human psychology makes one emotionally involved with his creation and hinders him from objective examination of his creations. Just like temperamental artists, programmers find it extremely difficult to locate bugs in their own programs or flaws in their own design. Therefore, the best way to find problems in a design or code is to have someone review it. Often, having to explain oneâ&#x20AC;&#x2DC;s program to someone else gives a person enough objectivity to find out what might have gone wrong. This observation is the basic idea behind code walk throughs. An application of this, is to encourage ademocratic team to think that the design, code, and other deliverables to belong to the entire group. This is called egoless programming technique. Characteristics of a good software engineer The attributes that good software engineers should posses are as follows: ________________________________________________________________________________________________________ Copyright ÂŠ 2011 by Indira Institute of management (MCA), Pune. {IIMP (MCA)} This online tutorial is compiled with the help of Referred References by Faculty of IIMP (MCA) with the help of ISSUU. For any Query of Copyright Contact: itlibrary@indiraiimp.edu.in

• Exposure to systematic techniques, i.e. familiarity with software engineering principles. • Good technical knowledge of the project areas (Domain knowledge). • Good programming abilities. • Good communication skills. These skills comprise of oral, written, and interpersonal skills. • High motivation. • Sound knowledge of fundamentals of computer science. • Intelligence. • Ability to work in a team. • Discipline, etc. [7]

Team Communication The Major Elements of Project Communications Who to Communicate to You could just say that it's important to communicate with all the project's stakeholders and leave it at that but this approach would guarantee failure. Each individual stakeholder has a different set of requirements for project information, and prefers different ways of receiving their communications. It will not be possible to define a unique set of communications and communication vehicles for each stakeholder in most projects so the best you can do is identify the different category of stakeholder and define the required information and communication methods that best suits the group. Executive Sponsor/Business Sponsor Probably the most important customer(s) of your project's communications. It's going to be worth your while to define a custom set of communications for each person in this category. Generally speaking, these are busy people who don't have a lot of time to read a lot of detail. Charts and graphs that tell the viewer a lot about the project at a glance will probably work best for them. Take the time to interview them about their preferences: what they need to know, how they want to be communicated with, and how often. Keeping them informed about project performance is critical because they sign the cheque for the project (including your salary). They also need information so they can keep their peers apprised of the project's performance. Remember, they

are your project's champions so the better armed with information they are, the better job they can do promoting your project. Tip: don't report a problem to them without suggesting a solution. For example, if you're reporting an SPI of less than 1.0 for the 2nd week in a row, you need to include a corrective action with the report. Project Team Members This is the single most populous group in your list of stakeholders. You may want to subdivide the group into sub-groups based on their roles. For example you may want to have a different set of communications for the Business Analysts and Software Developers, or for the Electricians and Plumbers on your project. This group has a different perspective on project performance than sponsors: the sponsor views the project as work being done for them. The team member views the project as work being done by them and therefore reports on project performance are a reflection on them. A good report pleases everyone - project sponsors and team members. A bad report will cause the sponsor to worry but may negatively impact team morale. Customers/Clients These can be internal to your organization, or external to it. These people may profess no particular interest in project communications until the final product or service is delivered. You need to overcome this disinterest and pique their interest in project progress. The more informed they are on the project as it progresses through its lifecycle, the more likely they are to accept the resulting products or services. Partners These are people who are doing work that is in some way affected by the work of your project. You may both be working on projects that are part of a program, or your projects may simply affect one another without further integration. For example, you may be managing a software project that requires a corresponding database project - the database project team is your partner. Or, you may be working on a software system new software system that will utilize an existing web portal for customer access - the portal team is your partner despite the fact they aren't performing a project. Community Stakeholders These are an increasingly important category of stakeholder. As more emphasis is being placed on organizations ethical behavior and social responsibility, there is an increasing demand for projects to be performed ethically. One of the ways this is done is by treating those who don't belong to the performing organization, or to the customer/client organization, as project stakeholders. Consideration of these stakeholders must go beyond communications, but project communications constitute an important part of your ethical dealings with them. Project Manager Don't forget to include yourself as a stakeholder. Your need for project information is perhaps the most important for the project. If you aren't receiving the information ________________________________________________________________________________________________________ Copyright ÂŠ 2011 by Indira Institute of management (MCA), Pune. {IIMP (MCA)} This online tutorial is compiled with the help of Referred References by Faculty of IIMP (MCA) with the help of ISSUU. For any Query of Copyright Contact: itlibrary@indiraiimp.edu.in

you need to run the project, you won't be able to share it with other stakeholders. Your needs will stem from the need to be updated on the progress of the individual tasks of the project so that you can keep the project plans up to date and identify preventive or corrective actions.[8]

Managing Customer Expectation One of the critical factors for successful project management is to make sure that customer staff balance fundamental principles and ideals with reasonable expectations for the real world. The following segment presents some tips and hints for setting and managing reasonable customer expectations. Get the Customer Involved Hold a Customer Kick-Off Meeting Get Buy-In to the Project Management Process Keep Risks Visible Share Problems[9]

Reference [6]http://www.management-hub.com/performance-management.html [7]http://nptel.iitm.ac.in/courses/Webcoursecontents/IIT%20Kharagpur/Soft%20Engg/pdf/m12L30.pdf [8]http://www.projectmagazine.com/executing/61-communication/407-project-communicationshow-to-keep-your-team-engaged-and-informed [9]http://it.toolbox.com/blogs/enterprise-solutions/managing-customer-expectations-25950

CHAPTER 7 ROLE OF USER IN PROJECTS

User role in project management end-user involvement will probably vary by the nature of the project at hand, but can encompass any of these possibilities: End-User Project Management: End-users will assume project management responsibility, and IT staff will act as a project team members. In the alternative, and if appropriate, IT can run its own sub-project focusing on the technical elements of the main project, to be later integrated into the whole. End-User Team Assignments: One or more members of the end-user community will take on assigned responsibilities as active members of the project team, reporting to the IT project manager. End-User Project Liaisons: End-user staff can assume a coordination role within the project, acting as a middleman between IT and the end-user community on project related issues. End-users should never be eliminated from projects in entirety, even if the project is purely technical (i.e. to swap server hardware over a weekend). While end-users may not have any specific input into this type of project, they have a vested interest in the outcome, and should always be considered and consulted. Essential End-User Roles & Responsibilities: Define business needs and requirements. Work with IT to specify deliverables. Work with IT to specify acceptance and success criteria. Follow established change control procedures to minimize unwarranted change requests. Establish communications channels to report issues and change requests. Participate in demonstrations and tests as needed. Provide feedback as needed after tests and pilots. Work through problems and issues without blame and finger-pointing. Communicate Effective communication will be a key factor of success in avoiding the project blame game. As you work with your end-users to define project involvement, you will need to use all your communications skills in order to

Understand and acknowledge end-user concerns. Negotiate roles and responsibilities. Market IT project skills and capabilities, focusing on prior success stories, or, if needed, on lessons learned from prior experiences Help end-users to define their needs. Communicate roles and responsibilities through documentation and in meetings.

Reference [10]http://www.ittoolkit.com/cgi-bin/itmember/itmember.cgi/reg/ITBE-no