Component Driven Approach to Overcome The Challenges in Software Development Process

Published on November 2016 | Categories: Documents | Downloads: 50 | Comments: 0 | Views: 158
of 5
Download PDF   Embed   Report

https://sites.google.com/site/journalofcomputing/volume-2-issue-8-august-2010In software process models, focus is on the activities directly related to development of software, such as requirement analysis, design, coding and testing. As the software process models play a vital role in software development, it really forms the core of the software product. Various software process models are proposed till now but the high failure rate in software development has shown the need of new approach. This paper will present a new approach of software process model, which deals with the various issues like changing requirements, quality, cost and time. This approach also helps in managing each phase more efficiently.

Comments

Content

JOURNAL OF COMPUTING, VOLUME 2, ISSUE 8, AUGUST 2010, ISSN 2151-9617 HTTPS://SITES.GOOGLE.COM/SITE/JOURNALOFCOMPUTING/ WWW.JOURNALOFCOMPUTING.ORG

38

Component Driven Approach to Overcome The Challenges in Software Development Process
Rupinder Kaur, Jyotsna Sengupta
Abstract—In software process models, focus is on the activities directly related to development of software, such as requirement analysis, design, coding and testing. As the software process models play a vital role in software development, it really forms the core of the software product. Various software process models are proposed till now but the high failure rate in software development has shown the need of new approach. This paper will present a new approach of software process model, which deals with the various issues like changing requirements, quality, cost and time. This approach also helps in managing each phase more efficiently. Index Terms— Component driven development approach, development process model, stage model, process model.

——————————  ——————————

1 INTRODUCTION
O solve actual problems in an industry setting, a software engineer or a team of engineers must incorporate a development strategy that encompasses the process, methods, and tools layers. This strategy is often referred to as a process model. Process models specifies a general process, usually as a set of stages in which a project should be divided, the order in which the stages should be executed and any other constraints and condition on execution of stages. Several process models exist to streamline the development process, which provides the framework to aid the software development. Software product quality results from a combination of factors involving not only the product being developed but also the process that develops that product [14]. As Jaccheri observe, software processes are highly complex activities that affect critical factors such as final product quality, time and costs, so process control is essential [12]. Software engineering is seen as a fixed, standardized discipline that evolves slowly, and a view which is often reflected in the repetitious or redundant character of recent software engineering methods. One technique to improve the effectiveness of software engineering would be to ensure that it dynamically adapts to change. Tracking and monitoring change would then become essential components of software engineering. An adaptive response to dynamic requirements that adjusts according to changing environments can lead to a better solution, which is lacking in present software process models. This leads us to introduce the new software process model, which is based on dynamic design specification and development and scope for dynamic testing during software development process. This ap-

T

proach is totally unlike CBSD (Component Based Software Development) which is based on pre-built, standardize software components. The new approach provides the ground for new software development life cycle model, which while implementing proven engineering techniques. This will limit all the software development risks to a component only, and provide the firmer control over software development process. The remainder of the paper is organized as follows: Section II discuss existing models and techniques, Section III presents new software process model, which will handle dynamic requirements efficiently and has controller to listing the details of components which are added due to requirement changes or because of new requirements. In Section IV we conclude and put forward the future work directions.

2 BACKGROUND WORK

There are various different methods and techniques used to direct the life cycle of a software development project. The most influencing and initial process model was Waterfall Model. It follows the linear sequence to software development that begins at the system level and progresses through analysis, design, coding, testing, and support. The Waterfall Model was widely used because it formalized certain elementary process control requirements. But it was not without problems, shortcomings of the Waterfall Model included its lack of risk assessment, fixed requirement, slow or unresponsive structure, and its inadequacy for object orientation. Later the German defense organization introduced a modified version of the Waterfall in 1992 called the V-Shaped Model. This model ———————————————— included validation and verification processes by asso F.A. Rupinder is pursuing PhD in Computer Science, Department of ciating testing activities with the analysis and design Computer Science, Punjabi University Patiala.  S.B. Jyotsna Sengupta is working with the Department of Computer phases [5]. This model had higher chance of success over the Waterfall Model due to the development of the test Science, Punjabi University Patiala.
© 2010 Journal of Computing Press, NY, USA, ISSN 2151-9617 http://sites.google.com/site/journalofcomputing/

JOURNAL OF COMPUTING, VOLUME 2, ISSUE 8, AUGUST 2010, ISSN 2151-9617 HTTPS://SITES.GOOGLE.COM/SITE/JOURNALOFCOMPUTING/ WWW.JOURNALOFCOMPUTING.ORG

39

