Week 1 Introduction to Project Management

<AFTER REF. BY K. SCHWALBY> Q : What is a project and what is the difference from operations ? A : A project is a temporary endeavor undertaken to create a unique product, service, or result. Operations, on the other hand, is work done in organizations to sustain the business. Projects are different from operations in that they end when their objectives have been reached or the project has been terminated

Q : What are project attributes ? A : 1) A project has a unique purpose, 2) A project is temporary, 3) A project is developed using progressive elaboration, 4) A project requires resources, often from various areas, 5) A project should have a primary customer or sponsor, 6) A project involves uncertainty

Q : State the triple (quadruple) constraint of the project ! A : 1) Scope : What work will be done ?, 2) Time : When and how long should it take to complete the project ?, 3) Cost : What should it cost to complete the project ?, 4) Quality : Does the projects product satisfy the customer ? How to realize it ?

Q : What is project management ? A : Project management is the application of knowledge, skills, tools and techniques to project activities to meet project requirements.

Q : What should a project manager do to succeed the project ? A : Project managers must not only strive to meet specific scope, time, cost, and quality goals of projects, they must also facilitate the entire process to meet the needs and expectations of the people involved in or affected by project activities.

Q : Illustrate the project management framework ! A:

Q : State the advantages of using formal project management ! A : 1) Better control of financial, physical, and human resources, 2) Improved customer relations, 3) Shorter development times, 4) Lower costs and improved productivity, 5) Higher quality and increased reliability, 5) Higher profit margins, 6) Better internal coordination, 7) Positive impact on meeting strategic goals, 8) Higher worker morale

Q : Explain the project stakeholders ! A : Stakeholders are the people involved in or affected by project activities and include the project sponsor, project team, support staff, customers, users, suppliers, and even opponents of the project.

Q : What is project management knowledge areas ? A : Project management knowledge areas describe the key competencies that project managers must develop, which consist of four core knowledge areas (scope management, time management, cost management, quality management), four facilitating knowledge areas (human resource management, communications management, risk management, procurement management) and integration management. See Project Management Framework

Q : State several ways to define the success of a project ! A : 1) The project met scope, time, and cost goals, 2) The project satisfied the customer/sponsor, 3) The results of the project met its main objective, such as making or saving a certain amount of money, providing a good return on investment, or simply making the sponsors happy.

Q : What helps projects succeed ? A : 1) Executive support, 2) User involvement, 3) Experienced project manager, 4) Clear business objectives, 5) Minimized scope, 6) Standard software infrastructure, 7) Firm basic requirements, 8) Formal methodology, 9) Reliable estimates, 10) Other criteria, such as small milestones, proper planning, competent staff, and ownership

Q : What are suggested knowledges and skills for project managers ? A : 1) The Project Management Body of Knowledge, 2) Application area knowledge, standards, and Regulations, 3) Project environment knowledge, 4) General management knowledge and skills, 5) Soft skills or human relations skills

Q : State ten most important skills and competencies for project managers ! A : 1) People skills, 2) Leadership, 3) Listening, 4) Integrity, ethical behavior, consistent, 5) Strong at building trust, 6) Verbal communication, 7) Strong at building teams, 8) Conflict resolution, conflict management, 9) Critical thinking, problem solving, 10) Understands, balances priorities

<AFTER REF. BY J. RAKOS> Q : Illustrate the project phase defined by J. Rakos !

A:

Q : State the reasons why the projects fail at the start, in the development stages and at the end of the project ? A : a) At the start : 1) Do no get off the ground, 2) Unrealistic deadline and budget; b) In the development stages : 1) Analysis and design are not documented, 2) The responsibilities are not clearly assigned to specific individuals, 3) Design, testing, and implementation methods are invaluable is not thoroughly understood, 4) Lack of walk-throughs and review, 5) Many project failures are blamed on turnover, 6) Lack of development standard, 7) Brute force techniques such as add more manpower do not work; c) At the end : 1) Delivery without thorough debugging, 2) Do not deliver the promised performance, 3) Maintenance cost is too high, 4) Overrun in expense and schedule, unhappy users, damaged reputation, waste expensive talent, etc

