1)Write the title and scope of your final year project. Who are your team members?

What role is played by each member? What Critical Practices do you want to adapt during Project management? Sol) Our project title is NETWORK TOPOLOGIES RELATED TO EMBEDDED SYSTEMS. Scope of our project is implementing different topologies in ES networks and reducing response delay and cost and increasing the efficiency of the project. Our team members are I K.Immanuel(Y8IT253), D.Vineela(Y8IT229), K. Naga Teja(Y8IT251), M.Devi Kavya Priya(Y8IT271). Each of us are working in different areas. One is dealing with topologies. One is dealing with embedded systems and another with networks in embedded systems. The other is dealing with already existing systems and their topologies. We are going to implement the other topologies in those places already existed items. Critical Practices do you want to adapt during Project management:PROJECT INTEGRITY 1. Adopt Continuous Program Risk Management: 1. Risk management is a continuous process beginning with the definition of the concept and ending with system retirement. 2. Risk management is a program responsibility impacting on and supported by all organizational elements. 3. All programs need to assign a risk officer as a focal point for risk management and maintain a reserve to enable and fund risk mitigation. 4. Risk need to be identified and managed across the life of the program. 5. All risks identified should be analyzed, prioritized-by impact and likelihood of occurrence-and tracked through an automated risk management tool. 6. High-priority risks need to be reported to management on a frequent and regular basis. 2. Estimate Cost and Schedule Empirically: 1. Initial software estimates and schedules should be looked on as high risk due to the lack of definitive information available at the time they are defined. 2. The estimates and schedules should be refined as more information becomes available. 3. At every major program review, costs-to-complete and rescheduling should be presented to identify deviations from the original cost and schedule baselines and to anticipate the likelihood of cost and schedule risks occurring. 4. All estimates should be validated using a cost model, a sanity check should be conducted comparing projected resource requirements, and schedule commitments should be made.

3. Use Metrics to Manage: 1. All programs should have in place a metrics program to monitor issues and determine the likelihood of risks occurring. 2. Metrics should be defined as part of definition of process, identification of risks or issues, or determination of project success factors. 5. Track Defects against Quality Targets 1. All programs need to have pre-negotiated quality targets, which is an absolute requirement to be met prior to acceptance by the customer. 2. Programs should implement practices to find defects early in the process and as close in time to creation of the defect as possible and should manage this defect rate against the quality target. 6. Treat People-as the Most Important Resource 1. A primary program focus should be staffing positions with qualified personnel and retaining this staff through the life of the project. 2. The program should not implement practices (e.g., excessive unpaid overtime) that will force voluntary staff turnover. 7. Adopt Life Cycle Configuration Management 1. All programs, irrespective of size, need to manage information through a preplanned configuration management (CM) process. 2. CM has two aspects: formal CM, which manages customer-approved baseline information, and development CM, which manages shared information not yet approved by the customer. 8. Manage and Trace Requirements 1. Before any design is initiated, requirements for that segment of the software need to be agreed to. 2. Requirements tracing should be a continuous process providing the means to trace from the user requirement to the lowest level software component. 9. Use System-Based Software Design 1. All methods used to define system architecture and software design should be documented in the system engineering management plan and software development plan and be frequently and regularly evaluated through audits conducted by an independent program organization. 2. Software engineering needs to participate in the definition of system architectures and should provide an acceptance gate before software requirements are defined.

10. Ensure Data and Database Interoperability 1. All data and database implementation decisions should considerinteroperability issues and, as interoperability factors change, these decisions should be revisited. 2. Program standards should exist for database implementation and for the data elements that are included. These standards should include process standards for defining the database and entering information into it and product standards that define the structure, elements, and other essential database factors. 11. Define and Control Interfaces 1. Before completion of system-level requirements, a complete inventory of all external interfaces needs to be completed. 2. All external interfaces need to be described as to source, format, structure, content, and method of support and this definition, or interface profile, needs to be placed under CM control. 12. Design Twice, Code Once 1. All design processes should follow methods documented in the software development plan. 2. All designs need to be subject to verification of characteristics, which are included as part of the design standards for the product produced. 13. Assess Reuse Risks and Costs 1. The use of reuse components, COTS, GOTS, or any other non-developmental items (NDI) should be treated as a risk and managed through risk management. 2. Application of reuse components, COTS, GOTS, or any other NDI will be made only after successful completion of a NDI acceptance inspection. This inspection needs to consider the process used to develop it, how it was document, number of users, user experience, and compliance with essential program considerations such as safety or security. 14. Inspect Requirements and Design 1. All products that are placed under CM and are used as a basis for subsequent development need to be subjected to successful completion of a formal inspection prior to its release to CM. 2. The inspection needs to follow a rigorous process defined in the software development plan and should be based on agreed-to entry and exit criteria for that specific product. 15. Manage Testing as a Continuous Process 1. All testing should follow a preplanned process, which is agreed to and funded. 2. Every product that is placed under CM should be tested by a corresponding testing activity.