plan but was very inflexible like Waterfall Model. Then, demand for new method of developing system leads to iterative development, in which project was divided into small parts. Prototyping Model helps to understand uncertain requirements but leads to false expectations and poorly designed system. A popular variation of the Prototyping Model is called Rapid Application Development (RAD). This model introduces firm time limits on each development phase and relies heavily on rapid application tools which allow for quick development [9]. Exploratory model use the prototyping as a technique for gathering requirements and was very simple in its construction but is limited with high level language for rapid development. Lichter observed that prototyping reflects an evolutionary view of software development [6]. It is closely related to incremental development except that, in prototyping, the development phase turn-around time is reduced by the quick development of a primitive version of the product. A number of Process Models evolved from the Iterative enhancement (evolutionary) approach. They are characterized in a manner that enables software engineers to develop increasingly more complete versions of the software. The incremental model combines elements of the linear sequential model with the iterative philosophy of prototyping. The incremental model applies linear sequences in a staggered fashion as time progresses. Each linear sequence produces a deliverable “increment” of the software [10]. Boehm proposed the Spiral Model, which provides the potential for rapid development in a series of incremental releases [2]. Risk analysis, which identify situations that might cause a development effort to fail or go over budget, occurs during each spiral cycle. In the course of several papers, Boehm and his colleagues extended the spiral model to a variant called the Win–Win Spiral Model [2], [3], [4]. The win–win stakeholder approach is used to determine three critical project milestones that together anchor the development of the project: namely, life-cycle objectives, life-cycle architectures, and initial operational capability [1]. Agile process model give less stress on analysis and design. Implementation begins much early in the life cycle of the software development. This process model demands fixed time. Extreme Programming (XP) was created by Kent Beck during software development, and is based on iterative enhancement model. Like other agile software development, XP attempts to reduce the cost of change by having multiple short development cycles, rather than one long one. It only works on teams of twelve or fewer people [11]. Industrial Extreme Programming (IXP) was introduced as an evolution of XP. It is intended to bring the ability to work in large and distributed teams. It then supported flexible values [8]. There is not enough data to prove its usability. These days, majority of the software development project involve some level of reuse of existing artifact like design or code modules. The component-based development (CBD) model incorporates many of the characteristics of the spiral model. It is evolutionary in nature, demanding an iterative approach to the creation of software [13]. The

component-based development model leads to software reuse, and reusability provides software engineers with a number of measurable benefits. The unified software development process is representative of a number of component-based development models that have been proposed. Using a combination of iterative and incremental development, the unified process defines the function of the system by applying a scenario-based approach [7].The concentration is on object oriented development. The literature has shown that engineers, researchers and practitioners are still using the traditional process models or combination of best features of different process models. But to manage the concern and challenges of modern world, no approach or model for effective software development is explicitly defined.

3 FUSION PROCESS MODEL
Fusion process model is based on component driven development approach, where each component implements a problem solving model. It includes the explicit processes for technically analyzing the problem, solution space analysis, alternative management, dynamic design specification and development and scope for dynamic testing. It implements the 3C-Model [15] on each stage or phase, which assist fusion process model in generalizing the process of solving the problems in each stage. It implements component based development approach, which provides a dynamic nature to complete software development. Since it is component driven approach, the risk associated with cost and time will be limited to component only and ensure the overall quality of software system, reduce the development cost and time by considering the changing requirements of customer, risk assessment, identification, evaluation and composition of relative concerns at each phase of development process. The 3C-Model for each stage helps in mapping the real world problems or requirement with technical problems, and providing the best available alternative with the help of complete background information gathered and controlled using process like solution space analysis, mathematical models and heuristics and optimization techniques. The following section describes the various techniques of implementation model in detail.

4.1 Problem Analysis and Alternate Generation
The control part of 3C-Modle performs this step where it analyzes the actual problem, which arises due to client requirements. This provides an understanding of the client perspective of the software system. The next step involves the technical problem analysis process in which client requirements are mapped to technical problems and solution domain is identified using solution space analysis process. Technical Problem Analysis includes the definition of the problems and the sub problems that need to be solved. In the problem analysis process, technical problems are identified and structured into loosely coupled sub-problems that are first independently solved and later integrated in the overall solution.

JOURNAL OF COMPUTING, VOLUME 2, ISSUE 8, AUGUST 2010, ISSN 2151-9617 HTTPS://SITES.GOOGLE.COM/SITE/JOURNALOFCOMPUTING/ WWW.JOURNALOFCOMPUTING.ORG

40