<AFTER REF. BY STELLMAN & GREENE> Q : Explain the reasons why the software projects fail ! A : 1) People begin programming before they understand the problem, 2) The team has an unrealistic idea about how much work is involved, 3) Defects are injected early but discovered late, 4) Programmers have poor habits and they dont feel accountable for their work, 5) Managers try to test quality into the software

Q : State several ways to make sure the projects succeed ! A : 1) Make sure all decisions are based on openly shared information, 2) Dont second-guess your team members expertise, 3) Introduce software quality from the very beginning of the project, 4) Dont impose an artificial hierarchy on the project team, 5) Remember that the fastest way through the project is to use good engineering practices

<SUMMARY> Things to remember in software project management : 1) Tell everyone the truth all the time, 2) Trust your Team, 3) Review everything, test everything, 4) All software engineers are created equal, 5) Doing the project right is most efficient, 6) Using tools and technique, 7) Using project management effectively

Week 2 Software Project Planning

Q : Who needs software ? A : Most software is built in organizations for people with specific needs. Personnel who need software include a) Stakeholder : anyone who has an interest (or stake) in the software being completed, b) User : someone who will need to use the software to perform tasks. Sometimes stakeholders will be users, but often the stakeholder will not use the software.

Q : Who builds software ? A : Software is typically built by a team of software engineers, which includes : a) Business analysts or requirements analysts who talk to users and stakeholders, plan the behavior of software and write software requirements, b) Designers and architects who plan the technical solution, c) Programmers who write the code, d) Testers who verify that the software meets its requirements and behaves as expected

Q : Explain the roles of a project manager in managing a software project ! A : The project manager plans and guides the software project, in such he or she : 1) is responsible for identifying the users and stakeholders and determining their needs, and 2) coordinates the team, ensuring that each task has an appropriate software engineer assigned and that each engineer has sufficient knowledge to perform it. To do this well, the project manager must be familiar with every aspect of software engineering

Q : How does the project manager drive the scope of the project ? A : The project manager should identify it by talking to and communicating with the main stakeholder. The effective way to show stakeholders that their needs are understood and that those specific needs will be addressed is with a vision and scope document

Q : Illustrate the outline of a typical vision and scope document ! A:

Q : What is a project plan ? A : A project plan defines the work that will be done on the project and who will do it. A typical project plan consists of : a) A statement of work (SOW) that describes all work products (specifications, test plans, code, defect reports, and any other product of work performed over the course of the project) that will be produced and a list of people who will perform that work, b) A resource list that contains a list of all resources that will be needed for the product, and their availability, c) A work breakdown structure and a set of effort estimates, d) A project schedule, e) A risk plan that identifies any risks that might be encountered and indicates how those risks would be handled, should they occur

Q : What is a statement of work (SOW) ? A : SOW is a detailed description of all of the work products which will be created over the course of the project. It includes : a) A list of features that will be developed, b) A description of each intermediate deliverable or work product that will be built, c) The estimated effort involved for each work product to be delivered

Q : What is a resource ? A : A resource is a person, hardware, room or anything else that is necessary for the project but limited in its availability

Q : What is a work breakdown structure (WBS) ? A : A work breakdown structure (WBS) is a list of tasks which, if performed, will generate all of the work products needed to build the software.

Q : Explain what a risk plan is, steps to create and illustrate an example ? A : A risk plan is a list of all risks that threaten the project, along with a plan to mitigate some or all of those risks. A risk plan can be created by firstly brainstorm the potential risks, then estimate the impact of each risk and build the risk plan. An example of typical risk plan is shown below.

Week 3 Estimation

Q : Why is estimation needed in executing a software project ? A : Estimation is a base for the project manager to set expectations about the time required to complete the software among the stakeholders, the team, and the organizations management. If those expectations are not realistic from the beginning of the project, the stakeholders will not trust the team or the project manager.

Q : List the elements of a sound estimate ! A : To generate a sound estimate, a project manager must have : a) A work breakdown structure (WBS), or a list of tasks which, if completed, will produce the final product, b) An effort estimate for each task, c) A list of assumptions which were necessary for making the estimate, d) Consensus among the project team that the estimate is accurate

