Software Engineering Techniques for Service-Based Development - Research Paper Example

Software engineering techniques for service-based development Introduction In the modern world, Software has evolved to encompass nearly every realm of our daily lives. In fact, software development and programming is no longer confined to the mere writing of code. The growing complexity of software, wider specifications and the collaborative need for a large number of software developers has resulted in a paradigm shift in the manner in which software is developed and managed today. Issues such as efficiency, cost, quality and infrastructure maintenance have become critical elements in ascertaining the success of software systems (Hofmeister, 2009). All these factors have contributed to the rise of ‘Software Engineering’ as a unique and distinct domain within computer science. The primary objective of software engineering is to realize all the above-mentioned objectives by ensuring the delivery of qualitative software that conform to all user requirements and which are developed on schedule within the allocated budget. Realizing this objective is not only dependent on improving quality of the final product, but also depends immensely on the nature of the entire process that is utilized in developing the software system (Bergenti, 2004). 1.1 Definition Zualkernan (2008) defined the term ‘Software Engineering’ as the use and development of efficient engineering principles in order to develop reliable and economically feasible software systems that are capable of running properly on actual machines. Alternatively, Choren (2005) defined software engineering as the development of quality software through a well-defined process that is delivered within the constraints of budget and time while fulfilling all requirements specified by the end users. While initial focus in software development was over quality considerations, the trend is now shifting gradually towards efficient maintenance and delivery within the budget owing to the rising costs of maintaining and upgrading software. 2. Literature Review 2.1 Brief history The evolution of software as an industry can be segregated into four main generations (1950 - 1965, 1965 - 1980, 1980 - 1985, 1985 - present) (Bergenti, 2004). With each generation, the complexity of software has increased tremendously while the size of hardware has reduced significantly in a similar fashion. During the first two generations, software engineering practices were far from efficient due to a lack of proper standards. Increase in the creation and use of software against the lack of established frameworks degraded people’s confidence in the industry leading to an industry wide crisis during the 1970s (Zualkernan, 2008). Some of the predominant issues that led to issues include the lack of proper techniques or parameters to measure software data, lack of oversight on costs, lack of efficient planning and testing tools that could cope with increasing code complexity, lack of effective risk monitoring and management and deficiencies in code and design review. Since the 1980s, the emphasis of the industry has been towards overcoming these pitfalls through a better assessment and understanding of the inherent development and managerial processes along with the development of better estimation methods (Zualkernan, 2008). Nevertheless, numerous problems continue to exist due to a number of reasons ranging from deficiencies in understanding the engineering methodology to a chaotic procedure in executing the project. Successes in delivering software have often been driven by dedicated efforts on the part of a few individuals within the enterprise. As a solution to these issues, Burback (2009) suggests that the focus of organizations should be on the process since restricting to product development can result in negligence of issues such as performance, scalability and reusability. He further suggests that a process-driven framework to software engineering can facilitate a certain degree of predictability with regards to project parameters and outcomes, thus helping improve control and planning. 2.2 Software requirements specification Merseken (2009) says that it is absolutely necessary to be aware of all functionalities and requirements that the software is supposed to achieve before commencing with actual development. He also observes that may projects either get delayed or do not proceed to completion as the project team begins development without allocating any effort or time to understand the requirements properly. The simplest method to overcome this bottleneck is to prepare some relevant documentation that describes every required aspect and behavior of the system through a combination of descriptions, figures (flow diagrams, architecture diagrams etc.) and charts (Choren, 2005). In fact, Luck (2008) states that this documentation, known as the ‘Software Requirements Specification’ (SRS) must be prepared before the commencement of any design, build or testing of the software system. Besides including detailed description of every required behavior of the system, the SRS includes a number of use cases that specify all known forms of interactions between users and the system. Besides, the SRS also includes technical details such as the programming languages used, the required hardware platforms, data processing methodologies and all other internal workings of the system (Burback, 2009). Additionally, a number of standards and requirements with regards to quality and performance are also specified in the SRS to impose relevant constraints. 2.3 SE techniques & methodologies Kreowski (2005) defines a ‘Software Development Methodology’ (SDM) as the collective procedures, frameworks and policies that facilitate the use of software engineering techniques by a project team. Alternatively, SDM is often referred to as the ‘Software Development Lifecycle’ (SDLC) (Merseke, 2009). The primary issue in choosing the most appropriate methodology lies in the identification of adequate process disciplines that minimize time, cost and effort while allowing the successful delivery of a quality software system. Guelfi (2007) argues that newer SE methods also factor in issues like administrative bottlenecks and developer confidence into the framework of a SDLC. According to him, an SDM should be viewed as a way of identifying and managing risks effectively. One of the simplest ways to achieve this is by examining the historical progress of past projects and learning from them. Davies (2004) states that languages such as the Unified Modeling Language (UML) have helped project managers visualize all perspectives of software development, thereby improving the quality of the ultimate product (Luck, 2008). A reliable SDM is also useful in streamlining the overall process while upholding the integrity and quality of the software system. Every phase in the SDM includes several techniques that provide effective risk management at every stage of the project. 3. SE for service-based development There are a number of methodologies or techniques for developing and managing software. Each technique aims to tackle certain issues pertaining to project management while providing related benefits to all stakeholders. Some of these techniques are discussed below. 3.1 Methodology frameworks 3.1.1 Waterfall The ‘Waterfall’ model for software development is the simplest of most available techniques. In simple terms, the waterfall model helps segment a project into a relevant hierarchy of individual stages or activities as shown below: Fig 1: Waterfall model (Source: Kreowski, 2005) As the above figure demonstrates, the waterfall model implies that each stage within the hierarchy should be performed incrementally before the next step is undertaken. A major deficiency of this model lies in the assumption that all system requirements have bee duly identified and evaluated extensively. Thus, the model relies on some assumptions for the most important phase of software development, ‘Requirements Specification’, which may not always be the case. The model also requires reviews at the conclusion of every stage, which help in decision-making and plans for continuity. Although it provides a sequential methodology for development and reviews, the waterfall model is not considered efficient on account of being slow and inadequate for large and complex projects (Kreowski, 2005). Also, the simpler steps inherent in the model do not provide much clarity and often lead to confusion in its interpretation. 3.1.2 Prototyping A newer SE method known as ‘Prototyping’ gained popularity during the 1990s for helping represent a system based on standard specifications. By way of prototyping, users can get a feel of the system’s behavior and interface (typically a graphical user interface (GUI) at several junctures during the project lifecycle. This helps garner their feedback and incorporate necessary changes to reflect their requirements. Through its two variants (Throwaway and Evolutionary), prototyping is particularly useful in projects depending heavily on user interaction (Guelf, 2007). A regular feedback helps recognize precise inputs and outputs besides facilitating an evaluation of the system’s workflows and resolution of any confusion. Moreover, users become an integral part of the development by way of prototyping and are constantly aware of what to expect from the functionality. This reduces overall time and effort spent in reconfiguring or reengineering the product according to user specifications. However, without proper clarification, prototyping can influence the user to assume that the prototype is a working product (Guelfi, 2007). The project team is responsible for communicating the purpose of a prototype and to differentiate it from the actual product. In other words, the project team should be well trained to incorporate criteria such as scalability and adaptability into the prototype to help it transform into a working and acceptable product. 3.1.3 Rapid application development The Rapid Application Development (RAD) SDM is a recent development in the software industry and focuses on developing applications within a short period of time. Although a quicker development lifecycle helps release products quickly into the market and build upon them in an iterative manner, it nevertheless has a direct impact on performance, features and user interaction. Typical RAD projects have an average lifecycle of around 2-3 months that also involves extensive prototyping (Davies, 2004). Fig 2: Rapid Application Development (Source: Davies, 2004) The RAD approach has several advantages including lesser costs and development times as well as customized application development. However, a focus on faster delivery does impact scalability of existing solutions wherein several features are pushed for incorporation in later versions thus leading to systems with reduced functionality. 3.1.4 Spiral method The spiral method emerged from the waterfall method and relies on the fact that projects can be better developed and managed through a combination of iterative and incremental enhancements. This technique allows a project team to begin from a small standpoint and implement each feature through a series of trials and errors. This facilitates parallel development of various modules of the system in a concurrent manner. The spiral method is followed extensively in the industry owing to the higher degree of parallelism in design, development and testing. The method is also useful since it allows careful planning without putting unnecessary pressures as in the RAD approach (Hofmeister, 2009). This allows careful selection of activities and deliverables for each iterative step in the spiral. Fig 3: Spiral Model (Source: Hofmeister, 2009) 3.2 Agile development ‘Agile Development’ is a collective term used to represent a number of incremental and iterative SDMs. Some of the most common SDMs that fall under the agile family include Scrum, Lean Development, Dynamic Systems Development Method (DSDM), Crystal and Extreme Programming (XP) (Zualkernan, 2008). While each method is different from the others in several ways, all these techniques promote collaboration, adaptability and reengineering through the entire project lifecycle. Fig 4: SCRUM: An Agile methodology (Source: Choren, 2005) The Agile framework is useful in splitting complex requirements or processes into smaller components. This procedure utilizes the least time and does not require elaborate planning. Each individual task is then completed as part of an iteration that usually requires a week to 1 month for realization. For every iteration, the project team carries out a complete SDLC with phases including planning, design, development, testing and integration. At the end of iteration, the concerned stakeholders evaluate the completed functionalities for validation and subsequent improvement (Burback, 2009). This methodology helps minimize risk and facilitates a quick adaptation of all prescribed changes. While each iteration may not qualify the system for final release into the market, the method nevertheless facilitates early identification of various bugs in the system (Merseken, 2009). Most projects that are developed using the agile approach normally undergo several iterations before being considered for market release. 4. Conclusion The preceding sections have discussed some of the most popular software engineering techniques that have been used by the industry over past decades. With growing complexity and rise in the popularity of computers, software systems have grown to such an extent that programs can no longer be written or managed by a single individual. This has necessitated the development of appropriate SDMs, which have evolved over the years. Besides, most of these methodologies have been devised keeping in mind the needs and trends during the related era. Bergenti (2004) says that changes in technology and customer preferences have been the main drivers behind the evolution of newer software engineering methodologies. References Bergenti, F., 2004. Methodologies and software engineering for agent systems: the agent-oriented software engineering handbook. New York: Springer. Burback, R., 2009. Software engineering methodology: the Watersluice. Stanford University. Choren, R., 2005. Software engineering for multi-agent systems III: research issues and practical applications. New York: Springer. Davies, J., 2004. Formal methods and software engineering. New York: Springer. Guelfi, N., 2007. Rapid integration of software engineering techniques. Chicago: McGraw Hill. Hofmeister, C., 2009. Component-Based Software Engineering. London: CRC Press. Kreowski, H., 2005. Formal methods in software and systems modeling. London: Routledge. Luck, M., 2008. Agent-oriented software engineering. New York: Springer. Merseken, S., 2009. Software Development Methodology: Software Engineering, Software Development Process, Information System, Domain-specific Modeling, Lightweight Methodology, Object Modeling Language. Chicago: Betascript Publishers. Zualkernan, I., 2008. New trends in software methodologies, tools and techniques: proceedings of the seventh SoMeT_08. London: IOS Press. Read More