Extracting requirements of a desired software product is the first task in creating it. This process is called requirements elicitation. While customers probably believe they know what the software should do, it may require skill and experience in software engineering to recognize incomplete, ambiguous or contradictory requirements. Requirement analysis process provides an understanding of the client perspective of the software system. After requirements elicitation, client requirements are mapped to technical problems in the technical problem analysis process. The problem analysis process consists of the following steps: 1. Generalize the Requirements: whereby the requirements are abstracted and generalized. 2. Identify the Sub-Problems: whereby technical problems are identified from the generalized requirements. 3. Specify the Sub-Problems: whereby the overall technical problem is decomposed into sub-problems. 4. Prioritize the Sub-Problems: whereby the identified technical problems are prioritized before they are processed. Problem reduction is a strategic approach to manage complexity. A widely known method for solving large and complex problems is to split them into simpler problems and then iteratively apply this process. The process is put into action until the sub-problems are reduced to a level of complexity at which they are easily solved or at least exhibit an irreducible level of difficulty. This paradigm for solving problems is called problem reduction. In this, a problem in a given domain is decomposed into a structured set of sub-problems in the same domain. Each sub-problem is evaluated for suitability to be further decomposed until each sub-problem is determined solvable. This problem reduction paradigm has been successfully applied to problems in a variety of application domains and in many phases of the process in which a top-down decision making strategy is applicable. The problem reduction can be expensive if not handled properly. Often, the same process must be done repeatedly for a similar type of problem with only minor differences. As a result, problem reduction may cost even more over time as problems become more complex. One important approach of handling the side effects of problem reduction is to build reusable sub-problems and solutions, instead of continually reinventing a related system reductive hierarchy. Such reusable sub-problems and solutions can be stored in a components library and retrieved as required. Complete solutions can then be obtained by using and reassembling appropriate sub-solution components. The capture part of 3C-Model consist these concepts: Need, Problem Description, Solution Domain Knowledge, Alternative, Solution Description and Artifact.   Need represents an unsatisfied situation existing in the context (environment). Problem Description represents the description of the

   

problem. Solution Domain Knowledge represents the background information that is used to solve the problem. Alternative represents the possible alternative solutions. Solution Description represents a feasible solution for the given problem. Artifact represents the solution for the given need.

4.2 Solution Domain and Alternate Space Analysis
Solution Domain represents the background information that is used to solve the problem and alternative space represents the possible alternative solutions. It includes the search for the solution space, and the complete background information required to solve the problems. In the solution space analysis process, requirements are specified using some representation and this should be refined along the software development process until the final software is delivered. The Solution Domain Analysis process applied in software design phase aims to provide a solution domain model that will be utilized to extract the architecture design solution. It consists of the following activities: 1. Identify and prioritize the solution domains for each sub-problem 2. Identify and prioritize knowledge sources for each solution domain. 3. Extract solution domain concepts from solution domain knowledge. 4. Structure the solution domain concepts. 5. Refine the solution domain concepts. The alternative space includes the alternative generation and alternative evaluation of the defined solutions. This can be defined as a set of possible design solutions that can be derived from a given conceptual software architecture. The alternative design space analysis aims to depict this space and consists of the two sub-processes: define the alternatives for each concept and describe the constraints. Let us now explain these sub-processes in more detail.  Define the Alternatives for each Concept- In this approach the various architecture design alternatives are derived from well-established concepts in the solution domain that have been leveraged to the identified technical problems. Describe the Constraints - The total set of alternatives per concept may be too large and/or not relevant for solving the identified problems. Therefore, to define the boundaries of the architecture it is necessary to identify the relevant alternatives and omit the irrelevant ones.



4.3 Development Process Control
The development process in software engineering starts with the need, while the goal is to arrive at an artifact

JOURNAL OF COMPUTING, VOLUME 2, ISSUE 8, AUGUST 2010, ISSN 2151-9617 HTTPS://SITES.GOOGLE.COM/SITE/JOURNALOFCOMPUTING/ WWW.JOURNALOFCOMPUTING.ORG

41

(output) by applying a sequence of actions. Since this may be a complex process, the concepts and functions that are applied are usually controlled. This is represented by the Control part in the model. The controller observes variables from the system, evaluates this against the criteria and constraints, produces the difference, and performs some control actions to meet the criteria.  Mathematical Model represents a description of the concept Alternative.  Quality Criteria represent the relevant criteria that need to be met for the final artifact.  Constraints represent the possible constraints either from the context or as described in Problem Statement.  Heuristics/Optimization Techniques represents the information for finding the necessary actions to meet the criteria and constraints.

state. Every transformation process engages an evaluation step, evaluation of design state with the initial requirements is done and verifies if additional requirements identified during this step. In particular, this process includes an explicit phase for searching design alternatives in the corresponding solution space and selecting these alternatives based on explicit quality criteria. Our work has shown that how this approach helps in controlling the overall development process by implementing component based approach. Since it is component driven approach, the threat tied with cost and time will be restricted to component only, ensuring the overall quality of software product, considering the changing requirement of customer, risk assessment, identification, evaluation and composition of relative concerns at each phase of development process.