Q : What is Wideband Delphi ? A : Wideband Delphi is a process that a team can use to generate an estimate. In Wideband Delphi, the project manager chooses an estimation team, and gains consensus among that team on the results. Wideband Delphi is a repeatable estimation process because it consists of a straightforward set of steps that can be performed the same way each time

Q : State 6 steps of Wideband Delphi process ! A : 1) Choosing the team : The project manager selects the estimation team (3 to 7 representatives project team members) and a moderator ; 2) Kickoff meeting : The moderator leads a discussion to brainstorm assumptions, generate a WBS, and decide on the units of estimation ; 3) Individual preparation : Each team member generates the initial estimates for each task in the WBS, documenting any changes to the WBS and missing assumptions ; 4) Estimation session : The moderator leads the team through a series of iterative steps to gain consensus on the estimates. The cycle repeats until either no estimator wants to change his or her estimate, the estimators agree that the range is acceptable, or two hours have elapsed ; 5) Assembling tasks : The project manager works with the team to collect the estimates from the team members at the end of the meeting and compiles the final task list, estimates, and assumptions ; 6) Reviewing results : The project manager reviews the final task list with the estimation team.

Week 4 Project Schedules

Q : What is a project schedule ? A : A project schedule is a calendar that links the tasks to be done with the resources that will do them. Before a project schedule can be created, the project manager must have a work breakdown structure (WBS) and estimates. The schedule is part of the project plan.

Q : What is effort ?

A : Effort represents the work required to perform a task. Effort is measured in person-hours (or person-days, person-weeks, etc.). It represents the total number of hours that each person spent working on the task.

Q : What is duration ? A : Duration is amount of time that elapses between the time the task is started and the time it is completed. Duration is measured in hours (or days, weeks, etc.). It does not take into account the number of people performing the task

Q : What is slack ? A : Slack is the amount of time which any of the tasks can be delayed without causing the due date of the final task in the sequence to be delayed as well. A tight schedule has very little slack; a delay in any task will cause a delay in the due date. Parkinsons Law: Work expands so as to fill the time available for its completion.

Q : What is overhead ? A : Overhead is any effort that does not go to the core activities of the task but is still required in order for the people to perform ita sort of real world cost of actually doing the work. Two people performing a task will require more effort than one person doing the same task. Assigning two people to the task requires more effort, but the task has a shorter duration

Q : Explain several key points in building a project schedule ! A : 1) Allocate resources : Assign sufficient resource for each task in WBS based on qualifications, familiarity and availability by considering also the overhead when calculating the duration of each task ; 2) Identify dependencies : A task has a dependency if it involves an activity, resource or work product which is subsequently required by another task ; 3) Create the schedule : Most project schedules are represented using a Gantt chart, which shows tasks, dependencies & milestones using different shapes ; 4) Reconcile the schedule with the organizations needs : Once resources are allocated to each task, a final date can be calculated, but if this date is unacceptable, the project plan must change by either allocating additional resources to the project or cutting down the scope Brooks Law: Nine women cannot have a baby in one month. ; 5) Add review meetings to the schedule : Progress reviews are meetings which should be held regularly to check the progress of a project versus it's scheduled progress, while milestone reviews are meetings which the project manager schedules in advance to coincide with project events ; 6) Optimize the schedule : Allocating resources to tasks on the critical path (the sequence of tasks that represent the minimum time required to complete the project) will reduce the project schedule; allocating them to other tasks will have less effect on the due date ; 7) Do not abuse buffers : A buffer is a task added to the schedule with no specific purpose except to account for unexpected delays; buffers should not be used to add time to compensate for an inaccurate estimate.

Q : Illustrate four types of predecessor ! A:

Q : Illustrate Gantt chart ! A:

# The black diamond between tasks D and E is a milestone, or a task with no duration. Milestones are used to show important events in the schedule. The black bar above tasks D and E is a summary task, which shows that these tasks are two subtasks of the same parent task. # Task A is a Finish-to-Start (FS) predecessor of Task B. Task B does not start until Task A is complete. # Task A is a Start-to-Start (SS) predecessor of Task C. Both tasks start at the same time. If the start time for Task A were delayed, then the start time for Task C would move forward to match it. # Task C is a Finish-to-Start (FS) predecessor of Task D. Task D is a Finish-to-Start (FS) predecessor of a milestone, which in turn is a Finish-to-Start predecessor of Task E. # Task E is a Finish-to-Finish (FF) predecessor of Task B. Note the delay before Task B startsit does not start until its planned completion time will match up with Task E.

Q : Explain the following project metirc terms : Baseline, Variance, BCWS, ACWP, CPI ! A : Baseline is the version of the schedule that has been approved ; Variance is the difference between the estimated effort in the baseline and the actual effort performed by the team Variance = BCWS ACWP; BCWS (Budgeted Cost for Work Scheduled) is the estimated effort of the actual tasks that appear on the schedule to date ; ACWP (Actual Cost of Work Performed) is the effort spent on the tasks in the schedule that have actually been completed by the development team members ; CPI (cost performance index) is calculated by dividing BCWS / ACWP and multiplying by 100 to express it as a percentage.

Week 5 Review

Q : What is review ? A : A review is any activity in which a work product is distributed to reviewers who examine it and give feedback.

Q : Why are reviews useful ? A : Reviews are useful not only for finding and eliminating defects, but also for gaining consensus among the project team, securing approval from stakeholders, and aiding in professional development for team members. Reviews also help teams find defects soon after they are injected making them cost less to fix than they would cost if they were found in test.

Q : What are the objects of review in a software project ? A : Software requirements specifications, schedules, design documents, code, test plans, test cases, and defect reports should all be reviewed.

Q : What is inspection ? A : Inspection is a moderated meetings in which reviewers list all issues and defects they have found in the document and log them so that they can be addressed by the author.

Q : What is the goal of the inspection ? A : To repair all of the defects so that everyone on the inspection team can approve the work product. Commonly inspected work products include software requirements specifications and test plans.

Q : State several key points in running an inspection ! A : 1) A work product is selected for review and a team is gathered for an inspection meeting to review the work product ; 2) A moderator is chosen to moderate the meeting ; 3) Each inspector prepares for the meeting by reading the work product and noting each defect ; 4) In an inspection, a defect is any part of the work product that will keep an inspector from approving it ; 5) Discussion is focused on each defect, and coming up with a specific resolution ; 6) The moderator compiles all of the defect resolutions into an inspection log

Q : What is a deskcheck ? A : A deskcheck is a simple review in which the author of a work product distributes it to one or more reviewers. Unlike an inspection, a deskcheck does not produce written logs which can be archived with the document for later reference. Deskchecks can be used as predecessors to inspections.

Q : What is a walkthrough ? A : A walkthrough is an informal way of presenting a technical document in a meeting. Walkthroughs are used when the author of a work product needs to take into account the perspective of someone who does not

have the technical expertise to review the document.

Q : What is a code review ? A : A code review is a special kind of inspection in which the team examines a sample of code and fixes any defects in it. In a code review, a defect is a block of code which does not properly implement its requirements, which does not function as the programmer intended, or which is not incorrect but could be improved

Q : What is pair programming ? A : Pair programming is a technique in which two programmers work simultaneously at a single computer and continuously review each others work. In pair programming, two programmers sit at one computer to write code. Generally, one programmer will take control and write code, while the other watches and advises. Pair programming improves the organization by ensuring that at least two programmers are able to maintain any piece of the software.

Week 6 Software Requirement

Q : What are software requirements ? A : Software requirements are documentation that completely describes the behavior that is required of the software-before the software is designed built and tested.

Q : How are software requirements specifications built ? A : Software requirements specifications are built by analysts through requirements elicitation, which includes a) Interviews with the users, stakeholders and anyone else whose perspective needs to be taken into

account during the design, development and testing of the software; b) Observation of the users at work; c) Distribution of discussion summaries to verify the data gathered in interviews.

