Software Project Management - Printable Version +- Free Academic Seminars And Projects Reports (https://easyreport.in) +-- Forum: Project Ideas And Disscussion (https://easyreport.in/forumdisplay.php?fid=32) +--- Forum: Engineering Project Ideas (https://easyreport.in/forumdisplay.php?fid=33) +---- Forum: Computer Science Project Ideas (https://easyreport.in/forumdisplay.php?fid=36) +---- Thread: Software Project Management (/showthread.php?tid=37772) |
Software Project Management - swati swagatika sahu - 10-04-2017 [attachment=14604] Software Project Management Rational Unified Framework Part 1 Software Management Renaissance Introduction In the past ten years, typical goals in the software process improvement of several companies are to achieve a 2x, 3x, or 10x increase in productivity, quality, time to market, or some combination of all three, where x corresponds to how well the company does now. The funny thing is that many of these organizations have no idea what x is, in objective terms. Part 1 Software Management Renaissance Part 1 Software Management Renaissance Table of Contents (1) The Old Way (Conventional SPM) The Waterfall Model Conventional Software Management Performance Evolution of Software Economics Software Economics Pragmatic Software Cost Estimation Part 1 Software Management Renaissance Table of Contents (2) Improving Software Economics Reducing Software Product Size Improving Software Processes Improving Team Effectiveness Improving Automation through Software Environments Achieving Required Quality Peer Inspections: A Pragmatic View The Old Way and the New The Principles of Conventional Software Engineering The Principles of Modern Software Management Transitioning to an Iterative Process The Old Way Part 1 The Old Way Software crisis The best thing about software is its flexibility It can be programmed to do almost anything. The worst thing about software is also its flexibility The almost anything characteristic has made it difficult to plan, monitor, and control software development. Part 1 The Old Way The Waterfall Model Drawbacks Protracted integration and late design breakage Late risk resolution Requirements - driven functional decomposition Adversarial stakeholder relationships Focus on document and review meetings Part 1 The Old Way Conventional Software Management Performance Finding and fixing a software problem after delivery costs 100 times more than finding and fixing the problem in early design phases. You can compress software development schedules 25% of nominal, but no more. For every $1 you spend on development, you will spend $2 on maintenance. Software development and maintenance costs are primarily a function of the number of source lines of code. Variations among people account for the biggest differences in software productivity. The overall ratio of software to hardware costs is still growing. In 1955 it was 15:85; in 1985, 85:15. Only about 15% of software development effort is devoted to programming. Walkthroughs catch 60% of the errors. 80% of the contribution comes from 20% of contributors. Part 1 Evolution of Software Economics Part 1 Evolution of Software Economics Most software cost models can be abstracted into a function of five basic parameters: Size (typically, number of source instructions) Process (the ability of the process to avoid non-value-adding activities) Personnel (their experience with the computer science issues and the applications domain issues of the project) Environment (tools and techniques available to support efficient software development and to automate process) Quality (performance, reliability, adaptability ) Part 1 Evolution of Software Economics Three generations of software economics Part 1 Evolution of Software Economics The predominant cost estimation process Part 1 Evolution of Software Economics Pragmatic software cost estimation A good estimate has the following attributes: It is conceived and supported by the project manager, architecture team, development team, and test team accountable for performing the work. It is accepted by all stakeholders as ambitious but realizable. It is based on a well defined software cost model with a credible basis. It is based on a database of relevant project experience that includes similar processes, technologies, environments, quality requirements, and people. It is defined in enough detail so that its key risk areas are understood and the probability of success is objectively assessed. Part 1 Improving Software Economics Five basic parameters of the software cost model: Reducing the size or complexity of what needs to be developed Improving the development process Using more-skilled personnel and better teams (not necessarily the same thing) Using better environments (tools to automate the process) Trading off or backing off on quality thresholds Part 1 Improving Software Economics Important trends in improving software economics Cost model parameters Trends Part 1 Improving Software Economics Reducing Software Product Size The most significant way to improve affordability and return on investment is usually to produce a product that achieves the design goals with the minimum amount of human-generated source material. Part 1 Improving Software Economics Reducing Software Product Size - Languages Part 1 Improving Software Economics Reducing Software Product Size Object-Oriented Methods An object-oriented model of the problem and its solution encourages a common vocabulary between the end users of a system and its developers, thus creating a shared understanding of the problem being solved. Here is an example of how object-oriented technology permits corresponding improvements in teamwork and interpersonal communications. The use of continuous integration creates opportunities to recognize risk early and make incremental corrections without destabilizing the entire development effort. This aspect of object-oriented technology enables an architecture-first process, in which integration is an early and continuous life-cycle activity. An object-oriented architecture provides a clear separation of concerns among disparate elements of a system, creating firewalls that prevent a change in one part of the system from rending the fabric of the entire architecture. This feature of object-oriented technology is crucial to the supporting languages and environments available to implement object-oriented architectures. Part 1 Improving Software Economics Reducing Software Product Size Reuse Number of Projects Using Reusable Components Part 1 Improving Software Economics Reducing Software Product Size Commercial Components Part 1 Improving Software Economics Improving Software Processes Part 1 Improving Software Economics Improving Team Effectiveness (1) The principle of top talent: Use better and fewer people. The principle of job matching: Fit the task to the skills an motivation of the people available. The principle of career progression: An organization does best in the long run by helping its people to self-actualize. The principle of team balance: Select people who will complement and harmonize with one another. The principle of phase-out: Keeping a misfit on the team doesn t benefit anyone. Part 1 Improving Software Economics Improving Team Effectiveness (2) Important Project Manager Skills: Hiring skills. Few decisions are as important as hiring decisions. Placing the right person in the right job seems obvious but is surprisingly hard to achieve. Customer-interface skill. Avoiding adversarial relationships among stake-holders is a prerequisite for success. Decision-making skill. The jillion books written about management have failed to provide a clear definition of this attribute. We all know a good leader when we run into one, and decision-making skill seems obvious despite its intangible definition. Team-building skill. Teamwork requires that a manager establish trust, motivate progress, exploit eccentric prima donnas, transition average people into top performers, eliminate misfits, and consolidate diverse opinions into a team direction. Selling skill. Successful project managers must sell all stakeholders (including themselves) on decisions and priorities, sell candidates on job positions, sell changes to the status quo in the face of resistance, and sell achievements against objectives. In practice, selling requires continuous negotiation, compromise, and empathy. Part 1 Improving Software Economics Achieving Required Quality Key practices that improve overall software quality: Focusing on driving requirements and critical use cases early in the life cycle, focusing on requirements completeness and traceability late in the life cycle, and focusing throughout the life cycle on a balance between requirements evolution, design evolution, and plan evolution Using metrics and indicators to measure the progress and quality of an architecture as it evolves from a high-level prototype into a fully compliant product Providing integrated life-cycle environments that support early and continuous configuration control, change management, rigorous design methods, document automation, and regression test automation Using visual modeling and higher level language that support architectural control, abstraction, reliable programming, reuse, and self-documentation Early and continuous insight into performance issues through demonstration-based evaluations Part 1 The Old Way and the New Part 1 The Old Way and the New The Principles of Conventional Software Engineering Make quality #1. Quality must be quantified and mechanism put into place to motivate its achievement. High-quality software is possible. Techniques that have been demonstrated to increase quality include involving the customer, prototyping, simplifying design, conducting inspections, and hiring the best people. Give products to customers early. No matter how hard you try to learn users needs during the requirements phase, the most effective way to determine real needs is to give users a product and let them play with it. Determine the problem before writing the requirements. When faced with what they believe is a problem, most engineers rush to offer a solution. Before you try to solve a problem, be sure to explore all the alternatives and don t be blinded by the obvious solution. Evaluate design alternatives. After the requirements are agreed upon, you must examine a variety of architectures and algorithms. You certainly do not want to use an architecture simply because it was used in the requirements specification. Use an appropriate process model. Each project must select a process that makes the most sense for that project on the basis of corporate culture, willingness to take risks, application area, volatility of requirements, and the extent to which requirements are well understood. Use different languages for different phases. Our industry s eternal thirst for simple solutions to complex problems has driven many to declare that the best development method is one that uses the same notation through-out the life cycle. Why should software engineers use Ada for requirements, design, and code unless Ada were optimal for all these phases? Minimize intellectual distance. To minimize intellectual distance, the software s structure should be as close as possible to the real-world structure. Put techniques before tools. An undisciplined software engineer with a tool becomes a dangerous, undisciplined software engineer. Get it right before you make it faster. It is far easier to make a working program run than it is to make a fast program work. Don t worry about optimization during initial coding. Part 1 The Old Way and the New The Principles of Conventional Software Engineering Inspect code. Inspecting the detailed design and code is a much better way to find errors than testing. Good management is more important than good technology. The best technology will not compensate for poor management, and a good manager can produce great results even with meager resources. Good management motivates people to do their best, but there are no universal right styles of management. People are the key to success. Highly skilled people with appropriate experience, talent, and training are key. The right people with insufficient tools, languages, and process will succeed. The wrong people with appropriate tools, languages, and process will probably fail. Follow with care. Just because everybody is doing something does not make it right for you. It may be right, but you must carefully assess its applicability to your environment. Object orientation, measurement, reuse, process improvement, CASE, prototyping-all these might increase quality, decrease cost, and increase user satisfaction. The potential of such techniques is often oversold, and benefits are by no means guaranteed or universal. Take responsibility. When a bridge collapses we ask, what did the engineers do wrong? Even when software fails, we rarely ask this. The fact is that in any engineering discipline, the best methods can be used to produce awful designs, and the most antiquated methods to produce elegant design. Understand the customer s priorities. It is possible the customer would tolerate 90% of the functionality delivered late if they could have 10% of it on time. The more they see, the more they need. The more functionality (or performance) you provide a user, the more functionality (or performance) the user wants. Plan to throw one away .One of the most important critical success factors is whether or not a product is entirely new. Such brand-new applications, architectures, interfaces, or algorithms rarely work the first time. Design for change. The architectures, components, and specification techniques you use must accommodate change. Design without documentation is not design. I have often heard software engineers say, I have finished the design. All that is left is the documentation. Part 1 The Old Way and the New The Principles of Conventional Software Engineering 21.Use tools, but be realistic. Software tools make Part 1 The Old Way and the New The Principles of Modern Software Management The central design element Part 2 A Software Management Process Framework Part 2 A Software Management Process Framework Table of Contents (1) Life-Cycle Phases Engineering and Production Stages Inception Phase Elaboration Phase Construction Phase Transition Phase Artifacts of the Process The Artifact Sets Management Artifacts Engineering Artifacts Pragmatic Artifacts Part 2 A Software Management Process Framework Table of Contents (2) Model-based software Architectures Architecture: A Management Perspective Architecture: A Technical Perspective Workflows of the Process Software Process Workflows Iteration Workflows Checkpoints of the Process Major Milestones Minor Milestones Periodic Status Assessments Part 2 Life-Cycle Phases Engineering and Production Stages Part 2 Life-Cycle Phases Engineering and Production Stages Part 2 Life-Cycle Phases Inception Phase Part 2 Life-Cycle Phases Elaboration Phase Part 2 Life-Cycle Phases Construction Phase Part 2 Life-Cycle Phases Transition Phase Part 2 Life-Cycle Phases Part 2 Artifacts of the Process Part 2 Artifacts of the Process Management Artifacts Part 2 Artifacts of the Process Management Artifacts Part 2 Artifacts of the Process Management Artifacts Part 2 Artifacts of the Process Engineering Artifacts Part 2 Artifacts of the Process Engineering Artifacts Part 2 Artifacts of the Process Pragmatic Artifacts Part 2 Model-Based Software Architectures A Management Perspective Part 2 Model-Based Software Architectures A Management Perspective Part 2 Model-Based Software Architectures A Technical Perspective Part 2 Model-Based Software Architectures A Technical Perspective Part 2 Workflows of the Process Software Process Workflows Part 2 Workflows of the Process Software Process Workflows Part 2 Workflows of the Process Iteration Workflows Part 2 Workflows of the Process Iteration Workflows Part 2 Checkpoints of the Process Part 2 Checkpoints of the Process Part 3 Software Management Disciplines Part 3 Software Management Disciplines Table of Contents (1) Iterative Process Planning Work Breakdown Structures Planning Guidelines The Cost and Schedule Estimating Process The Iteration Planning Process Pragmatic Planning Project Organizations and Responsibilities Line-of-Business organizations Project Organizations Evolution Organizations Process Automation Tools: Automation Building Blocks The Project Environment Part 3 Software Management Disciplines Table of Contents (2) Project Control and Process Instrumentation The Seven Core Metrics Management Indicators Quality Indicators Life-Cycle Expectations Pragmatic Software Metrics Metrics Automation Tailoring the Process Process Discriminants Example: Small-Scale Project Versus Large-scale Project Part 3 Iterative Process Planning Work Breakdown Structures Part 3 Iterative Process Planning Planning Guidelines Part 3 Iterative Process Planning The Cost and Schedule Estimating Process Part 3 Iterative Process Planning The Cost and Schedule Estimating Process Part 3 Iterative Process Planning The Iteration Planning Process Part 3 Project Organizations and Responsibilities Line-of-Business Organizations Default roles in a software line-of-business organizations Part 3 Project Organizations and Responsibilities Project Organizations Software Management Team Part 3 Project Organizations and Responsibilities Project Organizations Software Architecture Team Part 3 Project Organizations and Responsibilities Project Organizations Software Development Team Part 3 Project Organizations and Responsibilities Project Organizations Software Assessment Team Part 3 Project Organizations and Responsibilities Evolution of Organizations Part 3 Process Automation Computer-aided software engineering Computer-aided software engineering (CASE) is software to support software development and evolution processes. Activity automation Graphical editors for system model development; Data dictionary to manage design entities; Graphical UI builder for user interface construction; Debuggers to support program fault finding; Automated translators to generate new versions of a program. Part 3 Process Automation Computer-aided software engineering (CASE) Technology Case technology has led to significant improvements in the software process. However, these are not the order of magnitude improvements that were once predicted Software engineering requires creative thought - this is not readily automated; Software engineering is a team activity and, for large projects, much time is spent in team interactions. CASE technology does not really support these. Part 3 Process Automation CASE Classification Classification helps us understand the different types of CASE tools and their support for process activities. Functional perspective Tools are classified according to their specific function. Process perspective Tools are classified according to process activities that are supported. Integration perspective Tools are classified according to their organisation into integrated units. Part 3 Process Automation Functional Tool Classification Part 3 Process Automation CASE Integration Tools Support individual process tasks such as design consistency checking, text editing, etc. Workbenches Support a process phase such as specification or design, Normally include a number of integrated tools. Environments Support all or a substantial part of an entire software process. Normally include several integrated workbenches. Part 3 Process Automation Tools, Workbenches, Environments Part 3 Project Control and Process Instrumentation The Core Metrics Part 3 Tailoring the Process Process Discriminants The two primary dimensions of process variability Part 3 Tailoring the Process Example: Small-Scale Project vs. Large-Scale Project Differences in workflow priorities between small and large projects Part 4 Looking Forward Part 4 Looking Forward Table of Contents Modern Project Profiles Continuous Integration Early Risk Resolution Evolutionary Requirements Teamwork Among Stakeholders Top 10 Software Management Principles Software Management Best Practices Next-Generation Software Economics Next-Generation Cost Models Modern Software Economics Modern Process Transitions Culture Shifts Denouement Part 4 Modern Project Profiles Continuous Integration Part 4 Modern Project Profiles Continuous Integration Part 4 Modern Project Profiles Early Risk Resolution Part 4 Modern Project Profiles Evolutionary Requirements Part 4 Modern Project Profiles Teamwork among stakeholders Part 4 Modern Project Profiles Top 10 Software Management Principles Part 4 Modern Project Profiles Top 10 Software Management Principles Part 4 Modern Project Profiles Software Management Best Practices Part 4 Next-Generation Software Economics Next-Generation Cost Models Part 4 Next-Generation Software Economics Next-Generation Cost Models Part 4 Next-Generation Software Economics Modern Software Economics Part 4 Next-Generation Software Economics Modern Software Economics Part 4 Modern Process Transitions Culture Shifts Part 4 Modern Process Transitions Denouement Appendix Appendix Use Case Analysis What is a Use Case? A sequence of actions a system performs that yields a valuable result for a particular actor. What is an Actor? A user or outside system that interacts with the system being designed in order to obtain some value from that interaction Use Cases describe scenarios that describe the interaction between users of the system and the system itself. Use Cases describe WHAT the system will do, but never HOW it will be done. Appendix What s in a Use Case? Define the start state and any preconditions that accompany it Define when the Use Case starts Define the order of activity in the Main Flow of Events Define any Alternative Flows of Events Define any Exceptional Flows of Events Define any Post Conditions and the end state Mention any design issues as an appendix Accompanying diagrams: State, Activity, Sequence Diagrams View of Participating Objects (relevant Analysis Model Classes) Logical View: A View of the Actors involved with this Use Case, and any Use Cases used or extended by this Use Case Appendix Use Cases Describe Function not Form Use Cases describe WHAT the system will do, but never HOW it will be done. Use Cases are Analysis Products, not Design Products. Appendix Use Cases Describe Function not Form Use Cases describe WHAT the system should do, but never HOW it will be done Use cases are Analysis products, not design products Appendix Benefits of Use Cases Use cases are the primary vehicle for requirements capture in RUP Use cases are described using the language of the customer (language of the domain which is defined in the glossary) Use cases provide a contractual delivery process (RUP is Use Case Driven) Use cases provide an easily-understood communication mechanism When requirements are traced, they make it difficult for requirements to fall through the cracks Use cases provide a concise summary of what the system should do at an abstract (low modification cost) level. Appendix Difficulties with Use Cases As functional decompositions, it is often difficult to make the transition from functional description to object description to class design Reuse at the class level can be hindered by each developer taking a Use Case and running with it . Since UCs do not talk about classes, developers often wind up in a vacuum during object analysis, and can often wind up doing things their own way, making reuse difficult Use Cases make stating non-functional requirements difficult (where do you say that X must execute at Y/sec?) Testing functionality is straightforward, but unit testing the particular implementations and non-functional requirements is not obvious Appendix Use Case Model Survey The Use Case Model Survey is to illustrate, in graphical form, the universe of Use Cases that the system is contracted to deliver. Each Use Case in the system appears in the Survey with a short description of its main function. Participants: Domain Expert Architect Analyst/Designer (Use Case author) Testing Engineer Appendix Sample Use Case Model Survey Appendix Analysis Model In Analysis, we analyze and refine the requirements described in the Use Cases in order to achieve a more precise view of the requirements, without being overwhelmed with the details Again, the Analysis Model is still focusing on WHAT we re going to do, not HOW we re going to do it (Design Model). But what we re going to do is drawn from the point of view of the developer, not from the point of view of the customer Whereas Use Cases are described in the language of the customer, the Analysis Model is described in the language of the developer: Boundary Classes Entity Classes Control Classes Appendix Why spend time on the Analysis Model, why not just face the cliff ? By performing analysis, designers can inexpensively come to a better understanding of the requirements of the system By providing such an abstract overview, newcomers can understand the overall architecture of the system efficiently, from a bird s eye view , without having to get bogged down with implementation details. The Analysis Model is a simple abstraction of what the system is going to do from the point of view of the developers. By speaking the developer s language , comprehension is improved and by abstracting, simplicity is achieved Nevertheless, the cost of maintaining the AM through construction is weighed against the value of having it all along. Appendix Boundary Classes Boundary classes are used in the Analysis Model to model interactions between the system and its actors (users or external systems) Boundary classes are often implemented in some GUI format (dialogs, widgets, beans, etc.) Boundary classes can often be abstractions of external APIs (in the case of an external system actor) Every boundary class must be associated with at least one actor: Appendix Entity Classes Entity classes are used within the Analysis Model to model persistent information Often, entity classes are created from objects within the business object model or domain model Appendix Control Classes The Great Et Cetera Control classes model abstractions that coordinate, sequence, transact, and otherwise control other objects In Smalltalk MVC mechanism, these are controllers Control classes are often encapsulated interactions between other objects, as they handle and coordinate actions and control flows. Literature Software Project Management A Unified Framework Walker Royce Software Processes Ian Sommerville 2004 Process and Method: An Introduction to the Rational Unified Process Software Project Management - djforum - 10-04-2017 Abstract: In software industry, the major problem is meeting the clients requirements with specific to a software project development is the deliverables that should be promised to the client. The client standardizes himself to a contract and fixes a specific time onto the systems, when the project has to be delivered. Once the software development contract is signed, the actual task on scheduling the manpower and machine requirements arises. In scheduling the manpower and machine requirements arise. In a software development process, if the manpower is not organized properly then it can cause a great lot of have in reaching the targets. The major goal of any software development firm is to meet the targets as fast as possible with the least manpower, to get targeted profits. The other area where the software developments firm are interested are with respect to the management of library with specific to the previous project development processes. The application training the bugs and their associated tescases that were developed previously also plays a vital role. The software project management solutions, is an application that kinds itself with the overall standards of managing a project at all levels of its development processes. The application is projected towards the maintenance of data, that is utmost necessary to know the state and status of a project that is undergoing through the process of development. The major intension its to maintain the history of all the components that have been developed for a specific projects along with the associated information about the software engineer who has been involved in the process of development of that component. This type of standard always helps the industry not only in managing the Human Resources properly but also help to keep down the maintenance upon the system. The history of information also helps in keeping the standards of bug tracking and bug management much easier, flexible and faster. The project has been planned to be having the view of distributed architecture, with centralized storage of the database. The application for the storage of the data has been planned. Using the constructs of MS-SQLServer2000 and all the user interfaces have been designed using the ASP.Net technologies. The database connectivity is planned using the Software Project Management - divya - 10-04-2017 There are mainly four main things to be kept in mind about software project management, they are four p s people, product, process and project. Key concepts to be observed here are Agile teams, co-ordination, critical practices, software scope, software team, stake holders, team leaders. It is really very important. These are really very important in this. KEY ELEMENTS Project Management Estimation Project scheduling Risk Management. It is really very important to study more about it because it is very necessary for it. |