SAD 1 Assignment 6
{ Posted on 3:43 PM
by Ariel Serenado
}
Juan: The way to go about the analysis is to first examine the old system, such as reviewing key documents and observing the workers perform their tasks. Then we can determine which aspects are working well and which should be preserved.
Pedro: We have been through these types of projects before and what always ends up happening is that we do not get the new system we are promised; we get a modified version of the old system.
Juan: Well, I can assure you that will not happen this time. We just want a thorough understanding of what is working well and what isn’t.
Pedro: I would feel much more comfortable if we first started with a list of our requirements. We should spend some time up-front determining exactly what we want the system to do for my department. Then you systems people can come in and determine what portions to salvage if you wish. Just don’t constrain us to the old system.
Insights...
The scenario is very common to those who are involved in technical aspect on system analysis. In this kind of scenario, adjustment is very important especially that you cannot expect everyone to make believe with the idea that you brought to the group. And you cannot force the people around you to implement the said idea or the approach because they do have their own perspective on how the process should be and how a system should be developed. This case is very crucial in a technical environment, there are many approaches, set of standards and with these standards there are corresponding processes and the worst case is that it is not flexible for some point, one have to consider an approach that the system is suited to. Considering now the fact that the two people involved in the presented scenario are not of the same field; from the situation we can somehow say that John Juan is a system analyst or project manager, and IT professional while Pedro Peter is most likely a department manager of a certain business company. It cannot be expected that these two people can immediately unify there ideas considering that their nature of work is different. There are related works that the system professional can relate towards the work of a department manager and so with the manager, there are task perform by system professional that he cannot relate to. Generally, people of different organizations have different outlooks in most processes these people take.
Going back to the scenario, let us first tackle the point made by the system professional, John Juan. A system professional has a wide range of idea in system analysis and developing systems that their clients want them to do, a system professional has a wide range of knowledge on how a project must be processed as to the stages and phases of development; therefore a system professional has the edge on the targeted system by the department manager. I got the point of John which is to examine first the old system that the company is using, review related documents, and observing the functionalities of the system. Knowing that not all developers has the knowledge on the operations of different organizations, so the manner of examining the old system paved the way for the system professional to evaluate and examine the functionalities of the old system, for him also to know how these functionalities relate to the day-to-day operations of the department. Also, the system professional can assess whether to make another system or maybe make some enhancement from the old system without compromising the functionalities of the system. Besides, developer can assess further which data of the involved system can be salvaged and can be migrated to the new system to be developed, otherwise the system professional will develop the required system “from scratch” which is most likely cumbersome to the developer or maybe to the developing team. This is also to reduce the time allotted for the system, instead of developing from the beginning; the developer can just make some improvements or maybe enhancements to realize the system in the least possible time.
Sometimes, it is not ideal for a developer to make another system without having examined the old system, for in developing system one has to have the initiative to utilize available resources before re-inventing tools and approaches. Furthermore, to just examine the old system is not sufficient to define some requirements towards the new system to be developed. The developer should engage a thorough investigation of the current system before defining requirements and specifications for the next system. Thorough investigation may involve interviewing the management and the operational staff, also by direct observation and experience on the system. A set of requirements and specifications, this means the additional functionalities that the new system needs, interfaces, etc.; performance standards, this means levels of system service in terms of quantity, quality, efficiency, effectiveness of the new system; social and technical requirements, this involves system architecture, architectural designs, the languages that the developer will utilize to capture the need of the client. However, the most critical thing in this stage is the knowledge of the end user or the intended user of the system and the effective interpretation of their needs by the developer or the system professional who deals all of these processes. Achieving correct interpretation requires the end user interest and values, and making amicable resolutions which largely meets the interest of both parties.
Pedro on the other hand has also the point which is to have requirements phase, specification analysis before they examine what portion of the system to salvage if they wish. To develop a system, one cannot jump directly to hard coding of the system, the development involves series of documentation to be done prior an implementation phase is made. Pedro mentioned listing of requirements; it is actually the very first phase in the life cycle of a system which covers 2% of the whole development. This phase’ goal is to explore and refine the concept of the system, as result requirements are being elicited. Moreover, in this phase the client outlines the product as he conceptualizes it. From the viewpoint of the developer, the client’s description of the desired product may be vague, unreasonable, contradictory, or simply impossible to achieve. The task of the task of the developer at this stage is to determine exactly what the client needs and to find out from the client what constraints exist. The second thing to do as what Pedro mean in his statement is Specification (analysis) phase, which cover 5% of the total development of the project. This phase is sometimes called “analysis phase”. At the end of this phase, a plan is drawn, the Software Project Management Plan (SPMP), describing the project in detail. Besides, the document includes the functional requirements. In this manner there is a formal project requirements elicitation close-out, requirements set by the client are finalized in the paper. Since there is a close-out if there are changes of the functionalities in the middle of the development then it should de dealt accordingly. In this manner also, you can formalize the functional requirements of the project so the developer can assess how the system should work an in times of examining the old system the developer can see which data, related functionalities will be saved. The idea can be of help to the developer since they will no be working the system “from a scratch”, instead they can make some enhancement for they already know the requirements that has been elicited prior the examination.
Software professionals are also human and therefore sometimes make error especially if requirements needed are not clearly defined. As a result, there will be fault in the system. If the error is made during the requirement phase, then the resulting fault probably will appear in the specifications, design, and most probably in the code. Clearly, the earlier we correct the error, the better. Because if the client discover fault later if the product has been delivered and deployed, cost may be another issue between the developer and to the client. Furthermore, sometimes you don not have to constrain yourself in old systems because not all system can be intermingled with the other program in the sense that some data cannot be migrated to the other system might be that they are using different technology. Also, the old system is not capable to work and cater the need of the client if intermingled with the new system. However, according to Stephen Schach, “up to now, everything seems to be straightforward. Unfortunately, the requirements elicitation phase is inadequately performed”. Reasons may include, the client may not truly understand what is going on in the organization, the client cannot clearly define the functional requirements that involve the operations in the organization. It is therefore hard for a developer to visualize the project when the client himself is not clearly defining the project as to the functional and non-functional requirements of the system. If that is the case then prototyping can be used until such the client is satisfied that the developer has finally captured the system they desired.
In my own notion, I would like to propose the idea of Pedro Peter. Ideally, Pedro is following the ideal stages that a system should undergo prior any implementation is being made. A system should undergo, a hard copy or the technical paper for the developer to finalize what is to develop and what is not.
Pedro: We have been through these types of projects before and what always ends up happening is that we do not get the new system we are promised; we get a modified version of the old system.
Juan: Well, I can assure you that will not happen this time. We just want a thorough understanding of what is working well and what isn’t.
Pedro: I would feel much more comfortable if we first started with a list of our requirements. We should spend some time up-front determining exactly what we want the system to do for my department. Then you systems people can come in and determine what portions to salvage if you wish. Just don’t constrain us to the old system.
Insights...
The scenario is very common to those who are involved in technical aspect on system analysis. In this kind of scenario, adjustment is very important especially that you cannot expect everyone to make believe with the idea that you brought to the group. And you cannot force the people around you to implement the said idea or the approach because they do have their own perspective on how the process should be and how a system should be developed. This case is very crucial in a technical environment, there are many approaches, set of standards and with these standards there are corresponding processes and the worst case is that it is not flexible for some point, one have to consider an approach that the system is suited to. Considering now the fact that the two people involved in the presented scenario are not of the same field; from the situation we can somehow say that John Juan is a system analyst or project manager, and IT professional while Pedro Peter is most likely a department manager of a certain business company. It cannot be expected that these two people can immediately unify there ideas considering that their nature of work is different. There are related works that the system professional can relate towards the work of a department manager and so with the manager, there are task perform by system professional that he cannot relate to. Generally, people of different organizations have different outlooks in most processes these people take.
Going back to the scenario, let us first tackle the point made by the system professional, John Juan. A system professional has a wide range of idea in system analysis and developing systems that their clients want them to do, a system professional has a wide range of knowledge on how a project must be processed as to the stages and phases of development; therefore a system professional has the edge on the targeted system by the department manager. I got the point of John which is to examine first the old system that the company is using, review related documents, and observing the functionalities of the system. Knowing that not all developers has the knowledge on the operations of different organizations, so the manner of examining the old system paved the way for the system professional to evaluate and examine the functionalities of the old system, for him also to know how these functionalities relate to the day-to-day operations of the department. Also, the system professional can assess whether to make another system or maybe make some enhancement from the old system without compromising the functionalities of the system. Besides, developer can assess further which data of the involved system can be salvaged and can be migrated to the new system to be developed, otherwise the system professional will develop the required system “from scratch” which is most likely cumbersome to the developer or maybe to the developing team. This is also to reduce the time allotted for the system, instead of developing from the beginning; the developer can just make some improvements or maybe enhancements to realize the system in the least possible time.
Sometimes, it is not ideal for a developer to make another system without having examined the old system, for in developing system one has to have the initiative to utilize available resources before re-inventing tools and approaches. Furthermore, to just examine the old system is not sufficient to define some requirements towards the new system to be developed. The developer should engage a thorough investigation of the current system before defining requirements and specifications for the next system. Thorough investigation may involve interviewing the management and the operational staff, also by direct observation and experience on the system. A set of requirements and specifications, this means the additional functionalities that the new system needs, interfaces, etc.; performance standards, this means levels of system service in terms of quantity, quality, efficiency, effectiveness of the new system; social and technical requirements, this involves system architecture, architectural designs, the languages that the developer will utilize to capture the need of the client. However, the most critical thing in this stage is the knowledge of the end user or the intended user of the system and the effective interpretation of their needs by the developer or the system professional who deals all of these processes. Achieving correct interpretation requires the end user interest and values, and making amicable resolutions which largely meets the interest of both parties.
Pedro on the other hand has also the point which is to have requirements phase, specification analysis before they examine what portion of the system to salvage if they wish. To develop a system, one cannot jump directly to hard coding of the system, the development involves series of documentation to be done prior an implementation phase is made. Pedro mentioned listing of requirements; it is actually the very first phase in the life cycle of a system which covers 2% of the whole development. This phase’ goal is to explore and refine the concept of the system, as result requirements are being elicited. Moreover, in this phase the client outlines the product as he conceptualizes it. From the viewpoint of the developer, the client’s description of the desired product may be vague, unreasonable, contradictory, or simply impossible to achieve. The task of the task of the developer at this stage is to determine exactly what the client needs and to find out from the client what constraints exist. The second thing to do as what Pedro mean in his statement is Specification (analysis) phase, which cover 5% of the total development of the project. This phase is sometimes called “analysis phase”. At the end of this phase, a plan is drawn, the Software Project Management Plan (SPMP), describing the project in detail. Besides, the document includes the functional requirements. In this manner there is a formal project requirements elicitation close-out, requirements set by the client are finalized in the paper. Since there is a close-out if there are changes of the functionalities in the middle of the development then it should de dealt accordingly. In this manner also, you can formalize the functional requirements of the project so the developer can assess how the system should work an in times of examining the old system the developer can see which data, related functionalities will be saved. The idea can be of help to the developer since they will no be working the system “from a scratch”, instead they can make some enhancement for they already know the requirements that has been elicited prior the examination.
Software professionals are also human and therefore sometimes make error especially if requirements needed are not clearly defined. As a result, there will be fault in the system. If the error is made during the requirement phase, then the resulting fault probably will appear in the specifications, design, and most probably in the code. Clearly, the earlier we correct the error, the better. Because if the client discover fault later if the product has been delivered and deployed, cost may be another issue between the developer and to the client. Furthermore, sometimes you don not have to constrain yourself in old systems because not all system can be intermingled with the other program in the sense that some data cannot be migrated to the other system might be that they are using different technology. Also, the old system is not capable to work and cater the need of the client if intermingled with the new system. However, according to Stephen Schach, “up to now, everything seems to be straightforward. Unfortunately, the requirements elicitation phase is inadequately performed”. Reasons may include, the client may not truly understand what is going on in the organization, the client cannot clearly define the functional requirements that involve the operations in the organization. It is therefore hard for a developer to visualize the project when the client himself is not clearly defining the project as to the functional and non-functional requirements of the system. If that is the case then prototyping can be used until such the client is satisfied that the developer has finally captured the system they desired.
In my own notion, I would like to propose the idea of Pedro Peter. Ideally, Pedro is following the ideal stages that a system should undergo prior any implementation is being made. A system should undergo, a hard copy or the technical paper for the developer to finalize what is to develop and what is not.
No Response to "SAD 1 Assignment 6"
Post a Comment