3. All tests should consider not only a nominal system condition but also address anomalous and recovery aspects of the system. 16. Compile and Smoke Test Frequently 1. All tests should use systems that are built on a frequent and regular basis (nominally no less than twice a week). 2. All new releases should be regression tested by CM prior to release to the test organization.

2)With reference to your project, who are all the stake holders? What are their roles and responsibilities? Sol) Project stakeholders are those entities within or outside an organization which: 1. sponsor a project, or 2. have an interest or a gain upon a successful completion of a project; 3. may have a positive or negative influence in the project completion. Examples of project stakeholders include the customer, the user group, the project manager, the development team, the testers, etc. Stakeholders are anyone who has an interest in the project. Project stakeholders are individuals and organizations that are actively involved in the project, or whose interests may be affected as a result of project execution or project completion. They may also exert influence over the projects objectives and outcomes. The project management team must identify the stakeholders, determine their requirements and expectations, and, to the extent possible, manage their influence in relation to the requirements to ensure a successful project The following are examples of project stakeholders:

Project leader Project team members Upper management Project customer Resource Managers Line Managers Product user group Project testers Our project leader is Y8IT251 and we 3 members are team members who include project testers, resource managers. As we are given different work as team members are given in a project. Each of us are working in different areas. One is dealing with topologies. One is dealing with embedded systems and another with networks in embedded systems. The other is dealing with already existing systems and their topologies. We are going to implement the other topologies in those places already existed items. As team head is also a member he too works likely to us. He just schedules and manages things along the work. 3) What are the different types of risks that you have identified with respect to your project? Describe your plans to mitigate, monitor and manage the risks? Sol) what is Risk? Risk are future uncertain events with a probability of occurrence and a potential for loss Risk identification and management are the main concerns in every software project. Effective analysis of software risks will help to effective planning and assignments of work. Risks are identified, classified and managed before actual execution of program. These risks are classified in different categories. Categories of risks: Schedule Risk: Project schedule get slip when project tasks and schedule release risks are not addressed properly. Schedule risks mainly affect on project and finally on company economy and may lead to project failure. Schedules often slip due to following reasons: Wrong time estimation Resources are not tracked properly. All resources like staff, systems, skills of individuals etc. Failure to identify complex functionalities and time required to develop those functionalities.

Unexpected project scope expansions. Budget Risk: Wrong budget estimation. Cost overruns Project scope expansion Operational Risks: Risks of loss due to improper process implementation, failed system or some external events risks. Causes of Operational risks: Failure to address priority conflicts Failure to resolve the responsibilities Insufficient resources No proper subject training No resource planning No communication in team. Technical risks: Technical risks generally leads to failure of functionality and performance. Causes of technical risks are: Continuous changing requirements No advanced technology available or the existing technology is in initial stages. Product is complex to implement. Difficult project modules integration. Programmatic Risks: These are the external risks beyond the operational limits. These are all uncertain risks are outside the control of the program. These external events can be: Running out of fund. Market development Changing customer product strategy and priority Government rule changes.

A Risk Management Plan is a document prepared by a project manager to foresee risks, to estimate the effectiveness, and to create response plans to mitigate them. It also consists of the risk assessment matrix. A risk is defined as "an uncertain event or condition that, if it occurs, has a positive or negative effect on a project's objectives."[1] Risk is inherent with any project, and project managersshould assess risks continually and develop plans to address them. The risk management plan contains an analysis of likely risks with both high and low impact, as well as mitigation strategies to help the project avoid being derailed should common problems arise. Risk management plans should

be periodically reviewed by the project team in order to avoid having the analysis become stale and not reflective of actual potential project risks. Most critically, risk management plans include a risk strategy. Broadly, there are four potential strategies, with numerous variations. Projects may choose to:

Accept risk; simply take the chance that the negative impact will be incurred Avoid risk; changing plans in order to prevent the problem from arising Mitigate risk; lessening its impact through intermediate steps Transfer risk; outsource risk to a capable third party that can manage the outcome

