11/10/2022 0 Comments Cocomo model scale factors![]() ![]() ![]() Multisite Development - Is the team geographically dispersed? Use of Software Tools - To what degree will the Software Development Life Cycle (SDLC) tools support the project life cycle? Platform Volatility - How often will the platform be updated? Storage Constraint - How much memory of the target will the application require? Time Constraint - How much CPU time of the target will the application require? Language and Toolset Experience - How much experience does the team have with the language and tools? Platform Experience - How much experience does the team have with the target platform? Personnel Capability - How long has the team been working together? (Turnover %?)Īpplication Experience - How much experience does the team have with this type of application? Programmer Capability - How capable are the programmers? Product Complexity - How complex will the software be?ĭeveloped for Reusability - How much reuse is expected after completion?ĭocumentation Match to Lifecycle Needs - How much documentation will be required?Īnalyst Capability - How capable are the analysts on the project? Required Software Reliability - How reliable does the software have to be?ĭatabase Size - How much sample data will be needed to test the software? In addition to the above, the COCOMO outlines software cost drivers covering the product, personnel, platform, and project, as follows: Team Cohesion - How cooperative is the team, including stakeholders? Process Maturity - How mature is your organization? (Use the Software Engineering Institute's Capability Maturity Model.)ĭevelopment Flexibility - How firm are the requirements? Can they evolve? Precedence - How similar is this project to other projects that the same team completed?Īrchitecture - How well is the architecture defined? The COCOMO outlines a set of software scale drivers that attempt to capture some additional effort "amplifiers." The software scale drivers are as follows: The results of the meeting can then be used to estimate SLOCs. The idea is to envision what is outside our daily field of view, capture it as a raw thought, and process the information later. Every input in a brainstorming session is worthy of consideration. The team attempts to identify each application/class/library/configuration file to be developed, reused, or modified, and writes it down as a note. One approach is to assemble a team for a brainstorming session, ideally without cell phones, ipads, or laptops, but with a well-stocked pantry of snacks and beverages, a pile of sticky notes, and a large blank wall or table (see "Wideband delphi" method). Since requirements are rarely defined adequately at the initial stages, the process of determining how much code needs to be written is predominantly a RIGHT-brained activity the creative side of our minds. Estimating size requires expertise from the developers who will be writing the code. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |