Introduction to Software Engineering

Question: Discuss about the Introduction to Software Engineering. Answer: Software Project Failure There are different factors for which a software project can fail like short time, poor communication, insufficient budget, inadequate testing process, process progress never reviewed, lack of quality assurance, testing the product in live environment, not maintaining standardization, etc. It was found that the software projects that are developed only 16% of them get success and the a major 53% of the software products face challenges like content deficiency, cost overrun, budget failure etc. and the remaining 31% of the projects are discarded. Thus many of the software products in the IT industry face failures and many successful products are built taking ideas from the failed products. In the year 1980 a software product named TAURUS (Transfer and Automated Registration of Uncertificated Stock) was launched for transferring the stock exchange service of London to an automated system (Maas et al. 2016). The software product was launched to reduce the paper works of the stock exchange and thus reduce the cost and time. TAURUS was designed to bring the holdings of the investors of the London Stock Exchange in a centralized database (David and David 2016). All the records of the share holders, investors, market makers, brokers and the peoples associated with London stock exchange was to be stored electronically in the centralized database system. This would reduce the time required for the financial and legal steps that are required for the payment in the share market. TAURAS had small competition in the market but it was launched to manage bigger stock exchange but there was no to the point scope and it resulted in crawling for new scope and more investment cost. The manufacturer, designer and the peoples involved with TAURUS proposed some ideas and designers tried to implement the proposed idea on the live project but it was a failure and it costs a damage of 500 million pounds. TAURUS was discarded in 1993 and new software CREST took its place which was far more efficient than TAURUS (Savolainen Ahonen and Richardson 2012). The main reason for the failure of the TAURUS software was the increase of the complexity of the system and the involvement of the middle man in the development of the software (Maas et al. 2016). An U.S. software was bought and it was tried to be modified but a survey was made and it was found that to meet the requirement of the London Stock Exchange about 70% of the codes was required to be changed. Reason of Software Project Failure The two major reasons for the failure of the TAURUS are as follows. Creation of a centralized database: The first reason was the creation of a centralized database which requires a complete change in the business process of the share holders. TAURUS attempted to make a centralized hub to record the transaction and record the data flow. It was made to avoid the middleman who had a major role in the trading process of the share. The result of introducing the system was a violent opposition by the registrars or the middleman who could not gain profit from the business anymore. For developing the software a time period of 5 years was taken but it could not change the business process and finally the approach of the software was discarded in the year 1989 (O'Regan 2012). The stock exchange began to develop new design for the software which would be acceptable to all the stakeholders. Complexity of the project: Secondly the complexity of the project increased due to the revised design of the software and involvement of the stakeholders in the meetings. The new design was implemented by modifying a part of the existing system that was bought from U.S. Modifying the software was a great challenge for the software developer because the codes of the bought project was unknown to the designer and the developer have to follow the British laws and regulation to change the software and act according to the London stock exchange policy. It was noted that to meet the requirement of the London stock exchange policy about 70% of the codes was needed to be changed and this change in the codes caused a loss of time and the value of the purchasing of the software. The date that was fixed for the implementation of the software got delayed for a number of times and the external factors affecting the project made the software product unusable and finally it was discarded in the yea r 1993. Thus the lack of the strategic decision and poor governance was the main cause for the failure of TAURUS. Waterfall Model Description of Each Phases of Waterfall Model The waterfall model is the first developed software improvement lifecycle that is implemented to develop software. The waterfall model consists of 6 phases like requirement specification and analysis, feasibility study, coding, design, and unit testing, Integration, system testing and maintenance. Requirement specification and Analysis: Requirement gathering and analysis: The purpose of this step is to accumulate all the related information concerning the product from the customer to be developed with a vision to undoubtedly understand the requirement of the customers and to face the inconsistencies and the incompleteness. Requirement specification: The customer requirement identified and gathered into a document known as SRS or Software Requirement Specification document. The vital components of the document are: Functional requirements: It involves the identification of the function to be supportive to the system. Non-Functional Requirement: It includes the maintenance of the performance and the standards. The document of SRS is written by the end-user language and must be understandable by the customer and if necessary it will be reviewed then approved by the customer. It works like an agreement or pact between the developer team and the customers. Feasibility Study In this step we need to determine whether it is financially technically and timely feasible or not. In this process the problems regarding the project is analysed and the data regarding the software product is collected. While collecting the data we need to follow the following steps: An abstract problem definition which includes important requirement only and ignores the unimportance Formulation of different solution strategies Analysing of alternate solutions and compare their benefits and disadvantages Coding and Unit Testing In this phase we interpret the software design into a source code. Each constituent of the design is executed as a module of program that is individually tested which is known as unit testing. Each unit is tested to check it is correctly working or not which an efficient way to debug the errors. Design In design phase the designer alters the requirement prcised in the document of SRS into a structure that is appropriate to be implemented using programming language. There are basically two types of approach for designing. Traditional Design Approach- There are two types of activities in this approach Structured analysis: Here the details regarding the structure of the problem are examined. Structured designed activity: Here the outcomes of structured analysis are changed into a software based design. In the design approach we need to use DFDs, ERDs. Object oriented design approach- This is a new system where the objects that arise in the solution domain and the crisis domain are recognized. The relationship exists among them are identified. The advantages of this approach are less development time and effort, better maintenance etc. Integration and system testing After the unit testing is over the modules are integrated in a systematic manner and the testing for the system is carried out. The purpose of this testing is ensuring a developed system is that is properly working or not and confirming the requirement of SRS document. Types of system testing Alpha Testing- In this case the system testing is executed by the developer team. Beta Testing- This type of system testing is executed by a friendly customer set. Acceptance Testing- The customer executes this testing by himself after the delivery of the product for determining whether the product would be accepted or rejected. Maintenance Sometimes maintenance needs much more effort than developing the software. There are mainly three types of maintenance. Rectifying errors that are not revealed during the phase of product development is known as the corrective maintenance. For improving the execution of the system and to enhance the utility according to the customer requirement is known as perfective maintenance. Adaptive maintenance is known as for the porting the software to a new environment (a new platform or computer or a new operating system). Advantages of Waterfall Model and Examples The advantages of the classical model of waterfall are as follows: It is very simple to develop. It is easily manageable because the model is inflexible. It has a well defined inputs and outputs for every phase such as deliverables and milestones. It can be easily understood even by the non-technical persons (David and David 2016). It works well for smaller projects because the requirement is well understood by using this method. The classical waterfall model is appropriate for the small software projects where the requirement is clearly understood and less customer interaction is required for the development of the project. The project can be shown to the customer when the building of the software is completed. If there is any failure of the project the loss is very high as the whole project is required to be changed and thus it is applied for small scale software projects. Explanation of Main problems associated with Waterfall Model The main problem associated with the waterfall method is as follows: It cannot handle the risk that a real life project is subjected to. Since it is an idealistic model it assumes that the entire requirement should be clearly understood. There is no involvement of the user during the development phase. The user can only get to work once the system is fully developed since it is sequential in nature. The waterfall model is inappropriate for a large scale software project because if a requirement is changes by the user the designer and the software engineering have to begin the development from the early stage (Dingsyr et al. 2012). In practical scenario errors are identified much later during the development of the software product and if an error is identified in the later phase of development there is no way to get back to its immediate early phase to resolve the error. Thus it is difficult to handle large scale software project with the classical waterfall model. Consideration of Scenario In the practical environment the engineers face a large number of errors in almost every phase of the lifecycle. These faults usually get noticed much later in the lifecycle. Once a defect is noticed the engineers want to go back to the segment where the faults had taken place for reconstruction. Iterative waterfall model allows the engineers for going back to their particular phase using the feedback paths (Gandomani et al. 2013). The diagram of iterative model is very much similar to the classical waterfall model. In the classical waterfall model if an error is identified in the later stage there is no path to go back from that stage but this problem is conquered in the iterative model of waterfall by adding a feedback path to each of the stage (O'Regan 2012). If an error is identified in the requirement analysis and specification phase while the software engineers are working in the design phase; in classical waterfall model there was no way to modify the errors but in the iterati ve waterfall model the software engineers can go back to the requirement analysis and specification phase through the feedback path and solve the error (Balaji and Murugaiyan 2012). In the classical waterfall model if an error is identified in the design phase and the software engineers are working in the integration and system testing, they have to discard their workings and first solve the problem in the design phase and freshly start working on the later phases. Agile methods Summarising the Advantages of Incremental Delivery The incremental model is also known as Evolutionary Model (Bassil 2012). The software requirement is broken down into numerous modules in this model which can be incrementally developed step by step (Patel and Jain 2013). The different types of waterfall model are combined to form the incremental model. Firstly, the core modules are developed and the preliminary merchandise is refined into growing levels by addition of new functionalities. Each of the modules that are developed act as an independent module. Each evolutionary version is developed using the iterative waterfall model (Balaji and Murugaiyan 2012). The module acts as a standalone feature and can be delivered to the client and there is no interdependency between the modules. In case if an error is identified the error module is discarded and the whole project is saved. Figure 3: Incremental model for software development (Source: Created by author) There are several advantages of this model. The accuracy of the actual software product can be increased because there is a chance to experiment with the partially developed software (Bassil 2012). The core modules are tested again and again so that there is less chance of errors in the final product. Explanation on the way of first development that helps in understanding better The test first programming helps the developer to get a better idea about the software product the user wants from the developer. The developer first checks the acceptance of the software to the users and which group of customers would use the software product. It helps in understanding the application program interface and the graphical user interface from the customer perspective like what should be the input elements and their need as an input (Gandomani et al. 2013). Next the integration testing of the software is done to check the individual module of the software code written by the developer. The test first development also helps to identify a feature of a product which is working or not and the riskiest part of the feature or any other feature that may be skipped by the developer. It also helps to build a quality product with minimizing the errors in the final software product developed by the software development team (Bassil, 2012). The test first development is used for complex projects and the developer can get an idea to write the next part of the code by testing the previous module (Bass 2015). It would be easy to understand from the diagram given below that shows the testing process of the software product before launching it or handing over to the client. Figure 4: The test process (Source: Agiledata.org. 2016) Suggesting Three Reasons The productivity rate of two programmers working together is more than the programmers individually working (Patel and Jain 2013). This is because the programmers working together have greater responsibility towards the system as they have common responsibility. This process is also known as the pairing program. This is used to get a better output from the software developers working on the same software product (Gandomani et al. 2013). The line of codes written by the programmer is looked up two times and thus the errors can be identified more quickly and resolved. They switch their roles simultaneously such that errors or mistake made by one individual can be identified by the other one. The two software engineers work as a team and there is a continuous transfer of knowledge between them this helps them to overcome any problem that may arise during the software development process (Savolainen Ahonen and Richardson 2012). The two programmers can discuss among themselves about a part of the project that is not understood by them and thus a false start can be avoided from this (Patel and Jain 2013). The programmers working together have a mental satisfaction after developing a quality product this increases the confidence of the programmer. The programmers can rearrange the internal components of the software product to improve the development process of the software (Bassil, 2012). There may be three types of pairing like both the developers are experts, one of the developer is expert and another is novice or both the developers are novice. Project Scheduling Activity Network Chart without Milestone The network activity diagram is shown below. Figure 4: Network activity diagram (Source: Created by author) Gantt Chart Figure 5: Gantt chart showing earliest start and finish time (Source: Created by author using Excel) Staff Allocation Chart Here three developers are assumed to work on a project named Bob, Sue and Ann. They are assigned with one task each and the tasks are divided among them to complete the project in a shortest period of time. The graph below shows the staff allocation chart and the red bars are the critical path of the project. Figure 6: Staff allocation chart (Source: Created by author) References Agiledata.org. (2016).Introduction to Test Driven Development (TDD). [online] Available at: https://agiledata.org/essays/tdd.html [Accessed 23 Jul. 2016]. Savolainen, P., Ahonen, J.J. and Richardson, I., 2012. Software development project success and failure from the supplier's perspective: A systematic literature review.International Journal of Project Management,30(4), pp.458-469. Maas, M., Asanovi, K., Harris, T. and Kubiatowicz, J., 2016, March. Taurus: A Holistic Language Runtime System for Coordinating Distributed Managed-Language Applications. InProceedings of the Twenty-First International Conference on Architectural Support for Programming Languages and Operating Systems(pp. 457-471). ACM. O'Regan, G., 2012.A practical approach to software quality. Springer Science Business Media. Balaji, S. and Murugaiyan, M.S., 2012. Waterfall vs. V-Model vs. Agile: A comparative study on SDLC.International Journal of Information Technology and Business Management,2(1), pp.26-30. Bassil, Y., 2012. A simulation model for the waterfall software development life cycle.arXiv preprint arXiv:1205.6904. Patel, U.A. and Jain, N.K., 2013, April. New Idea In Waterfall Model For Real Time Software Development. InInternational Journal of Engineering Research and Technology(Vol. 2, No. 4 (April-2013)). ESRSA Publications. Gandomani, T.J., Zulzalil, H., Ghani, A.A.A., Sultan, A.B.M. and Nafchi, M.Z., 2013. Obstacles in moving to agile software development methods; at a glance.Journal of Computer Science,9(5), p.620. Bass, J.M., 2015. How product owner teams scale agile methods to large distributed enterprises.Empirical Software Engineering,20(6), pp.1525-1557. Dingsyr, T., Nerur, S., Balijepally, V. and Moe, N.B., 2012. A decade of agile methodologies: Towards explaining agile software development.Journal of Systems and Software,85(6), pp.1213-1221. David, F. and David, F.R., 2016. Strategic Management: A Competitive Advantage Approach, Concepts and Cases.