Risk management is the identification, assessment, and prioritization of risks (defined in ISO 31000 as the effect of uncertainty on objectives, whether positive or negative) followed by coordinated and economical application of resources to minimize, monitor, and control the probability and/or impact of unfortunate events or to maximize the realization of opportunities. Risks can come from uncertainty in financial markets, project failures (at any phase in development, production, or sustainment life-cycles), legal liabilities, credit risk, accidents, natural causes and disasters as well as deliberate attack from an adversary or events of uncertain root-cause. Several risk management standards have been developed including the Project Management Institute, the National Institute of Science and Technology, actuarial societies, and ISO standards. The strategies to manage risk include transferring the risk to another party, avoiding the risk, reducing the negative effect or probability of the risk, or even accepting some or all of the consequences of a particular risk. 4) Explain two different methods to estimate the effort involved while developing your final year project? Sol) Software development efforts estimation is the process of predicting the most realistic use of effort required to develop or maintain software based on incomplete, uncertain and/or noisy input. Effort estimates may be used as input to project plans, iteration plans, budgets, investment analyses, pricing processes and bidding rounds. Typically, effort estimates are over-optimistic and there is a strong over-confidence in their accuracy. The mean effort overrun seems to be about 30% and not decreasing over time. For a review of effort estimation error surveys. However, the measurement of estimation error is not unproblematic, see Assessing and interpreting the accuracy of effort estimates. The strong overconfidence in the accuracy of the effort estimates is illustrated by the finding that, on average, if a software professional is 90% confident or almost sure to include the actual effort in a

minimum-maximum interval, the observed frequency of including the actual effort is only 6070%. Estimation approaches: There are many ways of categorizing estimation approaches.

Expert estimation: The quantification step, i.e., the step where the estimate is produced based on judgmental processes. Formal estimation model: The quantification step is based on mechanical processes, e.g., the use of a formula derived from historical data. Combination-based estimation: The quantification step is based on a judgmental or mechanical combination of estimates from different sources.

The evidence on differences in estimation accuracy of different estimation approaches and models suggest that there is no best approach and that the relative accuracy of one approach or model in comparison to another depends strongly on the context. This implies that different organizations benefit from different estimation approaches. Findings, summarized in, that may support the selection of estimation approach based on the expected accuracy of an approach include:

Expert estimation is on average at least as accurate as model-based effort estimation. In particular, situations with unstable relationships and information of high importance not included in the model may suggest use of expert estimation. This assumes, of course, that experts with relevant experience are available. Formal estimation models not tailored to a particular organizations own context, may be very inaccurate. Use of own historical data is consequently crucial if one cannot be sure that the estimation models core relationships (e.g., formula parameters) are based on similar project contexts.

Formal estimation models may be particularly useful in situations where the model is tailored to the organizations context (either through use of own historical data or that the model is derived from similar projects and contexts), and/or it is likely that the experts estimates will be subject to a strong degree of wishful thinking.

The most robust finding, in many forecasting domains, is that combination of estimates from independent sources, preferable applying different approaches, will on average improve the estimation accuracy. In addition, other factors such as ease of understanding and communicating the results of an approach, ease of use of an approach, cost of introduction of an approach should be considered in a selection process. So, two different methods I use in my final project are analogy based estimation and parametric models. Analogy based estimation:Analogy Based Software Estimation is based on the principle that actual values achieved within the organization in an earlier and similar project are better indicators and predict the future project performance much better than an estimate developed afresh from scratch. It also facilitates bringing the organizational experience to bear on the new projects. However, to use this technique, it is necessary for the organization to put in place certain prerequisites, such as 1. The organization ought to have executed a number of projects 2. The organization should be keeping meticulous records of past projects 3. The organization must be conducting project post mortem for every project and causes for variances must be identified using meticulous methods and the actual values validated depending on the causes. Care must be taken to prevent erroneous data to influence future projects. 4. The organization should have a well organized and maintained Knowledge Repository from which it is feasible to locate similar past projects and extract the validated project data 5. The estimators should be trained in drawing analogies accurately and in accessing the Knowledge Repository and extracting validated data and extrapolate the same for the current project Once these pre-requisites are in place, this technique can very profitably be used in the organization. Parametric model: A parametric model is a set of related mathematical equations which incorporates variable parameters. A scenario is defined by selecting a value for each parameter. Software project managers use software parametric models and parametric estimation tools to estimate their projects' duration, staffing and cost.