Q : Illustrate a typical discussion summary template ! A:

Q : What is a use case ? A : A use case is a description of a specific interaction that a user may have with the system. Use cases do not describe any internal workings of the software, nor do they explain how that software will be implemented. They simply show how the steps that the user follows to use the software to do his work.

Q : Illustrate a typical use case template ! A:

Q : What are software requirements specifications (SRS) ? A : SRS represents a complete description of the behavior of the software to be developed. SRS includes a) A set of use cases that describe all of the interactions that the users will have with the software; b) All of the functional requirements necessary to define the internal workings of the software: calculations, technical details, data manipulation and processing, and other specific functionality that shows how the use cases are to be satisfied; c) Nonfunctional requirements, which impose constraints on the design or implementation (such as performance requirements, quality standards or design constraints).

Q : What is the difference between functional requirement and nonfunctional requirement ? A : Functional requirements define the outward behavior required of the software project. Nonfunctional requirements define characteristics of the software which do not change its behavior. The nonfunctional requirements are sometimes referred to as non-behavioral requirements or software quality attributes

Q : What is the difference between scope, requirements and design? A : Scope demonstrates the needs of the organization, and is documented in a vision and scope document. Requirements document the behavior of the software that will satisfy those needs. Design shows how those requirements will be implemented technically

Q : What is change control ? A : Change control is a method for implementing only those changes that are worth pursuing, and for preventing unnecessary or overly costly changes from derailing the project. Change control is an agreement between the project team and the managers that are responsible for decision-making on the project to evaluate the impact of a change before implementing it.

Q : What is change control board (CCB) ? A : CCB is made up of the decision-makers, project manager, stakeholder or user representatives, and

selected team members. CCB analyzes the impact of all requested changes to the software and has the authority to approve or deny any change requests once development is underway.

Week 7 Design and Programming

Q : What activities should be carried out by the team after SRS has been approved ? A : 1) The programmers can simply start building the code and create the objects and user interface elements; 2) Designers can build a user interface prototype to demonstrate to the users, stakeholders, and the rest of the team; 3) Pictures, flow charts, data flow diagrams, database design diagrams, and other visual tools can be used to determine aspects of the design and architecture; 4) An object model can be developed on paper, either using code, simple class diagrams, or Unified Modeling Language (UML) diagrams; 5) A written design specification is written, which includes some or all of these tools.

Q : What is a version control ? A : A version control is a system which has a purpose to bring the projects source code under control. It allows programmers to keep track of every revision of all source code files. The main element of the version control system is the repository, a database or directory which contains each of the files contained in the system. A programmer can pick a point at any time in the history of the project and see exactly what those files looked like at the time. It is always possible to find the latest version of any file by retrieving it from the repository. Changing a file will not unexpectedly overwrite any previous changes to that file; any change can be rolled back, so no work will accidentally be overwritten.

Q : Explain two common models for version control ! A : 1) A copy-modify-merge system : In this system, multiple people can work on a single file at a time. When a programmer wants to update the repository with his changes, he retrieves all changes which have occurred to the checked out files and reconciles any of them which conflict with changes he made before updating the repository. 2) A lock-modify-unlock system : In this system, only one person can work on any file at a time. A programmer must check a file out of the repository before it can be modified. The system prevents anyone else from modifying any file until it is checked back in. On large projects, the team can run into delays because one programmer is often stuck waiting for a file to be available.

Q : What is refactoring ? A : Refactoring is a programming technique in which the design of the software is improved without changing its behavior. There are many choices that programmers make which do not affect the behavior of the software but which can have an enormous impact on how easy the code is to read and understand. Examples of refactoring are Extract Method, Replace Magic Number with Symbolic Constant, Decompose Conditional, and Introduce Explaining Variable.

Q : What is the purpose of unit testing ? A : The purpose of unit testing is to create a set of tests for each unit to verify that it performs its function

correctly. To do it, programmers create suites of unit tests, where each test is a small block of code which exercises a specific behavior of one unit. The most common (and effective) way for programmers to do unit testing is to use a framework, a piece of software that automatically runs the tests and reports the results.