Midlands Auto-Parts Limited - Report Example

Midlands Auto-Parts Limited Table of Contents Table of Contents 2 Structured Development 3 1-Structured systems development Advantages 3 1.2-Structured systems development Disadvantages 4 2- Object oriented development approaches 5 2.1- Object oriented development Advantages 6 2.2- Object oriented development Disadvantages 6 3- Waterfall SDLC 7 3.1- Waterfall SDLC Shortcomings 9 04- Requirements Elicitation 10 5- System Implementation 11 Level-2 diagram 12 DFD 1 12 UML Activity Diagram 15 Activity Diagram 1 15 Activity Diagram 2 16 6- References 17 1- Structured Development Structured system development methodology (SSDM) is an old system development methodology. Structured development is still used mainly in business in structuring computer based systems those are acknowledged as structured design and analysis based systems. In addition, structured system development methods were initially developed in 1970s and 1980s for third generation programming languages. The general idea is to split a big, complicated problem into smaller parts, each part easy enough to deal with and solve separately. The SSDM methodology has been used for a many years in the real world. However, after the emergence of the object-oriented languages new development technologies have turned out to be gradually more and more well-liked as well as extensively utilized in industrial businesses and university organizations (Firesmith, 1991; Holt, 2009; Stair & Reynolds, 2003). 1.1- Structured systems development Advantages Structured systems development methodology has following advantages (Pefkaros, 2008; Whitten, Bentley, & Dittman, 2000; Laudon & Laudon, 1999): Structured systems development methodology makes better use of it graphical tools and analysis for instance, DFDs. Structured systems development methodology is an extremely familiar as well as recognized methodology for the business. Structured systems development methodology has been in existence for a long time as well as therefore is an established method. Structured systems development methodology permits for a ways of requirements support. Structured systems development methodology is comparatively straightforward as well as easy to recognize. 1.2- Structured systems development Disadvantages Structured systems development methodology has following disadvantages: (Pefkaros, 2008; Worthington, 2003; Whitten, Bentley, & Dittman, 2000) Structured systems development methodology is non-iterative similar to the waterfall model, as a result if there is a change in the requirements its mean regenerating the whole procedure In the structured systems development methodology there is a number of however not enough user/analyst communication Structured systems development methodology is process-oriented; it pays no attention to the non-system development functional requirements. Structured systems development methodology offers less direct management participation in system development Structured systems development methodology does not provide some other tools for the communication with system users other than DFDs, SSAD In structured systems development methodology it is additional hard to make a decision when to prevent functional decomposition as well as to start development of system. Structured systems development methodology does not for all time tackle the system users requirements. 2- Object oriented development approaches The object oriented development methodology is a components based system development methodology. Object oriented development methodology emphasizes on the creation of classes that encapsulates both data and algorithm used to manipulate the data. The main intention of the object oriented software development methodology is to develop a class that would be reusable to different applications and computer based system architecture (Pressman, 2001). In addition, object oriented development methodology incorporates lot of working functionalities of the spiral software development methodology. It is also an evolutionary system development methodology (Sommerville, 2004). Human resource required: This object oriented development methodology is more related to spiral model for the development of the overall system. In this way in this software development methodology there is no need of large development staff as compared to system size, because each problem is broken into small workable functions (Pressman, 2001). Resources needed: Due to less human resource working for system development through object oriented development methodology, there are fewer resources required for development of system (Pressman, 2001). Development domain: Object oriented development methodology is mostly used for huge application development that encompasses major aspect of reusability. It is also most excellent for complicated project for the reason that it develops system though components based approach (Pressman, 2001). 2.1- Object oriented development Advantages Object oriented development methodology has following advantages: (Sommerville, 2004; Whitten, Bentley, & Dittman, 2000) Component based approach is best for huge and complex systems Fewer resources (human and physical) needed as compared to size of system we are going to develop Main aspect of reusability Better interaction to customer Wider elaboration of system requirements Less cost due to reusability Less effort spends on system testing and mitigation because of components based approach. Each component (function) is separate working entity so this minimize the effort to check for whole system working and functionalities 2.2- Object oriented development Disadvantages Object oriented development methodology has following disadvantages: (Sommerville, 2004; Whitten, Bentley, & Dittman, 2000; Holt, 2009) Complex development structure Difficult to handle Not suitable for small projects Object oriented development methodology has a great focus on code than in system design Object oriented development methodology pay more emphasis on team work as in system design Object oriented development methodology is not a simple job to decide the entire objects and classes essential requirements for system Similarities The main similarity in this development methodology and object oriented methodology is the main phases of the system development. The system development phases remain the similar however they use different way of execution for those phases. Differences As compared to object oriented development the structured development is harder to manage and any mistake in earlier phases can only be made by changing the whole process. On the other hand, in object oriented system development we develop the system in small fractions and class based approach in this way any problem in system development could be handled by changing only that particular class. Recommendation For the development of MAP system I will recommend the object oriented system development approach. This will offer us a better system development in different fractions. Such a large system development could only be possible through this development methodology. In case of any problem and difficulty we have better ways to minimize the effect. However in traditional development cycle we need to stuck with the traditional life cycle of system development. 3- Waterfall SDLC The waterfall methodology is also known as liner sequential model that suggests the development of the system through a systemic sequential approach. Through this approach we start from analysis of the system, and then we design, code and test the system for potential operations (Pressman, 2001). So the main stages of the system development are: Requirements Deign Coding Testing Implementation Human resource needed: This method requires fewer human resources for the overall development of the project. In addition, through this model we can develop the overall system using a small development team (Pressman, 2001). Development resources needed: This software development methodology involves less people for the overall development of the project, so we also need fewer resources for the overall project development (Pressman, 2001). Development domain: This development methodology is used for the project of small or medium size and having long or stuffiest time constraints (Pressman, 2001). Figure 1- Main Stages of Waterfall: Image Source: http://farm3.static.flickr.com/2103/2283896218_77ce5af118_o.png 3.1- Waterfall SDLC Shortcomings Following are shortcomings of the Waterfall method :(Sommerville, 2004) and (Pressman, 2001) Real process really follows the sequential model Any error in the system development will remain unrented throughout the development life cycle Customer can not state each requirement at a time Customer has to wait till the completion of project for working version of the system This methodology is not able to manage a complex and larger project Figure 2: Waterfall Operations: Image Source: http://www.limina-ao.com/images/limina_process.png 04- Requirements Elicitation The requirements elicitation process is the initial process of system development. This requirements elicitation process outlines the functional and non-functional requirements for the development of products. This work product will help in recognizing the main needs and requirements for the taking system development. At this stage, we need to access the functional and non-functional requirements. The definition of the aspect is really necessary for the reason that we have to define the system development requirements. Outcomes for the requirements elicitation process are “Analysis reports”. Another main outcome for the requirements elicitation process is “customer requirements report”. In this report developers discover resources, tasks, infrastructure and responsibilities which are necessary to complete the process. The assessment of the system resources, tasks, infrastructure and responsibilities is really compulsory for the reason that it offers us a great help in planning and developing budgetary plans for the system development. Here the outcomes for the system design based Requirements Elicitation process is System architecture design. The process of requirements elicitation involves an assortment of procedures for gathering the system requirements. These procedures can be interview, survey, questionnaire and analysis (Pressman, 2001) & (Sommerville, 2004). For MAP development we would use interview and survey. These techniques are easy to use and effective data can be gathered using these methods. 5- System Implementation The last phase of system development is implementation phase that involves deployment of the applications into overall business and production environments. Its main tasks comprise: (Pressman, 2001; Whitten, Bentley, & Dittman, 2000; Sommerville, 2004) Developing and announcing the implementation timetable End users training Installing the product The corporation should input as well as verify data Testing and configuration of the system as well as security parameters, and also carry out post-implementation evaluations. At this stage, the system implementation management should manage and circulate implementation plan to the entire influenced parties as well as should update clients regarding some implementation tasks. Following the system implementation at organizations we install new product, as well as pre-existing data is electronically transferred or physically input to a novel system. In addition, the confirmation of the correctness of the input data as well as system security configurations is a significant fraction of the execution procedure. The corporation normally runs a new system in parallel with an old system until they authenticate the appropriateness as well as dependability of the new system. The users of the system should document, programming procedural, or configuration errors, transformations appeared all through the confirmation procedure (FFIEC, 2009) & (Yongquiang, Kai, & Li, 1997). System implementation for the MAP will be done through the initially delivering the plan for the system implementation. Then we will analyze the physical work structure. The next step will be about the implementation of new IS application for the MAP business. In the last step we will test and analyze the performance results of the MAP new business technology. Level-2 diagram DFD 1 DFD 2 UML Activity Diagram Activity Diagram 1 Activity Diagram 2 6- References FFIEC., 2009. Development and Acquisition: Development Procedures. Available at: http://www.ffiec.gov/ffiecinfobase/booklets/d_a/08.html [Accessed 19 December 2009]. Firesmith, D., 1991. Structured analysis and object-oriented development are not compatible. ACM SIGAda Ada Letters Volume XI , Issue 9, pp. 56 - 66. Holt, J., 2009. A Pragmatic Guide to Business Process Modelling. London: British Computer Society. ISO/IEC-15504., 2006. Information technology—Process Assessment- Part 5: An exemplar Process Assessment Model. AS/NZS ISO/IEC 15504.5:2006 . Laudon, K. C., & Laudon, J. P., 1999. Management Information Systems, Sixth Edition. New Jersey: Prentice Hall . Pefkaros, K., 2008. Using object-oriented analysis and design over traditional structured analysis and design. Available at: http://findarticles.com/p/articles/mi_6773/is_2_8/ai_n31126769/?tag=content;col1 [Accessed 19 December 2009]. Pressman, R. S., 2001. Software Engineering 5th Edition. New Yoer: McGraw Hill Publishers. Sommerville, I., 2004. Software Engineering, 7th Edition,. . New York : Pearson Education (Addison Wesley). Stair, R. M., & Reynolds, G. W., 2003. Principles of Information Systems, Sixth Edition. Toronto : Thomson Learning, Inc. Whitten, J. L., Bentley, L. D., & Dittman, K. C., 2000. Systems Analysis and Design Methods 5th Edition. New York: Irwin/McGraw-Hill. Worthington, P., 2003. Introduction to Information Systems. Singapore: Thomson. Yongquiang, S., Kai, L., & Li, S., 1997. The design and implementation of a program development system based on rewriting method. ACM SIGPLAN Notices Volume 32 , Issue 2, pp. 27 - 34. Read More