In the early 1980s refinements to earlier models, such as PRICE S and SLIM, and new models, such as SPQR, Checkpoint, ESTIMACS, SEER-SEM or COCOMO and its commercial implementations PCOC, GECOMO, COSTAR and Before You Leap emerged. The prime advantage of these models is that they are objective, repeatable, calibrated and easy to use, although calibration to previous experience may be a disadvantage when applied to a significantly different project. These models were highly effective for waterfall model, version 1 software projects of the 1980s and highlighted the early achievements of parametrics. As systems became more complex and new languages emerged, different software parametric models emerged which employed new cost estimating relationships, risk analyzers, software sizing, nonlinear software reuse and personnel continuity. 5) Write the schedule (Timeline Charts) of your final year project while keeping an eye on effort allocation. What factors may contribute to late delivery of your project? How? What factors may contribute to poor quality of your software? Sol) schedule (Timeline Charts) of your final year project:Before a project schedule can be created, a project manager should typically have a work breakdown structure (WBS), an effort estimate for each task, and a resource list with availability for each resource. If these are not yet available, it may be possible to create something that looks like a schedule, but it will essentially be a work of fiction. They can be created using a consensus-driven estimation method like Wideband Delphi. The reason for this is that a schedule itself is an estimate: each date in the schedule is estimated, and if those dates do not have the buy-in of the people who are going to do the work, the schedule will be inaccurate. In many industries, such as engineering and construction, the development and maintenance of the project schedule is the responsibility of a full time scheduler or team of schedulers, depending on the size of the project. And though the techniques of scheduling are well developed, they are inconsistently applied throughout industry. Standardization and promotion of scheduling best practices are being pursued by the Association for the Advancement of Cost Engineering (AACE), the Project Management Institute (PMI). In some large corporations, scheduling, as well as cost, estimating, and risk management are organized under the department of project controls. Many project scheduling software products exist which can do much of the tedious work of calculating the schedule automatically, and plenty of books and tutorials dedicated to teaching people how to use them. However, before a project manager can use these tools, he or she should understand the concepts behind the WBS, dependencies, resource allocation, critical paths, Gantt charts and earned value. These are the real keys to planning a successful project. In order for a project schedule to be healthy, the following criteria must be met [1]:

The schedule must be constantly (weekly works best) updated.

The EAC value must be equal to the baseline value. The remaining effort must be appropriately distributed among team members (taking vacations into consideration).

Factors may contribute to late delivery of project:1. Lack of clear links between the project and the organizations key strategic priorities, including agreed measures of success. 2. Lack of clear senior management and Ministerial ownership and leadership. 3. Lack of effective engagement with stakeholders. 4. Lack of skills and proven approach to project management and risk management. 5. Too little attention to breaking development and implementation into manageable steps. 6. Evaluation of proposals driven by initial price rather than long-term value for money (especially securing delivery of business benefits). 7. Lack of understanding of, and contact with the supply industry at senior levels in the organization. 8. Lack of effective project team integration between clients, the supplier team and the supply chain. Factors may contribute to poor quality of software:Poor quality is not an inevitable attribute of software. It results from known causes. It can be predicted and controlled, but only if its causes are understood and addressed. With more critical business processes being implemented in software, quality problems are a primary business risk. Ill discuss five primary causes of poor software quality and how to mitigate their damaging effects using methods other than brute testing. 1. Lack of domain knowledge: Perhaps the greatest contributor to poor software quality is the unfortunate fact that most developers are not experts in the business domain served by their applications, be it telecommunications, banking, energy, supply chain, retail, or others. The best way to mitigate this cause is to provide access to domain experts from the business, proactively train developers in the business domain, and conduct peer reviews with those possessing more domain experience. 2. Lack of technology knowledge: Most developers are proficient in several computer languages and technologies. However, modern multi-tier business applications are a complex tangle of many computer languages and different software platforms. These tiers include user interface, business logic, and data management, and they may interact through middleware with enterprise resource systems and legacy applications written in archaic languages. The best way to mitigate this cause is to crosstrain developers in different application technologies, conduct peer reviews with developers working in other application tiers, and perform static and dynamic analyses of the code.

3. Unrealistic schedules: When developers are forced to sacrifice sound software development practices to ridiculous schedules the results are rarely good.The few successful outcomes are based on heroics that are rarely repeated on future death marches. When working at breakneck pace, stressed developers make more mistakes and have less time to find them. The only way to mitigate these death march travesties is through enforcing strong project management practices. Controlling commitments through planning, tracking progress to identify problems, and controlling endless requirements changes are critical practices for providing a professional environment for software development. 4. Badly engineered software: Two-thirds or more of most software development activity involves changing or enhancing existing code. Studies have shown that half of the time spent modifying existing software is expended trying to figure out what is going on in the code. Unnecessarily complex code is often impenetrable and modifying it leads to numerous mistakes and unanticipated negative side effects. These newly injected defects cause expensive rework and delayed releases. The best way to mitigate this cause is to re-factor critical portions of the code guided by information from architectural and static code analyses. 5. Poor acquisition practices: Most large multi-tier applications are built and maintained by distributed teams, some or all of whom may be outsourced from other companies. Consequently, the acquiring organization often has little visibility into or control over the quality of the software they are receiving. For various reasons, CMMI levels have not always guaranteed high quality software deliveries. To mitigate the risks of quality problems in externally supplied software, acquiring managers should implement quality targets in their contracts and a strong quality assurance gate for delivered software.