References zChapter 3, Sommerville zChapters 3,5,6 & 7, Pressman zChapter 2, Unified Software Development Process
Management Spectrum zPeople Õrecruiting, selection, performance management, training, compensation, career development, organization structure, culture zProduct Õdefine product objectives and scope zProcess Õframework, methodology zProject Õproject planning, control
People zOrganization Structure (Players) Õarchitects, developers, testers, supporting management, customers and other stakeholders zSoftware Team Structure ÕMost effective if between 6-8 members ÕDemocratic decentralized ÕControlled decentralized ÕControlled centralized zCoordination and Communication
Product zArtifacts created during the life of a project Õmodels, source code, executables, documentation zScope ÕContext ÕInformation Objectives ÕFunction and Performance zProblem decomposition
Process zSet of activities that transform requirements to a product. zTemplate for creating projects ÕDefinition ÕInstitutionalization ÕImprovement Use of zProcess Models zCMM, ISO, etc
Project zOrganizational element through which software development is managed zPlanning Activities zTracking zManaging Risk
Management Activities zProposal Writing zProject Costing zPlanning and Scheduling * zMonitoring and Review * zPersonnel Selection and Evaluation zReports and Presentations *
Process Framework zS/W project typically divided into activities or tasks zEstimates are taken to drive task assignment and schedule zMilestones describe progress at the end of an activity Õprogress report Õinternal or presented zDeliverables are often part of a milestone
Software Project Estimation zDecompose Problem (identify task) zEstimate Size zEstimate Effort ÕNormally have some translation between size and effort zEstimate Cost zDon’t forget overhead!
Sizing zBased on historical data zFunction Point zStandard Component Sizing zChange Sizing zLOC based zEmpirical Estimation Models
Project Scheduling zScheduling involves: Õdistribute estimated effort across planned duration by allocating effort to specific tasks zConsiderations Õparallel activities Õproblem anticipation, regular sched updates Õresources other than time Õcritical dependencies
Scheduling Notation zTask Duration and Dependencies Õtable or activity network zActivity Bar Chart Õschedule, parallel activities Õdepicts flexibility against schedule slippage zStaff Allocation Õtable or time chart
Risk zSomething that can go wrong zCaused by inadequate information zResolved by initiating actions that Õdiscover the relevant information Õreduce uncertainty zBoehm’s Spiral Model Õexplicitly integrates risk assessment and reduction
Requirements Risks zDangers Õbuilding the wrong system Õmisunderstanding priorities zDealing with the risks Õimprove communication between analysts, developers, and clients Õenforce the discipline of using concrete, understandable models (e.g., use cases)
Technological Risks zDangers ÕUnexplored software tools or techniques ÕLack of alternatives zDealing with the risks Õobtain necessary resources Õbuild working prototypes Õtest integration capabilities (arch design) Õidentify alternatives
Your consent to our cookies if you continue to use this website.