Specialized process model
There are 4 types of Specialized process model :
1.5 SPECIALIZED PROCESS MODELS.
Special process models take on many of the characteristics of one or more of the conventional models. However, specialized models tend to be applied when a narrowly defined software engineering approach is chosen.
1.5.1 COMPONENT-BASED DEVELOPMENT. Commercial off-the-shelf (COST) software components, developed by vendors who offer them as products, can be used when software is to be built. These components provide targeted functionality with well-defined interfaces that enable the component to be integrated into the software. The component-based development model incorporates many of the characteristics of the spiral model. It is evolutionary in nature, demanding an iterative approach to the creation of software. However, the model composes applications from prepackaged software components. Modeling and construction activities begin with the identification of candidate components. These components can be designed as either conventional software modules or object-oriented classes or packages of classes. Regardless of the technology that is used to create the components, the component-based development model incorporates the following steps (implemented using an evolutionary approach):
• Available component-based products are researched and evaluated for the application domain in question. http://wikistudent.ws/Unisa
• Component integration issues are considered.
• A software architecture is designed to accommodate the components.
• Components are integrated into the architecture.
• Comprehensive testing is conducted to ensure proper functionality. The component-based development model leads to software reuse, and reusability provides software engineers with a number of measurable benefits. Based on studies of reusability component-based development can lead to reduction in development cycle time, reduction in project cost and increase in productivity. Although these results are a function of the robustness of the component library, there is little question that the component-based development model provides significant advantages for software engineers.
1.5.2 THE FORMAL METHODS MODEL. The formal methods model encompasses a set of activities that leads to formal mathematical specification of computer software. Formal methods enable a software engineer to specify, develop, and verify a computer-based system by applying rigorous, mathematical notation. A variation on this approach is called clean-room software engineering. When formal methods are used during development, they provide a mechanism for eliminating many of the problems that are difficult to overcome using other software engineering paradigms. Ambiguity, incompleteness, and inconsistency can be discovered and corrected more easily, not through ad hoc review, but through the application of mathematical analysis. When formal methods are used during design, they serve as a basis for program verification and therefore enable the software engineer to discover and correct errors that might otherwise go undetected. Although not a mainstream approach, the formal methods model offers the promise of defect-free software. Yet, concern about its applicability in a business environment has been voiced:
• The development of formal models is currently quite time-consuming and expensive.
• Because few software developers have the necessary background to apply formal methods, extensive training is required.
• It is difficult to use the model as a communication mechanism for technically unsophisticated customers.
1.5.3 ASPECT-ORIENTED SOFTWARE DEVELOPMENT.
Regardless of the software process that is chosen, the builders of complex software invariably implement a set of localized features, functions and information content. These localized software characteristics are modeled as components and then constructed within the context of a system architecture. As modern computer-based systems become more sophisticated and complex, certain concerns, customer required properties or areas of technical interest, span the entire architecture. Some concerns are high-level properties of a system; others affect functions or are systemic. When concerns cut across multiple system functions, features, and information they are often referred to as crosscutting concerns. Aspectual requirements define those crosscutting concerns that have impact across the software architecture. Aspects are mechanisms beyond subroutines and inheritance for localizing the expression of a crosscutting concerns. Aspect-oriented software development (AOSD), often referred to as aspect-oriented programming (AOP), is a relatively new software engineering paradigm that provides a process and methodological approach for defining, specifying, designing, and constructing aspects. http://wikistudent.ws/Unisa A distinct aspect-oriented process has not yet matured. However, it is likely that such a process will adopt characteristics of both the spiral and concurrent process models. The evolutionary nature of the spiral is appropriate as aspects are identified and then constructed. The parallel nature of concurrent development is essential because aspects are engineered independently of localized software components and yet, aspects have a direct impact on these components.
1.6 THE UNIFIED PROCESS.
In some ways the unified process (UP) is an attempt to draw on the best features and characteristics of conventional software process models, but characterize them in a way that implements many of the best principles of agile software development. The unified process recognizes the importance of customer communication and streamlined methods for describing the customer’s view of a system. It emphasizes the important role of software architecture and helps the architect focus on the right goals, such as understandability, reliance to future changes, and reuse. It suggests a process flow that is iterative and incremental, providing the evolutionary feel that is essential in modern software development.
1.1 PRESCRIPTIVE MODELS OR CONVENTIONAL MODELS. Every software engineering organization should describe a unique set of framework activities for the software processes it adopts. It should populate each framework activity with a set of software engineering actions, and define each action in terms of a task set that identifies the work (and work products) to be accomplished to meet the development goals. It should then adapt the resultant process model to accommodate the specific nature of each project, the people who will do the work and the environment in which the work will be conducted. Regardless of the process model that is selected, software engineers have traditionally chosen a generic process framework that encompasses the following framework activities:
• Communication – This framework activity involves heavy communication and collaboration with the customer (and other stakeholders) and encompasses requirements gathering and related activities. • Planning – This activity establishes a plan for the software engineering work that follows. It describes the technical tasks to be conducted, the risks that are likely, the resources that will be required, the work products to be produced, and a work schedule.
• Modeling – this activity encompasses the creation of models that allow the developer and the customer to better understand software requirements and the design that will achieve those requirements.
• Construction – This activity combines code generation (either manual or automated) and the testing that is required to uncover errors in the code.
• Deployment – The software (as a complete entity or as a partially completed increment) is delivered to the customer who evaluates the delivered product and provides feedback based on the evaluation. We call these models prescriptive because they prescribe a set of process elements namely framework activities, software engineering actions, tasks, work products, quality assurance and change control mechanisms for each project. Each process model also prescribes a workflow that is, the manner in which the process elements are interrelated to one another. All software process models can accommodate the generic framework activities, but each applies a different emphasis to these activities and defines a workflow that invokes each framework activity (as well as software engineering actions and tasks) in a different manner.
