Abstract

Continuous Business Process Improvement (BPI) is necessary in order to maintain and develop the enterprise competitiveness. Yet, achieving a level of software development performance that matches needs in terms of producing noticeable results within small amounts of time is a persnickety task, mainly because most available methodologies do not deliver full software architectures that can be directly used for in-house software development without iterations between implementation and design, as produced specifications are too close to the user interface, or too close to business rule and domain. Our approach applies a method that structures business processes, business rules and domain concepts, and uses this information in order to identify user tasks (use cases), and by means of their detail, methodically specify the final architecture for a particular BPI, bridging business and software using cross-consistent concepts. We provide an example and the theoretical validation of our approach.

Recommended Citation

Valente, P.D., Silva, T.R., Winckler, M.A, & Nunes, N. (2016). The Goals Approach: Agile Enterprise Driven Software Development. In J. Gołuchowski, M. Pańkowska, C. Barry, M. Lang, H. Linger, & C. Schneider (Eds.), Information Systems Development: Complexity in Information Systems Development (ISD2016 Proceedings). Katowice, Poland: University of Economics in Katowice. ISBN: 978-83-7875-307-0. http://aisel.aisnet.org/isd2014/proceedings2016/ISDevelopment/7.

Paper Type

Event

Share

COinS
 

The Goals Approach: Agile Enterprise Driven Software Development

Continuous Business Process Improvement (BPI) is necessary in order to maintain and develop the enterprise competitiveness. Yet, achieving a level of software development performance that matches needs in terms of producing noticeable results within small amounts of time is a persnickety task, mainly because most available methodologies do not deliver full software architectures that can be directly used for in-house software development without iterations between implementation and design, as produced specifications are too close to the user interface, or too close to business rule and domain. Our approach applies a method that structures business processes, business rules and domain concepts, and uses this information in order to identify user tasks (use cases), and by means of their detail, methodically specify the final architecture for a particular BPI, bridging business and software using cross-consistent concepts. We provide an example and the theoretical validation of our approach.