Software Engineering PDF

Software Engineering Software Engineering, A Practitioner’s Approach, Roger S, Pressman.(2014). An Integrated Approach to Software Engineering, Pankaj Jalote, Narosa,3rd edition. Software Testing - Concepts & Practices, K. Mustafa, R. A. Khan, Na...

Software Engineering Software Engineering, A Practitioner’s Approach, Roger S, Pressman.(2014). An Integrated Approach to Software Engineering, Pankaj Jalote, Narosa,3rd edition. Software Testing - Concepts & Practices, K. Mustafa, R. A. Khan, Narosa,Reprint 2009.  What is Software? Software is a set of programs performs a specific task. Software, when made for a specific requirement is called software product.  What is Engineering Engineering is all about developing products, using well-defined, scientific principles and methods.  What is Software Engineering? Software engineering is an engineering branch associated with development of software product using well-defined scientific principles, methods and procedures. The outcome of software engineering is an efficient(max productivity with min. wasted efforts) and reliable(good quality of s/w) software product.  Why Software Engineering is important? It enables us to build complex system in a timely manner. It ensures high quality of software.  What is work Product? It means result/outcome of software. 1. Software Engineer: The work product of s/w eng. is set of programs, the content along with documentation that is a part of s/w. 2. User/Customers: The functionality delivered by the s/w that improves user experience. Software Engineering Focuses on? 1. Quality: A) Functional: Degree to which correct software is produced. B)Non-functional(Structured): robustness,efficient,reliable. 2. Maintainability: After the s/w has been developed and delivered. Should be easily enhanced and adapt to change requirements whenever required.  Types of Software. 1. System Software: The software that provides a platform for other software to run. Eg. Operating system etc. 2. Application Software: They serve a particular purpose. Eg. Payroll , online shopping, Ms office etc.  3. Engineering/Scientific software: Solves complex numerical problems. Eg. Genetic Analysis, Astronomical etc. 4. Embedded S/w: Provides limlited features and functionality. Eg. Washing Machines, Micro wave ovens etc. 5. AI S/w: Induce human like intelligence in machines. Eg. Robotic, game playing s/w.  6. Legacy software: Very old and traditional software. Changed from time to time. Do not have good quality. 7. web/ Mobile application: Those s/w that run on browser or mobile. Eg candy crush etc. 8. Real world s/w: Control,monitor,analyse real world events in real time. Eg. Weather forecasting etc.  Software engineering - Layered technology Software engineering is a fully layered technology. To develop a software, we need to go from one layer to another. All these layers are related to each other and each layer demands the fulfillment of the previous layer.  Software eng. Comprises of a process, aset of methods for managing and developing the s/w and a collection of tools, The main layer of software eng. Is Quality. 1. Quality: A. Functional: Degree to which correct software is developed. B)Non-functional(Structured): Robustness, maintainability. Eg. Six sigma 2. Process: A framework that must be estabilished for effective delivery of s/w. Timely development of software. Management and control of software projects. 3. Methods: Provide technical “how to” for building a software. Each method consis of multiple tasks. Eg. Requirement analysis,testing,support etc. 4. Tools: Provides automated/semi automated support for process and methods. Eg. CAD. Software Development Life Cycle, SDLC Software Development Life Cycle, is a well-defined, structured sequence of stages in software engineering to develop the intended software product.  SDLC Activities SDLC provides a series of steps to be followed to design and develop a software product efficiently. SDLC framework includes the following steps:  Communication This is the first step where the user initiates the request for a desired software product. He contacts the service provider and tries to negotiate the terms. He submits his request to the service providing organization in writing.  Requirement Gathering This step onwards the software development team works to carry on the project. The team holds discussions with various stakeholders from problem domain and tries to bring out as much information as possible on their requirements. The requirements are contemplated and segregated into user requirements, system requirements and functional requirements. The requirements are collected using a number of practices as given – studying the existing system and software, – conducting interviews of users and developers, – referring to the database or – collecting answers from the questionnaires.  Feasibility Study After requirement gathering, the team comes up with a rough plan of software process. At this step the team analyzes if a software can be made to fulfill all requirements of the user and if there is any possibility of software being no more useful. It is found out, if the project is financially, practically, and technologically feasible for the organization to take up. There are many algorithms available, which help the developers to conclude the feasibility of a software project.  System Analysis At this step the developers decide a roadmap of their plan and try to bring up the best software model suitable for the project. System analysis includes Understanding of software product limitations, learning system related problems or changes to be done in existing systems beforehand, identifying and addressing the impact of project on organization and personnel etc. The project team analyzes the scope of the project and plans the schedule and resources accordingly.  Software Design Next step is to bring down whole knowledge of requirements and analysis on the desk and design the software product. The inputs from users and information gathered in requirement gathering phase are the inputs of this step. The output of this step comes in the form of two designs; logical design and physical design. Engineers produce data-flow diagrams and in some cases pseudo codes.  Coding This step is also known as programming phase. The implementation of software design starts in terms of writing program code in the suitable programming language and developing error-free executable programs efficiently.  Testing Software testing is done while coding by the developers and thorough testing is conducted by testing experts at various levels of code such as module testing, program testing, product testing, in-house testing and testing the product at user’s end. Early discovery of errors and their remedy is the key to reliable software.  Integration Software may need to be integrated with the libraries, databases and other program(s). This stage of SDLC is involved in the integration of software with outer world entities.  Implementation This means installing the software on user machines. At times, software needs post-installation configurations at user end. Software is tested for portability and adaptability and integration related issues are solved during implementation.  Operation and Maintenance If required, the users are trained on, or aided with the documentation on how to operate the software and how to keep the software operational. The software is maintained timely by updating the code according to the changes taking place in user end environment or technology. This phase may face challenges from hidden bugs and real-world unidentified problems.  Disposition As time elapses, the software may decline on the performance front. It may go completely obsolete or may need intense upgradation. This phase includes archiving data and required software components, closing down the system, planning disposition activity and terminating system at appropriate end-of-system time.  Software Life Cycle Models The process followed in the development of the software depends upon the Life cycle model chosen for development. Types of Life Cycle Model. (A) Prescriptive Models 1. Waterfall Model. 2. Incremental process model. – Iterative model. – Rapid application model.  3. Evolutionary Models. – Prototyping model. – Spiral Model (B) Specialized Process Models. 1. Agile Model. 2. Rational Unified process model.  Waterfall Model Requirement Gathering Design Coding and unit testing Integration & system Testing Implementation Operation and Maintenance  Waterfall Model. The waterfall model is also called as 'Linear sequential model' or 'Classic life cycle model'. It says the all the phases of SDLC will function one after another in linear manner. That is, when the first phase is finished then only the second phase will start and so on. This model does not work smoothly if there are some issues left at the previous step. The sequential nature of model does not allow us go back and undo or redo our actions.  Requirement Gathering Purpose:To understand customer requirements and document them Properly. Work product: SRS(Software requirement specification) Use: Used as a contract between developer and customer.  Design Purpose: Transforms requirements into a structure suitable for implementation in some programming language. Software architecture is specified in detail. Work Product: SDD(Software Design Document) Use: Useful for start coding.  Coding: SDD is used for coding. Testing: 1. Unit Testing: Each module is tested independently of other module. Integration & System Testing: Integration: Bring all the modules together, combine it to form a complete software & test it. System Testing:The whole software is tested by considering environment,hardware etc. Actual software is deployed at customer place and tested.  Operation and Maintenance: Purpose: After the delivery and deployment of the software to the customer, maintanance can be done like error correction, Improve software.  Problems with waterfall model. Expects complete and accurate requirements early in s/w development process. Working s/w is not available till very late in the s/w development cycle.(delay in error discovery) Change- not suitable for accomodating changing during development. Sequential Nature-not realistic in todays world and this model is not suitable for large projects  When to use waterfall model. When the requirements are very clearly understood and they will not change during SDLC. Can be used by an organization: – That has an experience in developing a particular kind of software. – When it wants to build a new software based on an existing software. Incremental Model.  Incremental Process Model. Aim: Deliver limited functionality quickly. Requirements: defined clearly. No confusion about requirements. Delivery of Functionality: is done in multiple phases depending upon the priorities of the requirements. Every Cycle: deliveres a semi-completed product with limited functionality. Last Cycle: Complete s/w.  Iterative Enhancement Model. Phase Same phases as waterfall model They are implemented with less restriction.(No need to follow sequential manner) Occurs in same order but in several cycles. Requirement Major requirements are specified by the customer at beginning and SRS is prepared. Priorities- decided for different requi. by customer and developer. Implementation of these requirement is done based on priorities.  Waterfall vs Incremental Waterfall One final product at the end of SDLC with all the functionalities. Long wait for the software. Incremental. Complete s/w is divided into releases. Limited functionality is released in every cycle. First release is available within a weeks/months.  RAD(Rapid Application Development) Model. Developed by IBM. In RAD user participation is very important. RAD model is Rapid Application Development model. It is a type of incremental model. In RAD model the components or functions are developed in parallel as if they were mini projects. The developments are time boxed, delivered and then assembled into a working prototype. Requirement User Construction Cut Over Planning Description 1. Requirement Planning: Using group elicitation techniques like brain stroming. User communication required for good understanding of requirements.. To gather and finalize the requirement by using following prototype. As long as requirements is finalized the process continues. Build Rapid Prototype User Evaluation Feedback prototype refined 2. User Description:A joint team of customers and developers understands and reviews the gathered requirements. Automated tools may also be used. 3. Construction:Design coding testing Product is released. For quick development we use automated code,screen generator. 4. Cut over:All development is over. Install the software+Acceptance testing+Training of the user.  Major Features. Rapid Prototype: Quick initial views about product. Powerful development tools: Development time goes down. User involvement: Acceptability of the product increase.  Not useful when User cannot be involved continuously. Tools & resuable components cannot be used. Highly skilled & specialized developers.  SDLC Evolutionary Model SDLC Evolutionary model builds the required product in several successive versions. It is also known as incremental model. Important points on SDLC Evolutionary model Requirement is broken down into different functional units/Modules. These modules can be incrementally built and delivered. Here at the beginning the core module of the software product is developed. New functionality is built, added to existing one and released as new version. Each successive version is capable of performing more functions in comparision to its previous versions.  Useful when It is also suitable for large products where requirements can be divided into modules. Every version will get built and delivered to customer who can then use it instead of waiting for the complete system.  Prototype Model Requirements Quick Design Feedback & Implement Refinement Not Accepted by Customer Evaluation Customer Accepted by Customer Design Implemantation & unit Testing Intergration & System Testing Operation and maintenance  Prototyping Model. Prototype is a working model of software with some limited functionality. The prototype does not always hold the exact logic used in the actual software application and is an extra effort to be considered under effort estimation. Prototyping is used to allow the users evaluate developer proposals and try them out before implementation. It also helps understand the requirements which are user specific and may not have been considered by the developer during product design. Continuous customer support in requirement phase.  Drawbacks Limited Functionality. Not very good quality. Not good performance. Advantages: Refine requirements. Prepare final SRS documents.  Is prototype our final product? Benefits of developing a prototype? Does prototype development incur extra cost? Spiral Model  Developed by Barry Boehm. Main feature: Handling uncertainity/Risk. Phase: Mulitiple phases having 4 Activities. 1. Planning: Determine objectivies,alternatives. Imposes constraints. 2. Risk: Identify & resolve risk, classify into levels Tries to find alternatives and plan ahead. 3. Development and testing 4. Assessment: Customer Evaluation.  Phase1: Planning Analyse Risk Prototypebuilt Customer Evaluation & feedback. Phase2:prototype is refined Reqirements are documented & validated by customers finalprototype. Phase3:Risks are known use traditional approach for development.  Focus Area. Identify problem classify into different risk levels eliminate them before they affect software. Continuous validation(review) by concerned people(designers/developers) to check the work product quality.  Advantages: Accommodate good features of other SDLC models. Software quality maintained during development – By continuous risk analysis. – Reviews conducted. Disadvantages: Experties required in risk handling to carry out spiral model  Software Requirements Engineering. Understanding the requirements of the customers, then document the requirements. Document the Requirement Specification what to do, & does not tell us How to do. Work Product: It Produces one large document written in Natural language containing a description of WHAT system will do without describing HOW it will do it. SRS Importance of Requirements Eng. Without well written document: The developers will not know what to do. Customers may not be consistent about requirements. It becomes difficult to validate/accept the software.  4 steps in Requirement Engineering 1. Requirement Elicitation: Gathering of requi, requi are identified with the help of customers(Existing system) 2.Requi. Analysis: Requi are analysed to find incosistencies,defects,omittions,priorities 3. Requi. Documentation: end product of first 2 steps. Leads to prepration of SRS. It becomes foundation for design of s/w. 4. Requi. Review or verification: To improve the quality of SRS.  Software Requirement Elicitation(Requi. Gathering) Requi elicitation is an activity that helps us to undesrtand what problem has to be solved and wat customers expect from the software. Foundation:Effective communication between customer and the developer. Method: Developer questions customers. Customer responds, based on response cross questions carry outs. Hurdles: Misunderstanding/conflict(customer & developers are not understanding each others point of view) Communication gap.(unanswered questions)  Reason for Conflits Developers is efficient in the knowledge of his own development domain while customer is efficient only in his domain(not suitable to implement some functionality) Lack of proper communication skills(not understanding technical terms)  Requi Elicitation Methods. 1. Interviews: Understanding each other. Requi engineers act as mediators between customer and development team. Open minded, co-operative,understanding,flexible. Types of interviews: 1. open-ended:No pre-set agenga. No pre-defined list of questions are prepared. 2. Structure: There is a set agenda. pre-defined list of questions are prepared. In both interviews questions should be short,simple & clear. Both parties should be open for discussion in any direction. Types of stakeholders to interview. 1. Entry level personnel: They don’t have much domain knowledge. They have new ideas,opinions.general ideas(not technical) 2. Mid level: Experience people with good domain knowledge they know the criticality of the project. Eg. Project Managers 3. Mangers and higher managements: Useful insights about the project. 4. Users of S/W: They will be using the software max no. of time.  2. BrainStroming Session. Group Discussion techniques. Promotes creative thinking & new ideas. Platform to express and share your views, expectations & difficulties in implementation. Facilitators: Ego clashes/conflicts(to avoid them) Encourage people to participate as much as possible. Work Product:all ideas are Documented and displayed on projector , so that all participant can see. Detailed report containing each idea in simple language is prepared and reviewed by facilitator. At end a document is prepared with list of requirements and their priority.  Types of Requirements 1. Functional and non-functional requi. 2. User and system requi.(language difference) 3. Interface specification.  Functional Requi: (Product Features) - Describes what the system has to do. - What are expectations from the software. - What the system should not do. Non-Function Requi.: - Highlight how well the software programs its function. - Eg: for user: High performance.goog interface,usability. - For developers: maintainability,testability,portability.  User Requi.: Written for users who are not experts of software field - Highlight the overview of the system without design description. - Specifies: - functional+non functional requi. - Constraints. - Quality. - External behaviour(user interaction like interfaces) - What to avoid? - Complex lang. - Technical terms.  System requi.: (expanded form of user requi.) Used as input to designers so that they can prepared SDD. Both user and system requi are a part of SRS. Interface specification: API(Application programming interfaces) are specified in SRS. What kind of interfaces customer desires.  SRS (software requirements specification) A software requirements specification (SRS) is a document that captures complete description about what the system is expected to perform. It is usually signed off at the end of requirements engineering phase.  Characteristics of good SRS. 1. Consistency:No conflict between the requirements. - Every requi must be specified using standard terminiology. - Eg. Module A should take 3 inputs but later the same module A should take 2 inputs 2. Correct: What is stated is exactly what is desired. - Expected functionality matches the requi present in SRS. 3. Unambiguos: Every stated requi has only 1 unique meaning. - Words with multiple meaning(these words should be specified with meaning) - SRS lang is used. - Advantage: lang processors exist which tell diff kinds of errors. 4. Complete: include all functional+non functional requi+constraints. - Specifies expected output from all kinds(valid/invalid) inputs from the user. 5. Traceable: each requi should be clear. - Important is because future referencing may be required for development/maintenance.(ask concerned people) 6. verifiable:Each requi is verifiable. 7. modifiable: easy to make changes in SRS retaining its structure. Agile Model What is Agile Model?(ability to move quickly and easily) Agile model, the requirements are decomposed into many small parts that can be incrementally developed. The Agile model adopts Iterative development. Each iteration is intended to be easily manageable and that can be completed within a couple of weeks only. At a time one iteration is planned, developed and deployed to the customers. Long-term plans are not made. Agile model is the combination of iterative and incremental process models. Steps involve in agile SDLC models are: Requirement gathering Requirement Analysis Design Coding Unit testing Acceptance testing  Agile Vs Traditional SDLC Models Agile is based on the adaptive software development methods, whereas the traditional SDLC models like the waterfall model is based on a predictive approach. Predictive teams in the traditional SDLC models usually work with detailed planning and have a complete forecast of the exact tasks and features to be delivered in the next few months or during the product life cycle. Predictive methods entirely depend on the requirement analysis and planning done in the beginning of cycle. Any changes to be incorporated go through a strict change control management and prioritization. Agile uses an adaptive approach where there is no detailed planning and there is clarity on future tasks only in respect of what features need to be developed. There is feature driven development and the team adapts to the changing product requirements dynamically. The product is tested very frequently, through the release iterations, minimizing the risk of any major failures in future. Customer Interaction is the backbone of this Agile methodology, and open communication with minimum documentation are the typical features of Agile development environment. The agile teams work in close collaboration with each other and are most often located in the same geographical location.  Use of Agile Model In earlier days Iterative Waterfall model was very popular to complete a project. But nowadays developers face various problems while using it to develop a software. The main difficulties included - handling change requests from customers during project development - the high cost and time required to incorporate these changes. - To overcome these drawbacks , in the mid-1990s the Agile Software Development model was proposed.  Why agility is Required? The Agile model was primarily designed to help a project to adapt to change requests quickly. So, the main aim of the Agile model is to facilitate quick project completion. Agility is achieved by removing activities that may not be essential for a specific project. Also, anything that is wastage of time and effort is avoided.  Agile SDLC models Crystal Atern Feature-driven development Scrum Extreme programming (XP) Lean development Unified process These are now collectively referred to as Agile Methodologies, after the Agile Manifesto was published in 2001.  Following are the Agile Manifesto principles − Individuals and interactions − In Agile development, self-organization and motivation are important, as are interactions like co-location and pair programming. Working software − Demo working software is considered the best means of communication with the customers to understand their requirements, instead of just depending on documentation. Customer collaboration − As the requirements cannot be gathered completely in the beginning of the project due to various factors, continuous customer interaction is very important to get proper product requirements. Responding to change − Agile Development is focused on quick responses to change and continuous development.  Software Delivery. The time to complete an iteration is known as a Time Box. Time-box refers to the maximum amount of time needed to deliver an iteration to customers. So, the end date for an iteration does not change. The development team can decide to reduce the delivered functionality during a Time-box if necessary to deliver it on time. The principle of the Agile model is the delivery of an increment to the customer after each Time-box.  Advantages of Agile model: Customer satisfaction by rapid, continuous delivery of useful software. Customers, developers and testers constantly interact with each other. Working software is delivered frequently (weeks rather than months). Face-to-face conversation is the best form of communication. Daily cooperation between business people and developers. Continuous attention to technical excellence and good design. Regular adaptation to changing circumstances. Even late changes in requirements are welcomed.  Disadvantages of Agile model: In case of some software deliverables, especially the large ones, it is difficult to assess the effort required at the beginning of the software development life cycle. There is lack of emphasis on necessary designing and documentation. The project can easily get taken off track if the customer representative is not clear what final outcome that they want. Only senior programmers are capable of taking the kind of decisions required during the development process. Hence it has no place for new programmers, unless combined with experienced resources.  Example of Agile software development Example: Google is working on project to come up with a competing product for MS Word, that provides all the features provided by MS Word and any other features requested by the marketing team. The final product needs to be ready in 10 months of time. Let us see how this project is executed in traditional and Agile methodologies.  In traditional Waterfall model – At a high level, the project teams would spend 15% of their time on gathering requirements and analysis (1.5 months) 20% of their time on design (2 months) 40% on coding (4 months) and unit testing 20% on System and Integration testing (2 months). At the end of this cycle, the project may also have 2 weeks of User Acceptance testing by marketing teams. In this approach, the customer does not get to see the end product until the end of the project, when it becomes too late to make significant changes. project schedule in traditional software development.  With Agile development methodology– In the Agile methodology, each project is broken up into several ‘Iterations’. All Iterations should be of the same time duration (between 2 to 8 weeks). At the end of each iteration, a working product should be delivered. In simple terms, in the Agile approach the project will be broken up into 10 releases (assuming each iteration is set to last 4 weeks). Rather than spending 1.5 months on requirements gathering, in Agile software development, the team will decide the basic core features that are required in the product and decide which of these features can be developed in the first iteration. Any remaining features that cannot be delivered in the first iteration will be taken up in the next iteration or subsequent iterations, based on priority. At the end of the first iterations, the team will deliver a working software with the features that were finalized for that iteration. There will be 10 iterations and at the end of each iteration the customer is delivered a working software that is incrementally enhanced and updated with the features that were shortlisted for that iteration. The iteration cycle of an Agile project  Unified Model The Unified Process Model (UPM) is an iterative, incremental, architecture-centric and use-case driven approach to software development. Use-case driven approach The list of requirements specified by a customer are converted to functional requirements by a business analyst and generally referred to as use cases. For example, the online cake shop can be specified in terms of use cases such as 'Add cake to cart', 'Change the quantity of added cakes in cart', 'Cake Order Checkout' and so on. Architecture-centric approach creating a blueprint of the organization of the software system. It would include taking into account the different technologies, programming languages, operating systems, development and release environments, for developing the software.  Phases of Unified Process Model. Inception: initial concept(requirement gathering) Elaboration: exploring requirements Construction: building the software Transition: final packaging  Inception : The inception phase is similar to the 'Requirements Collection and Analysis' stage of the Waterfall Model of software development. In this phase, you'd collect requirements from the customer, analyse the project's feasibility, it's cost, risks and profits. Elaboration : In this phase, you'd be expanding upon the activities undertaken in the inception phase. The major goals of this phase include creating fully functional requirements (use cases) and creating a detailed architecture for fulfillment of the requirements. You'd also prepare a business case document for the customer.  Construction : In this phase, you'd be writing actual code and implementing the features for each iteration. You'd be rolling out the first iteration of the software depending on the key use cases that make up the core functionalities of the software system. Transition : In this phase, you'd be rolling out the next iterations to the customer and fixing bugs for previous releases. You would also deploy 'builds' of the software to the customer.  Advantages of UP Rapid feedback from users and developers – Then adapt to changes in the next iteration (adaptive development) Visible progress. Manage complexity by dividing the problem into smaller ones.  Scrum Scrum is a project management framework that is applicable to any project with aggressive deadlines, complex requirements. In Scrum, projects move forward via a series of iterations called sprints. Each sprint is typically two to four weeks long. Roles of SCRUM  Scrum Best Practices Define requirements just in time to keep product features as relevant as possible. Test and incorporate product owner feedback daily. Sprint reviews with stakeholders need to be regular. The scrum team needs to use the sprint retrospectives to improve how they work. Conduct face-to-face conversations to reduce miscommunications. Trust the teams to do the best job possible. Don’t burn out the team members. Respect the balance between their personal and professional lives to ease stress.  Extreme Programming(XP) Extreme Programming (XP) is an agile software development framework that aims to produce higher quality software. Extreme programming (XP) is one of the most important software development framework of Agile models. It is used to improve software quality and responsive to customer requirements. The extreme programming model recommends taking the best practices that have worked well in the past in program development projects to extreme levels.  Values of XP/Best Practices The five values of XP are: Communication XP of communication - face to face discussion with the aid of a white board or other drawing mechanism. Simplicity Simplicity means “what is the simplest thing that will work?” The purpose of this is to avoid waste and do only absolutely necessary things such as keep the design of the system as simple as possible so that it is easier to maintain, support, and revise. Simplicity also means address only the requirements that you know about; don’t try to predict the future.  Feedback Through constant feedback about their previous efforts, teams can identify areas for improvement and revise their practices. Feedback also supports simple design. Your team builds something, gathers feedback on your design and implementation, and then adjust your product going forward. Courage You need courage to raise organizational issues that reduce your team’s effectiveness. courage to stop doing something that doesn’t work and try something else. courage to accept and act on feedback, even when it’s difficult to accept. Respect The members of your team need to respect each other in order to communicate with each other, provide and accept feedback that honors your relationship, and to work together to identify simple designs and solutions.  Project Manager. A software project manager is the most important person inside a team who takes the overall responsibilities to manage the software projects and play an important role in the successful completion of the projects. A project manager has to face many difficult situations to accomplish activities like building up team moral. Most of the managers take responsibility for: writing the project proposal, project cost estimation, scheduling, project staffing, project monitoring and control, software configuration management, risk management and interfacing with clients.  The task of a project manager are classified into two major types: 1. Project planning 2. Project monitoring and control  I. Project Planning Project planning is undertaken immediately after the feasibility study phase and before the starting of the requirement analysis phase. Once a project has been found to be feasible, Software project managers started project planning. Project planning is completed before any development phase starts. Project planning involves estimating several characteristics of a project and then plan the project activities based on these estimations. Project planning is done with most care and attention. A wrong estimation can result in : Schedule delay can cause customer dissatisfaction, which may lead to a project failure. For effective project planning, in addition to a very good knowledge of various estimation techniques, past experience is also very important. During the project planning the project manager performs the following activities: During the project planning the project manager performs the following activities: Project Estimation: Project Size Estimation is the most important parameter based on which all other estimations like cost, duration and effort are made. – Cost Estimation: Total expenses to develop the software product is estimated. – Time Estimation: The total time required to complete the project. – Effort Estimation: The effort needed to complete the project is estimated. The effectiveness of all later planning activities is dependent on the accuracy of these three estimations. Scheduling: After completion of estimation of all the project parameters, scheduling for manpower and other resources are done. Staffing: Team structure and staffing plans are made. Risk Management: The project manager should identify the unanticipated risks that may occur during project development risk, analysis the damage might cause these risks and take risk reduction plan to cope up with these risks. Miscellaneous plans: This includes making several other plans such as quality assurance plan, configuration management plan, etc. II. Project monitoring and control Project monitoring and control activities are undertaken once the development activities start. The main focus of project monitoring and control activities is to ensure that the software development proceeds as per plan. This includes checking whether the project is going on as per plan or not if any problem created then the project manager must take necessary action to solve the problem.  knowledge areas of Project Management: Project Integration Management to identify, define, combine, unify, and coordinate the various processes and project management activities within the Project Management Process Groups. Project Scope Management : only the work required, to complete the project successfully.  Project Time Management : to manage the timely completion of the project. Project Cost Management : planning, estimating, budgeting, financing, funding, managing, and controlling costs so that the project can be completed within the approved budget. Project Quality Management : organization performing to determine quality policies, objectives, and responsibilities so that the project will satisfy the needs for which it was undertaken.  Project Human Resource Management : the processes that organize, manage, and lead the project team. Project Communications Management : that are required to ensure timely and appropriate planning, collection, creation, distribution, storage, retrieval, management, control, monitoring, and the ultimate disposition of project information.  Project Risk Management : conducting risk management planning, identification, analysis, response planning, and controlling risk on a project. Project Procurement Management : necessary to purchase or acquire products, services, or results needed from outside the project team Project Stakeholders Management : identify all people or organizations impacted by the project, analyzing stakeholder expectations and impact on the project, and developing appropriate management strategies for effectively engaging stakeholders in project decisions and execution.