1:these endeavors are managed as a program by the IT steering committee. The steering committee must provide oversight and governance to the entire set of projects that are undertaken by the IT organization ● The approval committee must be selective about where to allocate resources, because the organization has limited funds. ● This involves trade-offs in which the organization must give up something in return for something else in order to keep its portfolio well balanced. ● If there are three potentially high-payoff projects, yet all have very high risk, then maybe only one of the projects will be selected. 2: PPM software collects and manages information about all projects – on-going and awaiting approval. Companies stay up to date on projects and adapt to changing conditions. Features: project prioritization, employee allocation, real-time project monitoring, flagging cost and time variances, monitoring economic feasibility 3: Move from phase to phase Emphasis on deliverables from one phase flowing into the next phase Analysts and users proceed sequentially from one phase to the next. The key deliverables for each phase are typically voluminous (often, hundreds of pages) and are presented to the approval committee and project sponsor for approval as the project moves from phase to phase. 4: Subdivide the project into subprojects that can be worked on at the same time. Reduce the overall project length The parallel development methodologies evolved to address the lengthy time frame of waterfall development. Instead of doing the design and implementation in sequence, a general design for the whole system is performed. Then the project is divided into a series of subprojects that can be designed and implemented in parallel. Once all subprojects are complete, there is a final integration of the separate pieces, and the system is delivered. o 5: Emphasizes system quality through text plan development The V-model is another variation of waterfall development that pays more explicit attention to testing. The development process proceeds down the left-hand slope of the V, defining requirements and designing system components. At the base of the V, the code is written. On the upward-sloping right side of the model, testing of components, integration testing, and, finally, acceptance testing are performed. A key concept of this model is that as requirements are specified and components designed, testing for those elements is also defined. 6: RAD approach Develop system in series of versions THE most important and fundamental requirements are bundled into the first version of the system. 7: RAD approach Create a rough version of system quickly and “grow” it into final system with repetitive refinement System prototyping performs the analysis, design, and implementation phases concurrently in order to quickly develop a simplified version of the proposed system and give it to the users for evaluation and feedback. 8: RAD approach Adds emphasis on experimenting with design options before design is finalized Design options are thrown-away, but learning from them is factored into final design Throwaway prototyping includes the development of prototypes, but uses the prototypes primarily to explore design alternatives rather than as the actual new system (as in system prototyping). Throwaway prototyping has a fairly thorough analysis phase that is used to gather requirements and to develop ideas for the system concept. 9: Extreme Programming (XP), Scrum, and others Focus on short cycles that produce a complete software product Highly adaptable in dynamic environments Agile development is a group of programming-centric methodologies that focus on streamlining the SDLC. Much of the modeling and documentation overhead is eliminated; instead, face-to-face communication is preferred. A project emphasizes simple, iterative application development in which every iteration is a complete software project, including planning, requirements analysis, design, coding, testing, and documentation. 10: Extreme programming 11 emphasizes customer satisfaction and teamwork. Communication, simplicity,, feedback, and courage are core values. Developers com-municate with customers and fellow programmers. Designs are kept simple and clean. Early and frequent testing provides feedback, and developers are able to courageously respond to changing requirements and technology. Throwaway prototyping6 includes the development of prototypes, but uses the prototypes primarily to explore design alternatives rather than as the actual new system (as in system prototyping). throwaway prototyping has a Fairly thorough analysis phase that is used to gather requirements and to develop ideas for the system concept. Many of the features suggested by the users may not be well understood, however, and there may be challenging technical issues to be solved. 11??: 12:Clarity of User Requirements Familiarity with Technology System Complexity System Reliability Short Time Schedules Schedule Visibility 13:?? 14: There are two basic ways to estimate the time required to build a system. The simplest method uses the amount of time spent in the planning phase to predict the time required for the entire project. The idea is that a simple project will require little planning, and a complex project will require more planning; so using the amount of time spent in the planning phase is a reasonable wayto estimate overall project time requirements. A more precise approach to estimation is called the function point approach. This approach is a more complex—and, it is hoped, more reliable—way of estimating time and effort for a project. The details of the function point approach are explained in Appendix2A. 15: Once a project manager has a general idea of the size and approximate schedule for the project, he or she creates a work plan, which is a dynamic schedule that records and keeps track of all of the tasks that need to be accomplished over the course of the project ??? 16???: 17: A functional lead usually is assigned to manage a group of analysts, and a technical lead oversees the progress of a group of programmers and more technical staff members. 18:. Technical skills are useful for working with technical tasks (e.g., programming in Java) and in trying to understand the various roles that technology plays in the particular project (e.g., how a Web server should be conﬁgured on the basis of a projected number of hits from customers). Interpersonal skills, on the other hand, include interpersonal and communicationabilities that are used when dealing with business users, senior management executives, and other members of the project team 19: You may think that good project managers motivate their staff by rewarding them with money and bonuses, but most project managersagree that this is the last thing that should be done. The more often you reward team members with money, the more they expect it—and most times monetary motivation won’t work. Assuming that team members are paid a fair salary, technical employees on project teams are much more motivated by recognition, achievement, the work itself, responsibility, advancement, and the chance to learn new skills.18 If you feel THAT you need to give some kind of reward for motivational purposes, try a pizza or free dinner, or even a kind letter or award. These often have much more effective results 20: Clearly deﬁne plans for the project. Make sure the team understands how the project is important to the organization. Develop detailed operating procedures and communicate these to the team members. Develop a project charter. Develop schedule commitments ahead of time. Forecast other priorities and their possible impact on project. 21: Computer-aided software engineering (CASE) is a category of software that automates all or part of the development process. Some CASE software packages are primarily used during the analysis phase to create integrated diagrams of the system nd to store information regarding the system components (often called upper CASE), whereasothers are design-phase tools that create the diagrams and then generate code for database tables and system functionality (often called lower CASE).IntegratedCASE, orI-CASE 22: 1: Documentation standards The date and project name should appear as a header on all documentation. All margins should be set to 1 inch. All deliverables should be added to the project binder and recorded in its table of contents. 2:Coding standards All modules of code should include a header that lists the programmer, last date of update, and a short description of the purpose of the code. Indentation should be used to indicate loops, if-then-else statements, and case statements.On average, every program should include one line of comments for every ﬁve lines of code. 3:Procedural standards Record actual task progress in the work plan every Monday morning by 10A.M.Report to project update meeting on Fridays at 3:30P.M. All changes to a requirements document must be approved by the project manager. 23: . Often, the documentation is stored in project binder (s) that contain all the deliverables and all the internal communication that takes place—the history of the project.
A simple way to set up your documentation is to get some binders and use dividers to separate content according to the major phases of the project. An additional divider should contain internal communication, such as the minutes from status meetings, written standards, letters to and from the business users, and a dictionary of relevant business terms. Then,as the project moves forward, place the deliverables from each task into the project binder with descriptions so that someone outside of the project will be able to understand it, and keep a table of contents up to date with the content that is added. Documentation takes time up front, but it is a good investment that will pay off in the long run. 24: The science (or art) of project management is in making trade-offs among three important concepts: the size of the system (in terms of what it does), the time to complete the project (when the project will be ﬁnished), and the cost of the project. 25: You may assume that your project will be safe from scheduling problems because you carefully estimated and planned your project up front. However, the most common reason for schedule and cost overruns occurs after the project is underway—scope creep. Scope creep happens when new requirements are added to the project after the original project scope was deﬁned and “frozen.” It can happen for many reasons:Users may suddenly understand the potential of the new system and realize new functionality that would be useful; developers may discover interesting capabilities to which they become very attached; a senior manager may decide to let this system support a new strategy that was developed at a recent board meeting.
Sign up for free and study better. Anytime, anywhere.
Get started today!
Find materials for your class:
Download our app to study better. Anytime, anywhere.