![]() | This article has multiple issues. Please help improve it or discuss these issues on the talk page . (Learn how and when to remove these template messages)
|
Methodology to evaluate complexity and cost of developing and maintaining application software for creating information systems (Method CETIN) - this is an algorithmic model assessment value software, developed by a consortium of Kazakh IT companies: Kazakhstan Association of IT-companies Company System Studies "Factor" and JSC "National Information Technologies. Method allows assessment of complexity and cost of development of [software] in the early stages and is based on an assessment of the functional size of software.
The first edition of the Kazakh techniques appeared in 1994 as in "Methods of assessing complexity of information systems of the Ministry of Finance of the Republic of Kazakhstan". The principal method was based on the standardization work on a project (the creation of the queue system, the development and implementation of the project functional complex tasks, linking projects, project monitoring, the use of a PC for debugging and commissioning). The disadvantages were the methods use the principle of a cascade model of the software lifecycle and experience of a single developer.
In 2005 in NIT with Research Institute of Economy and Informatization of transport, telecommunications have developed a "methodology to assess the complexity and cost of developing and maintaining information systems." The method was based on 2005 edition of evaluating the functional size of a model of UML-diagrams of the information system, assessment of functional complexity of the size and development time estimates based on the model COCOMO. The main drawback of techniques, from whom she has not received Shirokova distribution is that technique was not adopted as a single regulatory document cost estimates for public IP razrabokti organmov. Another drawback was the lack of research on the collection of statistical databases based on IT development in Kazakhstan to confirm the partial adjustment factors.
In early 2010 and were re-work continued to refine techniques. Then at the second congress of IT-companies of Kazakhstan in the report Gabbasov M Pustovoitenko V have been identified requirements for the new version of the Methodology.
Work continued on methods companies JSC "National Information Technologies, Kazakhstan Association of IT-companies and Company System Studies "Factor". Reworked version techniques presented in August 2011 as well.
Procedure for evaluating the development of middleware complexity represented by the following steps: 1. Evaluation of the functional size of the developed IP; 2. Assessment of the basic design complexity of the PES; 3. Determining the values of correction factors labor development and maintenance of fire suppression; 4. Calculation of complexity, taking into account the development of the PES adjustment factors; 5. Estimation of the development of middleware; 6. Adjustment of labor in developing middleware reduction of development; 7. Assessment of the cost of developing the middleware.
Evaluation of the functional size of the IP is based on a model of information system and functional requirements of users. Functional size of IP given by a set of five elements, each element of which is the appropriate functional unit. Functional units:
Functional size is designated - SIZE = {C, E, T, I, N}
Basic complexity of software development is based on the evaluation of complexity of each software development process. As the development processes used by the process model Rational Unified Process. Basic labor Sj development process with index j is calculated as follows: Sj = 1 / 165 • [C * Sj (C) + E * Sj (E) + T * Sj (T) + I * Sj (I) + N * Sj (N) Calculation made on the basis of the regulatory complexity of factors.
Determining the values of correction factors for each development process is based on frequent adjustment factors characterizing the information system, the scope of its use and development process. Application of correction factors can improve the assessment data are available on an information system.
On the basis of correction factors to the complexity of developing middleware complexity calculation is done taking into account the development of the PES adjustment factors.
Estimation of the development of an information system is on the basis of the values that are defined on the basis of a mathematical model based development time with teamwork.
In the case of reducing the period of development defined in the previous section uses a method of adjusting labor input software, which is determined by the elasticity of difficulty.
The cost of software development is calculated as the product of the complexity of software development at the flat rate of person-months by the authorized body for the planning period.
Project management is the process of leading the work of a team to achieve all project goals within the given constraints. This information is usually described in project documentation, created at the beginning of the development process. The primary constraints are scope, time, and budget. The secondary challenge is to optimize the allocation of necessary inputs and apply them to meet pre-defined objectives.
An embedded system is a computer system—a combination of a computer processor, computer memory, and input/output peripheral devices—that has a dedicated function within a larger mechanical or electronic system. It is embedded as part of a complete device often including electrical or electronic hardware and mechanical parts. Because an embedded system typically controls physical operations of the machine that it is embedded within, it often has real-time computing constraints. Embedded systems control many devices in common use. In 2009, it was estimated that ninety-eight percent of all microprocessors manufactured were used in embedded systems.
A prototype is an early sample, model, or release of a product built to test a concept or process. It is a term used in a variety of contexts, including semantics, design, electronics, and software programming. A prototype is generally used to evaluate a new design to enhance precision by system analysts and users. Prototyping serves to provide specifications for a real, working system rather than a theoretical one. Physical prototyping has a long history, and paper prototyping and virtual prototyping now extensively complement it. In some design workflow models, creating a prototype is the step between the formalization and the evaluation of an idea.
Automotive engineering, along with aerospace engineering and naval architecture, is a branch of vehicle engineering, incorporating elements of mechanical, electrical, electronic, software, and safety engineering as applied to the design, manufacture and operation of motorcycles, automobiles, and trucks and their respective engineering subsystems. It also includes modification of vehicles. Manufacturing domain deals with the creation and assembling the whole parts of automobiles is also included in it. The automotive engineering field is research intensive and involves direct application of mathematical models and formulas. The study of automotive engineering is to design, develop, fabricate, and test vehicles or vehicle components from the concept stage to production stage. Production, development, and manufacturing are the three major functions in this field.
The Constructive Cost Model (COCOMO) is a procedural software cost estimation model developed by Barry W. Boehm. The model parameters are derived from fitting a regression formula using data from historical projects.
Software maintenance in software engineering is the modification of a software product after delivery to correct faults, to improve performance or other attributes.
Software prototyping is the activity of creating prototypes of software applications, i.e., incomplete versions of the software program being developed. It is an activity that can occur in software development and is comparable to prototyping as known from other fields, such as mechanical engineering or manufacturing.
In the context of software engineering, software quality refers to two related but distinct notions:
The term process model is used in various contexts. For example, in business process modeling the enterprise process model is often referred to as the business process model.
Cost estimation in software engineering is typically concerned with the financial spend on the effort to develop and test the software, this can also include requirements review, maintenance, training, managing and buying extra equipment, servers and software. Many methods have been developed for estimating software costs for a given project.
SEER for Software (SEER-SEM) is a project management application used to estimate resources required for software development.
The function point is a "unit of measurement" to express the amount of business functionality an information system provides to a user. Function points are used to compute a functional size measurement (FSM) of software. The cost of a single unit is calculated from past projects.
In software engineering, structured analysis (SA) and structured design (SD) are methods for analyzing business requirements and developing specifications for converting practices into computer programs, hardware configurations, and related manual procedures.
Legacy modernization, also known as software modernization or platform modernization, refers to the conversion, rewriting or porting of a legacy system to modern computer programming languages, architectures, software libraries, protocols or hardware platforms. Legacy transformation aims to retain and extend the value of the legacy investment through migration to new platforms to benefit from the advantage of the new technologies.
Software sizing or software size estimation is an activity in software engineering that is used to determine or estimate the size of a software application or component in order to be able to implement other software project management activities. Size is an inherent characteristic of a piece of software just like weight is an inherent characteristic of a tangible material.
Programming productivity describes the degree of the ability of individual programmers or development teams to build and evolve software systems. Productivity traditionally refers to the ratio between the quantity of software produced and the cost spent for it. Here the delicacy lies in finding a reasonable way to define software quantity.
In software development, effort estimation is the process of predicting the most realistic amount of effort required to develop or maintain software based on incomplete, uncertain and noisy input. Effort estimates may be used as input to project plans, iteration plans, budgets, investment analyses, pricing processes and bidding rounds.
In software engineering, a software development process or software development life cycle (SDLC) is a process of planning and managing software development. It typically involves dividing software development work into smaller, parallel, or sequential steps or sub-processes to improve design and/or product management. The methodology may include the pre-definition of specific deliverables and artifacts that are created and completed by a project team to develop or maintain an application.
Use case points is a software estimation technique used to forecast the software size for software development projects. UCP is used when the Unified Modeling Language (UML) and Rational Unified Process (RUP) methodologies are being used for the software design and development. The concept of UCP is based on the requirements for the system being written using use cases, which is part of the UML set of modeling techniques. The software size (UCP) is calculated based on elements of the system use cases with factoring to account for technical and environmental considerations. The UCP for a project can then be used to calculate the estimated effort for a project.
SNAP is the acronym for "Software Non-functional Assessment Process," a measurement of the size of the software derived by quantifying the non-functional user requirements for the software. The SNAP sizing method complements ISO/IEC 20926:2009, which defines a method for the sizing of functional software user requirements. SNAP is a product of the International Function Point Users Group (IFPUG), and is sized using the “Software Non-functional Assessment Process (SNAP) Assessment Practices Manual” (APM) now in version 2.4. Reference “IEEE 2430-2019-IEEE Trial-Use Standard for Non-Functional Sizing Measurements,” published October 19, 2019. Also reference ISO standard “Software engineering — Trial use standard for software non-functional sizing measurements,”, published October 2021. For more information about SNAP please visit YouTube and search for "IFPUG SNAP;" this will provide a series of videos overviewing the SNAP methodology.