Download Overview of Software Estimation, Project Management: COSMIC, FPA, Agile - Prof. Boka and more Cheat Sheet Software Project Management in PDF only on Docsity!
UNIT-2 (Lecture-6)
Software estimation: COSMIC Full function points
Function Point Analysis (FPA) is one of the most widely used methods to determine the size of software projects. FPA originated at a time when only a mainframe environment was available. Sizing of specifications was typically based on functional decomposition and modeled data. Nowadays, development methods like Object Oriented, Component Based and RAD are applied more often. There is also more attention on architecture and the use of client server and multitier environments. Another development is the growth in complexity caused by more integrated applications, real‐ time applications and embedded systems and combinations. FPA was not designed to cope with these various newer development approaches. The Common Software Measurement International Consortium (COSMIC), aimed to develop, test, bring to market and to seek acceptance of a new software sizing method to support estimating and performance measurement (productivity, time to market and quality). The measurement method must be applicable for estimating the effort for developing and maintaining software in various software domains. Not only business software (MIS) but also real time software (avionics, telecom, process control) and embedded software (mobile phones, consumer electronics) can be measured. The basis for measurement must be found, just as in FPA, in the user requirements the software must fulfill. The result of the measurement must be independent of the development environment and the method used to specify these requirements. Sizes depend only on the user require.
COSMIC Concepts
The Functional User Requirements (FUR) are, according to the definition of a functional size measurement method, the basis for measurement. They specify user’s needs and procedures that the software should fulfill. The FUR are analyzed to identify the functional processes. A Functional Process is an elementary component of a set of FUR. It is triggered by one or more events in the world of the user of the software being measured. The process is complete when it has executed all that is required to be done in response to the triggering event. Each functional process consists of a set of sub processes that are either movements or manipulations of data. Since no one knows how to measure data manipulation, and since the aim is to measure ‘data movement rich’ software, the simplifying assumption is made that each functional process consists of a set of data movements. A Data Movement moves one Data Group. A Data Group is a unique cohesive set of data (attributes) specifying an ‘object of interest’ (i.e. something that is ‘of interest’ to the user). Each Data Movement is counted as one CFP (COSMIC function point).
COSMIC recognizes 4 (types of) Data Movements: Entry moves data from outside into the process Exit moves data from the process to the outside world Read moves data from persistent storage to the process Write moves data from the process to persistent storage.
Users of the COSMIC method have reported the following benefits, compared with using '1st generation' methods Easy to learn and stable due to the principles-based approach, hence 'future proof' and cost-effective to implement; Well-accepted by project staff due to the ease of mapping of the method’s concepts to modern software requirements documentation methods, and to its compatibility with modern software architectures; Improves estimating accuracy, especially for larger software projects; Possible to size requirements automatically that are held in CASE tools;
Avoid irrelevant and unreliable estimation information. Use documented data from previous development tasks. Find estimation experts with relevant domain background and good estimation records. Estimate top-down and bottom-up, independently of each other. Use estimation checklists. Combine estimates from different experts and estimation strategies. Assess the uncertainty of the estimate.
Delphi Method:
The aim of Delphi method is to combine expert opinion and prevent bias due to positions, status or dominant personalities. Delphi arranges an especial meeting among the project experts and tries to achieve the true information. Delphi includes some steps as, The coordinator gives an estimation form to each expert. Each expert presents his own estimation (without discussing with others). The coordinator gathers all Forms and sums them up and start another iteration. steps (b-c) are repeated until an approval is gained. Rule Based Systems: Uses human expert knowledge to solve real-world problems that normally would re- quire human intelligence. Expert knowledge is often represented in the form of rules or as data within the Personnel Capability = Low THEN Risk Level = High
Bayesian Belief Network
It is the process of fore- casting the software effort to estimate software costs of both development and maintenance. In the past decades, various kinds of software cost and effort estimation methods have been proposed. However, there is no optimal approach to accurately predict the effort needed for developing a software system. Because, the information gathered at the early stages of software system development is insufficient for providing a precise effort prediction. It is a complex activity that requires knowledge of a number of key attributes. Bundle of data is needed, which is often impossible to get in needed quantities. Hence, Bayesian Belief Networks are effective for cost and effort estimation. BBNs are especially useful when the information about the past and/or the current situation is vague, incomplete, conflicting, and uncertain. They are a very effective method of modeling uncertain situations that depend on cause and effect. They are compact networks of probabilities that capture the probabilistic relationship between variables, as well as historical information about their relation- ships. BBNs are very effective for modeling situations where some information is already known and incoming data is uncertain or partially unavailable. An important fact to realize about Bayesian Belief Networks is that they are not dependent on knowing exact historical information or current evidence.
UNIT-2 (Lecture-4)
Managing interactive processes
Models are defined as explicit representations of some portions of reality as perceived by some actor. A model is active if it influences the reality it reflects; if changes to the representation also change the way some actors perceive reality. Model activation is the process by which a model affects reality. Activation involves actors interpreting the model and adjusting their behavior to it. This process can be Automated , where a software component executes the model, Manual , where the model guides the actions of human actors, or Interactive , where prescribed aspects of the model are automatically interpreted and ambiguous parts are left to the users to resolve, with tool support. Fully automated activation implies that the model must be formal and complete, while manual and interactive activation also can handle informal and evolving models. We define a model to be interactive if it is interactively activated. The process of defining and updating an interactive model is called articulation. In this thesis we are primarily concerned with interactive models of work processes. By altering models of their own work, users can control and customize the behavior of an interactive system. The inter-play of articulation and activation (Figure) keeps the models alive and up to date as resources for learning, coordination and work support. The three engineering challenges (articulation, activation, and reuse) all contribute to increasing the benefits of interactive models and decreasing the efforts and learning required to use the system.
Software estimation
The four basic steps in software project estimation are:
1. Estimate the size of the development product. This generally ends up in either Lines of Code (LOC) or Function Points (FP), but there are other possible units of measure. A discussion of the pros & cons of each is discussed in some of the material referenced at the end of this report. 2. Estimate the effort in person-months or person-hours. 3. Estimate the schedule in calendar months. 4. Estimate the project cost in dollars (or local currency)
What is SCRUM?
SCRUM is an agile development method which concentrates specifically on how to manage tasks within a team based development environment. Basically, Scrum is derived from activity that occurs during a rugby match. Scrum believes in empowering the development team and advocates working in small teams (say- 7 to 9 members).
It consists of three roles, and their responsibilities are explained as follows
Process flow of Scrum
UNIT-2 (Lecture-2)
Software Process Models: Rapid Application Development & Agile Method
Rapid Application Development (RAD) Model
Rapid Application Development model relies on prototyping and rapid cycles of iterative
development to speed up development and elicit early feedback from business users. After each
iteration, developers can refine and validate the features with stakeholders. RAD model is also characterized by reiterative user testing and the re-use of software components. Hence, RAD has
been instrumental in reducing the friction points in delivering successful enterprise applications.
Wave Maker makes use of the RAD model to provide a Rapid Application Development
platform to create web and mobile applications. The following diagram depicts Wave Maker
RAD platform architecture, based on the MVC (Model-View- Controller) pattern. Open
standards, easy customization and rapid prototyping are central to the platform.
Phases in RAD Model: Business Modeling Data Modeling Process Modeling Application Modeling Testing and Turnover
Business Modeling: In this phase of development business model should be designed based on
the information available from different business activities. Before start the development there
should be a complete picture of business process functionality. Data Modeling: Once the business modeling phase over and all the business analysis completed,
all the required and necessary data based on business analysis are identified in data modeling
phase.
Process Modeling: All the data identified in data modeling phase are planned to process or
implement the identified data to achieve the business functionality flow. In this phase all the data
modification process is defined.
In simple terms, in the Agile approach the project will be broken up into 10 releases
(assuming each iteration is set to last 4 weeks).
Rather than spending 1.5 months on requirements gathering, in Agile software
development, the team will decide the basic core features that are required in the product and decide which of these features can be developed in the first iteration.
Any remaining features that cannot be delivered in the first iteration will be taken up in
the next iteration or subsequent iterations, based on priority. At the end of the first iterations, the team will deliver a working software with the
features that were finalized for that iteration.
UNIT-2 (Lecture-1)
Software process and Process Models
Software process
A software process is a set of activities that leads to the production of a software product. These activities may involve the development of software from scratch in a standard programming language like Java or C. Increasingly, however, new software is developed by extending and modifying existing systems and by configuring and integrating off-the-shelf software or system components. Fundamental activities of Software Process: Software specification the functionality of the software and constraints on its operation must be defined. Software design and implementation the software to meet the specification must be produced. Software validation the software must be validated to ensure that it does what the customer wants. Software evolution the software must evolve to meet changing customer needs.
Software process models
A Process Model describes the sequence of phases for the entire lifetime of a product. Therefore it is sometimes also called Product Life Cycle.
List various software process models Waterfall model, Iterative model, Agile model, RAD model etc.
1. Waterfall Model