REFERENCES
4.4 Software Development Scope
Both the control and the problem-solving activities take place in a particular context. Context can be expressed as the environment in which software development takes place including a broad set of external constraints that influence the final solution and the approach to the solution. Constraints are the rules, requirements, relations, conventions, and principles that define the context of software engineering, that is, anything, which limits the final solution. Since constraints rule out alternative design solutions directing engineers into taking action on what is doable and feasible. The context also defines the need and may be very wide and include different aspects like the engineer’s experience and profession, culture, history, and environment.
[1] Barry Boehm, “Anchoring the Software Process”, IEEE Transaction on Software Engineering, pp. 79-82, July 1996. [2] B.Boehm, “A Sprial Model of Software Development and Enhancement”, IEEE Computer, Volume 21, Issue 5, pp. 61-72, 1988. [3] B.Boehm and D.Port, “Escaping the software tar pit: model clashes and how to avoid them”, Software Engineering Note, Volume 24, Issue 1, pp. 3648, 1999. [4] B.Boehm and P.Bose, “A Collaborative Spiral Software Process Model Based on Theory W.Processing of ICSP”, 3, New York: IEEE Press, 1994. [5] Fadi P. Deek, James A.M. McHugh and Osama M. Eljabiri, “Strategic Software Engineering an Interdisciplinary Approach”, Auerbach Publications, pp. 11-35, 2005. [6] H.Lichter, M Hufschmidt Schneider,and H. Zullighoven, “Prototyping in industrial software projects”, IEEE Trans. Software Eng., 20(11), pp. 825–832, 1994. [7] I. Jacobson, G. Booch, and J. Rumbaugh, “The Unified Software Development Process”, Addison-Wesley, 1999. [8] Joshua Kerievsky, “Industrial XP: Making XP Work in Large Organizations”, vol. 6, issue 2, Cutter Consortium Agile Product and Project Management. [9] J. Martin, “Rapid Application Development”, Prentice-Hall Publication, 1991. [10] J. McDermid and P. Rook, “Software Development Process Models,” in Software Engineer’s Reference Book, CRC Press, pp. 15/26–15/28, 1993. [11] Kent Beck, “Extreme Programming Explain: Embrace Change”, Addison-Wesley, First Edition-1999, Second Edition- 2004. [12] M.L.Jaccheri,G.P. Picco, and P. Lago, (1998). Eliciting software process models with the E3 language. ACM Trans. Software Eng. Methodol, Volume7, Issue 4, pp. 368–410, 1998. [13] O.Nierstrasz, S. Gibbs, and D. Tsichritzis, “Component-Oriented Software Development,” CACM, vol. 35, no. 9, pp. 160–165, September 1992. [14] R.S.Pressman, “Software Engineering: a Practitioner’s Approach”, McGraw–Hill Publication, Fourth Edition, 1996. [15] Rupinder Kaur and Jyotsna Sengupta, “Development and Analysis of 3C-Model for Software Development Lifecycle”, IEEE 2nd International Conference on Computer Engineering and Technology (ICCET 2010), Volume 6, April 16 -18, Chengdu, China, 2010.

4.5 Domain Engineering
The phased model use domain analysis to identify domains, bounding them, and discovering commonalities and variability’s among the systems. This information is captured in models that are used in the domain implementation phase to create artifacts such as reusable components, a domain-specific programming language, or application generators that can be used to build new systems in the domain. A key idea in systematic software reuse is the domain, a software area that contains systems sharing commonalities.

4

CONCLUSION

We have presented a Fusion Process Model for software development process and discussed the concept of 3CModel for each phase of development process model. In this approach transformation of a problem specification to a solution is made by decomposing the problem into sub-problems that are independently solved and integrated into an overall solution. This process consist of multiple cycles, were each cycle transform from problem specification state to design state. After each state transformation, a sub-problem is solved and a new subproblem possibly be added to the problem specification

JOURNAL OF COMPUTING, VOLUME 2, ISSUE 8, AUGUST 2010, ISSN 2151-9617 HTTPS://SITES.GOOGLE.COM/SITE/JOURNALOFCOMPUTING/ WWW.JOURNALOFCOMPUTING.ORG

42

  Project  Preparation 

  Software  Blueprint 

Realization 

Testing 

  Go Live and  Support 

Fusion Process Controller
Fig. 1. Fusion Process Model

Sponsor Documents

Or use your account on DocShare.tips

Hide

Forgot your password?

Or register your new account on DocShare.tips

Hide

Lost your password? Please enter your email address. You will receive a link to create a new password.

Back to log-in

Close