Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.
Planning and Managing You have a project and you have a customer, but Do you understand the requirements? Can you design such a system? How long will it take? How much will it cost?
Schedule and Deliverables Documentation Prototype Individual Subsystems Accuracy Performance, reliability, security, etc.
Milestones and Activities Activity – a part of project that takes place over a period of time. Milestone – the completion of activity, a particular point in time.
Activity Graph Estimating Completion: Critical Path Method Real time vs. available time Slack time = available - real
Project Personnel Manager Requirements analyst System design architect Data modelers Programmers Testers Support Personnel Test team should be independent from developer team!
Choosing People Ability to perform work Interest in the work Experience with similar problems Experience with tools, languages Experience with development process Communication skills Match for other team members
Developer Traits Intuitive – bases decisions on feelings Rational – bases decisions on facts Extroverts – communicate ideas Introverts – ask for suggestions How do you balance a team? Characterize yourself!
Project Organization Project structure is driven by: Team member background Team size Managerial style
Chief Programmer Team + Minimizes communication overhead + Responsibility is clear Chief has to be a quick-thinking extravert
Egoless Approach + Everyone is equally responsible Responsibility is not clear + Democratic decision making + Product is criticized, not people
Structure vs. Creativity Observation Unstructured / loose teams produce the most creative designs but never complete one on time. Highly structured / organized teams tend to turn out bland designs but in timely manner. There has to be always a balance between structure and creativity!
Effort Estimation Why need effort estimation? To provide project cost guidelines and avoid cost overruns. Easiest and most accurate – from personal experience. But what about new projects? Or new teams?
Causes of Estimation Inaccuracy User-initiated change requests Overlooked tasks / incomplete analysis Lack of understanding of requirements Integration with unknown systemDevelopment phase Lack of coordination Lack of experience Lack of resources
Expert Judgment Ask around and get competitive bids. - Pay attention to fine print! Delphi technique: Cost = (pessimistic + 4*optimistic + likely)/6 Subjective, depends on environment.
Algorithmic Models Analyze prior data (which has to be available!) Effort = const*Project Size Effort º Developer-days Project Size º Lines of Code Applies to large organizations with vast history of data. But can we use them?
In Reality… Given - existing team and resources - process model (e.g. waterfall) - and based on experience Simulate development effort accounting for - Several iterations (from experience) - Unanticipated difficulties - User-introduced changes - Poorly understood specification And produce three estimates (optimistic, pessimistic, and average) and explain the results to customer.
Risk Management Risk factors: 1. Impact: a monetary loss associated with the event. 2. Probability: likelihood of the event to occur. Probability = 1 is a real problem 3. Controllability of the outcome. What can we do to minimize the negative outcome?
Top Risk Items Personnel shortfalls Leveraging talent, teambuilding & balancing, personality matching, training Unrealistic schedules and / or budgets. Detailed estimation, requirement scrubbing. Implementing wrong functions. Prototyping “Gold plating” Cost-benefit analysis Continuous requirement change Incremental development External shortfalls Compatibility analysis Performance shortfall Simulation, modeling, load testing Cutting-edge science Is the solution possible in principle?
Risk Identified: Now What? Changing requirements to avoid risk Transferring risk (and responsibility) to other systems or departments Buying insurance policy (duh!) Assuming and controlling the risk.
Risk Reduction Cost Risk Leverage = (Risk Exposure before reduction – Risk Exposure after reduction)/(cost of reduction) Is Risk Leverage enough to justify the action?
Project Plan Scope Requirements Technical specification Schedule Team organization Standards Test plan QA plan Deployment plan Maintenance plan
Homework Create a plan for YOUR project. Read Chapter 3.