The most interesting thing for me in this chapter is the system implementation, namely, the circular structure of the implementation system. To begin with, this structure is interesting for me in that it breaks the implementation process into five different steps which makes it more practical and allows this process to be much clearer overall. Then, this circular shape is actually what attracts me most. To explain it further, as it is a common sense that there would be a start point and an ending in any system, however, this is not the same case when it comes to the implementation of the management information system because it seems to be a repetitive process. As for me, I would internally regard the design as the initial process in that it forms the basis of the preliminary system. Then, I tend to put the planning and analysis after the design, however, in this system, they are the two after the implementation. This is informative for me in that it teaches me that the eventual mistakes of the design in the system is more likely to be discovered by the testing but not by the theoretical analysis. Thus, in the forthcoming practice, I am going this apply this system into practice.
Hello,
Reading through your response to what you found most interesting from the textbook chapter 13 on “System Implementation”, I could tell that you took interest in some of the more detailed features of the implementation process. Namely, how you took an interest in the cyclical nature of implementation and go onto explain that while implementation has a beginning, there isn’t necessarily an ending point as improvements can always be made. What I was curious about, however, was the type of system you were envisioning in your mind as an example of the cyclical nature of system implementation, since you talk about it a little towards the end of your example.
After planning and maintenance, the system implementation phase is where all the action starts and will be the most expensive phase. What I found the most interesting part of this chapter is The Processes of Documenting the System, Training Users and Supporting Users. Analysts need to prepare documents that reveal all of the important information you have accumulated about this system during its development and implementation.
There are two audiences for this final documentation:
-the information systems personnel who will maintain the system throughout its productive life,
-the people who will use the system as part of their daily lives. The analysis team in a large organization can get help in preparing documentation from specialized staff in the information systems department.
Training is very important, big organizations tend to provide training and support to computer users through the organization. As we know, the biggest threat can come from people within the information system.
To gain an understanding of implementation strategy, we must first define a strategic plan. A strategic plan is the process of defining the strategy by which you (or a team or organization) will accomplish certain goals or make decisions. Organizations make strategic plans to guide organizational direction, a particular department’s efforts, or any project or initiative.
Looking back on what stood out to me while reading through Chapter 13, which focused on the “Sytem Implementation” phase of the systems development life cycle, I definitely took the most interest in the section focusing on Installation. Prior to reading this chapter, I hadn’t realized that there were 4 primary installation methods that companies tend to employ, those being: Direct Installation, Parallel Installation, Single-Location Installation and Phased Installation. Direct installation, being the most straightforward and only method I was truly familiar with, revolved around an immediate switch from the old system to the new system upon activation. Parallel installation, in comparison, requires that the old system and new system run parallel to each other for a short period of time until management deems necessary for integration and testing purposes, ensuring the new system is satisfactory. Single-location Installation, being the most intriguing method in my opinion, has the new system being tested on a separate location for testing purposes prior to deployment to the rest of the locations. Phased installation, on the other hand, is the most micro-focused of the installation methods, having only certain aspects and function of the system replaced at different times until the new system is fully integrated, all while trying to ensure functionality and compatibility is kept through out.
System implementation uses the structure created during architectural design and the results of system analysis to construct system elements that need the stakeholder requirements and system requirements developed in the early life cycle phases. System implementation is made up of many activities. It is included six major activities that are coding, testing, installation, documentation, training, and support. These steps are to convert the physical system specifications into working and reliable software and hardware, document the work that has been done and provides help for current and future users and caretakers of the system.
The management support of the system under development and the involvement of users in the development process are necessary for a successful implementation. But although the support and active participation of management and users, information systems implementation sometimes fail. For instance, un unstable or insecure hardware and network platform is likely to challenge system integrity and can often impose a political risk that kills a project. This can be especially critical for hosted solutions where internet connectivity may poor performing. Make sure there is a fast, reliable internet connection before implementing hosted software.
The following major activities and tasks are performed during this process:
Define the implementation strategy
Realize the system element
Provide evidence of compliance
Package, store, and supply the implemented element
I think one thing of interest I took away from MSAD Chapter 13 “System Implementation” is “software application testing.” In traditional plan-driven systems development projects, coding takes considerable effort and skill. However, we need to understand the essentials of the testing process because software application testing is an activity that analysts plan at the beginning of the analysis phase. Many of the tests in this section can be used during the analyze–design–code–test cycle common to the Agile Methodologies. During analysis, we will develop a master test plan. During design, we will develop a unit test plan, an integration test plan, and a system test plan. During implementation, we put these various plans into effect and perform the actual testing.
I agree. I also mentioned coding in my comment. Coding does not only need a lot of skill but also so much effort. There are an infinite amount of different ways to create a picture. Depending on the project, it could be simple or complex. If you are making an in-house application, the effort needed is a lot different than an application for your clients.
I’m interested in system implementation testing as well. The purpose of testing is to confirm that the system satisfies the requirements. We can break down system implementation testing into 7 types of testing, they are both physical and technical testing. while walking through testing, desk checking are focused on maintaining equipment, systems. Inspection ensure each module is tested alone in an attempt to discover any error on its code
The most interesting part to me is always the coding, testing, and implementation process. The system or application has just been designed and now you get to bring your vision to life. From previous coding experience, coding is one big, frustrating nightmare. Ideally, I will never have to do the coding in a project. My preferred career path is either in IT Auditing or IT Project Management. I’d much rather tell people what to do, or what they did wrong. In reality, it seems like the coding and testing process is never. There will always have to be updates and patches to any application. Just think about any application that you’ve had for a few years, and how different it looks now compared to when it was first implemented.
Hey Penay, I agree with you that seeing your masterpiece come to life is one awesome part of the system development process. In addition, coding — especially on a new application — can cause too many headaches that turn into roadblocks. I know during my code development and testing I do periodic testing to show whether what I did actually affected the project as I thought it would. Carrying the ITACS view into the real world will definitely give us an advantage over our competitors.
Hi Panayiotis, I agree with your point about preferring IT auditing over coding. I am also not a strong coder but seeing a design I’ve worked on come to life is still gratifying. With each iteration of updates, the testing and implementation phase truly doesn’t ever halt.
The one thing that I found interesting is user acceptance testing which determines whether the new system meets the user requirement or not. Two common acceptance testings are alpha testing and beta testing.
Alpha testing is simulated and uses typical data for system testing, and there are several testing are included such as recovery testing, security testing, stressing testing, performance testing. Recovery testing is interesting because it forces the software to fail to verify that if the recovery is properly performed. Stress testing is also interesting because it trie to break the system to see what happens.
Beta testing uses live data that are used in the users’ real working environment, which is to determine whether the software, documentation, technical support, and training activities work as intended or not. Any problems that are found during the testing phase need to be corrected before users can actually accept the system.
Hi Shuyue, I’m really interested in the Alpha and Beta testing too. Both of them are commonly used to denote the three stages of the software testing process. Alpha is the first phase of an informal acceptance test and is typically used for internal testing only while Beta is the second phase, which has eliminated most of the imperfections in the software, but it is still possible to have defects and vulnerabilities that are typically only available to a specific group of users for testing purposes. They play the important roles in the system tests.
One thing that was interesting to read was acceptance testing by users. Even though we have spent some time discussing how important acceptance testing is, we did not focus much attention on the different types of acceptance testing. So, I assumed acceptance testing was performed a couple times until all glitches were treated and users were satisfied with the system. However, this is not the case. Acceptance testing includes alpha testing and beta testing. Alpha testing is testing using simulated data. On the other hand, beta testing is testing carried out by real users in a real environment. If this was not time consuming already, alpha testing is broken down into four types of tests— recovery testing, stress testing, security testing, and performance testing. Each of these test types have their own set of requirements that must be met. Once all of these tests are satisfied, beta testing is performed. After the system passes the different testing stages, the system can move into the installation phase. As you can see, acceptance testing is a laborious cycle. It is not something that takes only a couple days to achieve.
I agree with your points Raisa. I had initially overlooked this section when I read over the topics in this chapter but after looking thorough most of the comments, I brushed up my understanding and importance of User Acceptance testing. This piece is extremely important as the user acceptance testing helps the requester/project management team to determine if the software that is being developed is working based on how it is supposed to work for users. UAT reduces the risk of defects being identified in production. Fixing items in development is less costly and has less risk to the business than issues being identified in production.
When it comes to Software implementation, the one key activity that should not be ignored is “Documentation”. When building software without documentation, developers can easily forget, get distracted and derail from the core functionality that the software solution is supposed to provide. Having documented software requirements is critical to ensuring that everyone is headed towards the same direction to accomplish the objectives of the project. If developers and stakeholders forget what has been discussed, they can always refer back to the requirements documentation, in whatever form it exists.
To make it more easier, documentation types can further be divided into two – System documentation and User documentation. System documentation provides detailed information about a system’s design specifications, its internal workings, and its functionality whereas user documentation is a written or other visual information about an application system, how it works, and how to use it. Though Agile approaches question the need for extensive documentation, communicating requirements without “enough” documentation can pose significant risks of missing out on key requirements or creating gaps in understanding what the system is expected to do.
I feel as though the importance of documentation is often overlooked during these projects, most likely due to the idea that it’s redundant, tedious, or a waste of time. Personally, I’ve always found it better to just make note of everything at that moment and avoid the mentality that I’ll remember when the time comes. This is the issue with the Agile approach, as you mentioned. We can see in the readings that having extensive planning/documentation is typically better than just thinking of ideas on the fly and hoping for the best. Without having a proper game plan, this is probably where the issue of security as an afterthought comes into play.
In this chapter, I think the testing process is interesting. There are two important things to understand about testing information systems. The first thing is the purpose of testing is to confirm that the system satisfies requirements and second is testing must be planned. The authors also mentioned about the seven different types of tests for software applications. I think it is important to understand why we need to conduct the testing and how to do it. Testing is the process of evaluating a system or its components with the intent to find whether it satisfies the specified requirements or not. A test case should be repeatable so that it can be rerun as new versions of the software are tested.
Hi Ryu! Good stuff. I too found testing to be an interesting section. The purpose of system testing is to evaluate the system’s compliance with specified requirements. The goal of system testing is not just to find bugs or defects. It is to reduce risk by proactively finding and eliminating issues which could affect the user and the business in the long run.
Chapter 8, the system implementation is the last stage of new system development. It is the process of turning the result of structured system design into a practical system. Under this phase, the testing is needed, and I find alpha testing and beta testing are quite interesting. Alpha testing is testing by users in a development environment, or by users within a development environment simulating a real environment, while Beta testing is testing by one or more users of software in a real-world environment. Alpha testing refers to the organization of system development companies to simulate various types of users to test the upcoming system in an attempt to find errors and correct them. After passing the Alpha testing, the system goes to the Beta testing, which is an acceptance test. Beta test is the system testing activity carried out before the product release after the completion of functional test and system test. After passing the acceptance test, the product will enter the release stage and are ready to use.
Hi Yuqing, I agree with your ideas. When I read about Alpha testing, I found that it is a type of acceptance testing. The focus of this testing is to simulate real users by using a black box and white box techniques. The aim is to carry out the tasks that a typical user might perform. I think it is a good idea to compare with Beta testing.
One point is to to determine if an implementation has been successful, the two most common and trusted are the extent to which the system is used and the users’ satisfaction with the system. Six factors that influence the extent to which a system is used includes User’s personal stake (how relevant the system is to the work the user performs), System characteristics (aspects of the system’s design such as ease of use, reliability and relevance to the task the system supports), User demographics (Characteristics of the user, such as age and degree of computer experience), Organizational support, Performance (The more use, the greater the performance) and Satisfaction (The more they use it, the more satisfied they will be).
I found an interesting point about large organization system implementation. It lend provide training and support to computer users throughout the organization. Some of the training and support is very specific
to particular application systems, whereas the rest is general to particular operating systems or off-the-shelf software packages. For example, it is common to find courses on Microsoft Windows® in organization-wide training facilities. Analysts are mostly uninvolved with general training and support, but they do work with corporate trainers to provide training and support tailored to particular computer applications they have helped to develop. Centralized information system training facilities tend to have specialized staff who can help with training and support issues.
Hi, Yuan
Good point and I cannot agree more. Often times I Google or watch Youtube learn how to use off the shelf package, and there are a lot of free courses and lectures all over the Internet as well as the website of the company developed the software. It would be a lot easier to train users with off the shelf software package. On the other hand, organizations would provide specialized staff who knows the software very well and good with communication.
Hi Yuan,
Interesting point and I also agree it is interesting that training can be very specific. The employee who receives the necessary training is more able to perform in their job and reduce the risk of a data breach in the organization. Also training will improve morale of the employees as they will more or less be on the same level so they can work better and perform better.
In Chapter 13 of MSAD “System Implementation”, the main topic is of course centered around implementing a Information System or Software into a new or existing business. The Chapter started off stating that the implementation phase is the most expensive and time consuming phase because of the sheer amount of people that are involved in the processes. It is vitally important to get this step right as a proper/improper implementation would have positive and negative effects down the line. One section that stuck out to me was the “User Acceptance Testing” (UAT) section. In the industry I hear User Acceptance thrown around like a buzzword. Therefore, I decided to take a deeper dive. UAT deals with testing the system/software in the environment where it will be used. This aspect will prove if the system fully meets its requirements as a real world application in practice.
User acceptance testing (UAT) is the last phase of the software testing process. During UAT, actual software users test the software to make sure it can handle required tasks in real-world scenarios, according to specifications.
UAT is one of the final and most critical software project procedures that must occur before newly developed software is rolled out to the market. Also, as beta testing, application testing or end-user testing.
UAT directly involves the intended users of the software. UAT can be implemented by making software available for a free beta trial on the internet or through an in-house testing team comprised of actual software users.
UAT is important because it helps demonstrate that required business functions are operating in a manner suited to real-world circumstances and usage.
The most interesting part for me is testing, this is also the part benefits me most. The purpose of testing is to confirm that the system satisfies the requirements.After I review the chapter, I learn that there are 7 types of testing, they are both physical and technical testing. Regarding physical testing, A walkthrough testing helps the group to review of any product created during the systems development process. A desk checking manually executed by the reviewer to test the program. while technical testing emphasis on developing a master testing plan during the analysis phase. First of all, Inspection is a testing technique in which participants examine program code for predicable language-specific errors. Unit testing ensure each module is tested alone in an attempt to discover any error on its code. Furthermore, Integration testing brings together all of the modules that a program comprises for testing purposes.
From the chapter about implementation, I learned that system implementation is actually made of many activities. The six major activities are the circular flow are coding, testing. installation, documentation, training, and support. With each, there are deliverables coming from each activity. This circular flow seems to be using an agile methodology to continuously go through each iteration to convert the physical system specifications into the working and reliable software and hardware.
Each of these activities is also broken up into different types, such as the seven different types of testing, and acceptance testing. There’s also four different types of installation and 2 types of documentation.
Great comments! The six major activities of the system implementation are important for an auditor to understand. Among the six major activities, there are a lot of more definitions, such as different types of installation and documentation.
While reading the section on system implementation issues, I thought about how it relates back to the Mudra Communications case study that we analyzed earlier in the semester. The author cites commitment to the project, commitment to change, and the extent of project definition and planning, as the additional factors to the catchall standard of management and user involvement during the development process. Furthermore, it is important that the new system meets user expectations- meaning that the system seems familiar and is not an entirely new piece of technology that is intimidating or difficult to use. We can, again, see how issues in system development can typically be traced back to poor planning and/or documentation procedures, and how these early stages of the SDLC are crucial for project success.
Feng Gao says
The most interesting thing for me in this chapter is the system implementation, namely, the circular structure of the implementation system. To begin with, this structure is interesting for me in that it breaks the implementation process into five different steps which makes it more practical and allows this process to be much clearer overall. Then, this circular shape is actually what attracts me most. To explain it further, as it is a common sense that there would be a start point and an ending in any system, however, this is not the same case when it comes to the implementation of the management information system because it seems to be a repetitive process. As for me, I would internally regard the design as the initial process in that it forms the basis of the preliminary system. Then, I tend to put the planning and analysis after the design, however, in this system, they are the two after the implementation. This is informative for me in that it teaches me that the eventual mistakes of the design in the system is more likely to be discovered by the testing but not by the theoretical analysis. Thus, in the forthcoming practice, I am going this apply this system into practice.
Imran Jordan Kharabsheh says
Hello,
Reading through your response to what you found most interesting from the textbook chapter 13 on “System Implementation”, I could tell that you took interest in some of the more detailed features of the implementation process. Namely, how you took an interest in the cyclical nature of implementation and go onto explain that while implementation has a beginning, there isn’t necessarily an ending point as improvements can always be made. What I was curious about, however, was the type of system you were envisioning in your mind as an example of the cyclical nature of system implementation, since you talk about it a little towards the end of your example.
Yuchong Wang says
After planning and maintenance, the system implementation phase is where all the action starts and will be the most expensive phase. What I found the most interesting part of this chapter is The Processes of Documenting the System, Training Users and Supporting Users. Analysts need to prepare documents that reveal all of the important information you have accumulated about this system during its development and implementation.
There are two audiences for this final documentation:
-the information systems personnel who will maintain the system throughout its productive life,
-the people who will use the system as part of their daily lives. The analysis team in a large organization can get help in preparing documentation from specialized staff in the information systems department.
Training is very important, big organizations tend to provide training and support to computer users through the organization. As we know, the biggest threat can come from people within the information system.
Yuan Liu says
To gain an understanding of implementation strategy, we must first define a strategic plan. A strategic plan is the process of defining the strategy by which you (or a team or organization) will accomplish certain goals or make decisions. Organizations make strategic plans to guide organizational direction, a particular department’s efforts, or any project or initiative.
Imran Jordan Kharabsheh says
Looking back on what stood out to me while reading through Chapter 13, which focused on the “Sytem Implementation” phase of the systems development life cycle, I definitely took the most interest in the section focusing on Installation. Prior to reading this chapter, I hadn’t realized that there were 4 primary installation methods that companies tend to employ, those being: Direct Installation, Parallel Installation, Single-Location Installation and Phased Installation. Direct installation, being the most straightforward and only method I was truly familiar with, revolved around an immediate switch from the old system to the new system upon activation. Parallel installation, in comparison, requires that the old system and new system run parallel to each other for a short period of time until management deems necessary for integration and testing purposes, ensuring the new system is satisfactory. Single-location Installation, being the most intriguing method in my opinion, has the new system being tested on a separate location for testing purposes prior to deployment to the rest of the locations. Phased installation, on the other hand, is the most micro-focused of the installation methods, having only certain aspects and function of the system replaced at different times until the new system is fully integrated, all while trying to ensure functionality and compatibility is kept through out.
Zhu Li says
System implementation uses the structure created during architectural design and the results of system analysis to construct system elements that need the stakeholder requirements and system requirements developed in the early life cycle phases. System implementation is made up of many activities. It is included six major activities that are coding, testing, installation, documentation, training, and support. These steps are to convert the physical system specifications into working and reliable software and hardware, document the work that has been done and provides help for current and future users and caretakers of the system.
The management support of the system under development and the involvement of users in the development process are necessary for a successful implementation. But although the support and active participation of management and users, information systems implementation sometimes fail. For instance, un unstable or insecure hardware and network platform is likely to challenge system integrity and can often impose a political risk that kills a project. This can be especially critical for hosted solutions where internet connectivity may poor performing. Make sure there is a fast, reliable internet connection before implementing hosted software.
Feng Gao says
The following major activities and tasks are performed during this process:
Define the implementation strategy
Realize the system element
Provide evidence of compliance
Package, store, and supply the implemented element
Penghui Ai says
I think one thing of interest I took away from MSAD Chapter 13 “System Implementation” is “software application testing.” In traditional plan-driven systems development projects, coding takes considerable effort and skill. However, we need to understand the essentials of the testing process because software application testing is an activity that analysts plan at the beginning of the analysis phase. Many of the tests in this section can be used during the analyze–design–code–test cycle common to the Agile Methodologies. During analysis, we will develop a master test plan. During design, we will develop a unit test plan, an integration test plan, and a system test plan. During implementation, we put these various plans into effect and perform the actual testing.
Panayiotis Laskaridis says
I agree. I also mentioned coding in my comment. Coding does not only need a lot of skill but also so much effort. There are an infinite amount of different ways to create a picture. Depending on the project, it could be simple or complex. If you are making an in-house application, the effort needed is a lot different than an application for your clients.
Xinye Yang says
I’m interested in system implementation testing as well. The purpose of testing is to confirm that the system satisfies the requirements. We can break down system implementation testing into 7 types of testing, they are both physical and technical testing. while walking through testing, desk checking are focused on maintaining equipment, systems. Inspection ensure each module is tested alone in an attempt to discover any error on its code
Panayiotis Laskaridis says
The most interesting part to me is always the coding, testing, and implementation process. The system or application has just been designed and now you get to bring your vision to life. From previous coding experience, coding is one big, frustrating nightmare. Ideally, I will never have to do the coding in a project. My preferred career path is either in IT Auditing or IT Project Management. I’d much rather tell people what to do, or what they did wrong. In reality, it seems like the coding and testing process is never. There will always have to be updates and patches to any application. Just think about any application that you’ve had for a few years, and how different it looks now compared to when it was first implemented.
Alexander Reichart-Anderson says
Hey Penay, I agree with you that seeing your masterpiece come to life is one awesome part of the system development process. In addition, coding — especially on a new application — can cause too many headaches that turn into roadblocks. I know during my code development and testing I do periodic testing to show whether what I did actually affected the project as I thought it would. Carrying the ITACS view into the real world will definitely give us an advantage over our competitors.
Mei X Wang says
Hi Panayiotis, I agree with your point about preferring IT auditing over coding. I am also not a strong coder but seeing a design I’ve worked on come to life is still gratifying. With each iteration of updates, the testing and implementation phase truly doesn’t ever halt.
Shuyue Ding says
The one thing that I found interesting is user acceptance testing which determines whether the new system meets the user requirement or not. Two common acceptance testings are alpha testing and beta testing.
Alpha testing is simulated and uses typical data for system testing, and there are several testing are included such as recovery testing, security testing, stressing testing, performance testing. Recovery testing is interesting because it forces the software to fail to verify that if the recovery is properly performed. Stress testing is also interesting because it trie to break the system to see what happens.
Beta testing uses live data that are used in the users’ real working environment, which is to determine whether the software, documentation, technical support, and training activities work as intended or not. Any problems that are found during the testing phase need to be corrected before users can actually accept the system.
Yuqing Tang says
Hi Shuyue, I’m really interested in the Alpha and Beta testing too. Both of them are commonly used to denote the three stages of the software testing process. Alpha is the first phase of an informal acceptance test and is typically used for internal testing only while Beta is the second phase, which has eliminated most of the imperfections in the software, but it is still possible to have defects and vulnerabilities that are typically only available to a specific group of users for testing purposes. They play the important roles in the system tests.
Raisa Ahmed says
MSAD Chapter 13 “System Implementation”
One thing that was interesting to read was acceptance testing by users. Even though we have spent some time discussing how important acceptance testing is, we did not focus much attention on the different types of acceptance testing. So, I assumed acceptance testing was performed a couple times until all glitches were treated and users were satisfied with the system. However, this is not the case. Acceptance testing includes alpha testing and beta testing. Alpha testing is testing using simulated data. On the other hand, beta testing is testing carried out by real users in a real environment. If this was not time consuming already, alpha testing is broken down into four types of tests— recovery testing, stress testing, security testing, and performance testing. Each of these test types have their own set of requirements that must be met. Once all of these tests are satisfied, beta testing is performed. After the system passes the different testing stages, the system can move into the installation phase. As you can see, acceptance testing is a laborious cycle. It is not something that takes only a couple days to achieve.
Deepa Kuppuswamy says
I agree with your points Raisa. I had initially overlooked this section when I read over the topics in this chapter but after looking thorough most of the comments, I brushed up my understanding and importance of User Acceptance testing. This piece is extremely important as the user acceptance testing helps the requester/project management team to determine if the software that is being developed is working based on how it is supposed to work for users. UAT reduces the risk of defects being identified in production. Fixing items in development is less costly and has less risk to the business than issues being identified in production.
Deepa Kuppuswamy says
When it comes to Software implementation, the one key activity that should not be ignored is “Documentation”. When building software without documentation, developers can easily forget, get distracted and derail from the core functionality that the software solution is supposed to provide. Having documented software requirements is critical to ensuring that everyone is headed towards the same direction to accomplish the objectives of the project. If developers and stakeholders forget what has been discussed, they can always refer back to the requirements documentation, in whatever form it exists.
To make it more easier, documentation types can further be divided into two – System documentation and User documentation. System documentation provides detailed information about a system’s design specifications, its internal workings, and its functionality whereas user documentation is a written or other visual information about an application system, how it works, and how to use it. Though Agile approaches question the need for extensive documentation, communicating requirements without “enough” documentation can pose significant risks of missing out on key requirements or creating gaps in understanding what the system is expected to do.
Sarah Puffen says
I feel as though the importance of documentation is often overlooked during these projects, most likely due to the idea that it’s redundant, tedious, or a waste of time. Personally, I’ve always found it better to just make note of everything at that moment and avoid the mentality that I’ll remember when the time comes. This is the issue with the Agile approach, as you mentioned. We can see in the readings that having extensive planning/documentation is typically better than just thinking of ideas on the fly and hoping for the best. Without having a proper game plan, this is probably where the issue of security as an afterthought comes into play.
Ryu Takatsuki says
In this chapter, I think the testing process is interesting. There are two important things to understand about testing information systems. The first thing is the purpose of testing is to confirm that the system satisfies requirements and second is testing must be planned. The authors also mentioned about the seven different types of tests for software applications. I think it is important to understand why we need to conduct the testing and how to do it. Testing is the process of evaluating a system or its components with the intent to find whether it satisfies the specified requirements or not. A test case should be repeatable so that it can be rerun as new versions of the software are tested.
Raisa Ahmed says
Hi Ryu! Good stuff. I too found testing to be an interesting section. The purpose of system testing is to evaluate the system’s compliance with specified requirements. The goal of system testing is not just to find bugs or defects. It is to reduce risk by proactively finding and eliminating issues which could affect the user and the business in the long run.
Yuqing Tang says
Chapter 8, the system implementation is the last stage of new system development. It is the process of turning the result of structured system design into a practical system. Under this phase, the testing is needed, and I find alpha testing and beta testing are quite interesting. Alpha testing is testing by users in a development environment, or by users within a development environment simulating a real environment, while Beta testing is testing by one or more users of software in a real-world environment. Alpha testing refers to the organization of system development companies to simulate various types of users to test the upcoming system in an attempt to find errors and correct them. After passing the Alpha testing, the system goes to the Beta testing, which is an acceptance test. Beta test is the system testing activity carried out before the product release after the completion of functional test and system test. After passing the acceptance test, the product will enter the release stage and are ready to use.
Ryu Takatsuki says
Hi Yuqing, I agree with your ideas. When I read about Alpha testing, I found that it is a type of acceptance testing. The focus of this testing is to simulate real users by using a black box and white box techniques. The aim is to carry out the tasks that a typical user might perform. I think it is a good idea to compare with Beta testing.
Haixin Sun says
One point is to to determine if an implementation has been successful, the two most common and trusted are the extent to which the system is used and the users’ satisfaction with the system. Six factors that influence the extent to which a system is used includes User’s personal stake (how relevant the system is to the work the user performs), System characteristics (aspects of the system’s design such as ease of use, reliability and relevance to the task the system supports), User demographics (Characteristics of the user, such as age and degree of computer experience), Organizational support, Performance (The more use, the greater the performance) and Satisfaction (The more they use it, the more satisfied they will be).
Yuan Liu says
I found an interesting point about large organization system implementation. It lend provide training and support to computer users throughout the organization. Some of the training and support is very specific
to particular application systems, whereas the rest is general to particular operating systems or off-the-shelf software packages. For example, it is common to find courses on Microsoft Windows® in organization-wide training facilities. Analysts are mostly uninvolved with general training and support, but they do work with corporate trainers to provide training and support tailored to particular computer applications they have helped to develop. Centralized information system training facilities tend to have specialized staff who can help with training and support issues.
Shuyue Ding says
Hi, Yuan
Good point and I cannot agree more. Often times I Google or watch Youtube learn how to use off the shelf package, and there are a lot of free courses and lectures all over the Internet as well as the website of the company developed the software. It would be a lot easier to train users with off the shelf software package. On the other hand, organizations would provide specialized staff who knows the software very well and good with communication.
Yuchong Wang says
Hi Yuan,
Interesting point and I also agree it is interesting that training can be very specific. The employee who receives the necessary training is more able to perform in their job and reduce the risk of a data breach in the organization. Also training will improve morale of the employees as they will more or less be on the same level so they can work better and perform better.
Alexander Reichart-Anderson says
In Chapter 13 of MSAD “System Implementation”, the main topic is of course centered around implementing a Information System or Software into a new or existing business. The Chapter started off stating that the implementation phase is the most expensive and time consuming phase because of the sheer amount of people that are involved in the processes. It is vitally important to get this step right as a proper/improper implementation would have positive and negative effects down the line. One section that stuck out to me was the “User Acceptance Testing” (UAT) section. In the industry I hear User Acceptance thrown around like a buzzword. Therefore, I decided to take a deeper dive. UAT deals with testing the system/software in the environment where it will be used. This aspect will prove if the system fully meets its requirements as a real world application in practice.
Zhu Li says
User acceptance testing (UAT) is the last phase of the software testing process. During UAT, actual software users test the software to make sure it can handle required tasks in real-world scenarios, according to specifications.
UAT is one of the final and most critical software project procedures that must occur before newly developed software is rolled out to the market. Also, as beta testing, application testing or end-user testing.
UAT directly involves the intended users of the software. UAT can be implemented by making software available for a free beta trial on the internet or through an in-house testing team comprised of actual software users.
UAT is important because it helps demonstrate that required business functions are operating in a manner suited to real-world circumstances and usage.
Xinye Yang says
The most interesting part for me is testing, this is also the part benefits me most. The purpose of testing is to confirm that the system satisfies the requirements.After I review the chapter, I learn that there are 7 types of testing, they are both physical and technical testing. Regarding physical testing, A walkthrough testing helps the group to review of any product created during the systems development process. A desk checking manually executed by the reviewer to test the program. while technical testing emphasis on developing a master testing plan during the analysis phase. First of all, Inspection is a testing technique in which participants examine program code for predicable language-specific errors. Unit testing ensure each module is tested alone in an attempt to discover any error on its code. Furthermore, Integration testing brings together all of the modules that a program comprises for testing purposes.
Mei X Wang says
From the chapter about implementation, I learned that system implementation is actually made of many activities. The six major activities are the circular flow are coding, testing. installation, documentation, training, and support. With each, there are deliverables coming from each activity. This circular flow seems to be using an agile methodology to continuously go through each iteration to convert the physical system specifications into the working and reliable software and hardware.
Each of these activities is also broken up into different types, such as the seven different types of testing, and acceptance testing. There’s also four different types of installation and 2 types of documentation.
Penghui Ai says
Hi Mei,
Great comments! The six major activities of the system implementation are important for an auditor to understand. Among the six major activities, there are a lot of more definitions, such as different types of installation and documentation.
Sarah Puffen says
While reading the section on system implementation issues, I thought about how it relates back to the Mudra Communications case study that we analyzed earlier in the semester. The author cites commitment to the project, commitment to change, and the extent of project definition and planning, as the additional factors to the catchall standard of management and user involvement during the development process. Furthermore, it is important that the new system meets user expectations- meaning that the system seems familiar and is not an entirely new piece of technology that is intimidating or difficult to use. We can, again, see how issues in system development can typically be traced back to poor planning and/or documentation procedures, and how these early stages of the SDLC are crucial for project success.