Prototyping allows the users to try out a working model of a system before the actual system is complete. Explain how prototyping can be counterproductive if it creates task interference during training.
A prototype typically simulates only a few aspects of the features of the final program, and may be completely different from the final implementation. The usual purpose of prototyping is to allow the users of the system to evaluate developers’ proposals for the design of the final product by essentially trying them out, rather than having to understand and assess the design based on descriptions. It can also be used by end users to describe and prove requirements that developers have not considered, so controlling the prototype can be a key factor in the commercial relationship between providers and their clients.
Prototyping can be a big help since when it is made software and implementer can obtain feedback from the user early in the project. It allows the software engineer some insight into the accuracy of initial project estimates and whether the deadlines and milestones proposed can be successfully met and if it matches the software specification.
Prototyping can improve the quality of requirements and specifications provided to developers. Because changes cost exponentially more to implement as they are detected later in development. Because the early determination of what the user really wants can result in faster and less expensive software.
But despite the fact that prototyping improves and increases user involvement it can somehow produce problems or difficulties instead of helping to achieve a goal especially when it creates task obstruction during training. It can create insufficient analysis since focusing on a limited prototype can distract developers from properly analyzing the complete project. This can lead to overlooking better solutions, preparation of incomplete specifications or the conversion of limited prototypes into poorly engineered final projects that are hard to maintain.
A key property to prototyping is the fact that it is supposed to be done quickly. If the developers lose sight of this fact, they very well may try to develop a prototype that is too complex. User can become stuck in debates over details of the prototype, holding up the development team and delaying the final project.
Saturday, March 7, 2009
who is responsible if the component fails?
If one person has written a component but others have revised it, who is responsible if the component fails? What are the legal and ethical implications of reusing someone else’s component?
Some scenarios these days are copying others work with or without the authors’ knowhow. But sometimes it leads to failure of a component for the fact that incorrect revision takes place. First issue of incorrect revising is not getting the real idea of the original author. But who’s to be blame when such things happen? Is it in the side of the original author or the one who revised it? Sometimes we revised work in order for us to correct, update and improve the original text but usually we lack analysis and better perception of the point of the original component.
When we revised someone else’s component, we come to different conclusions and update previous estimate in order to make it more accurate or even realistic. But the fact that nothing ends up perfectly makes me apprehend that both of the two (less from the original author and more from the one who revised) are legally responsible for whatever failures occur. Considering the time when the component hasn’t revised yet, we don’t know if it is correctly written and can lead to more errors when revision takes place.
But unauthorized revising of someone else’s component has legal and ethical implications. They say that when a things has been done and done well, take it and copy it without hesitation. As people in a new generation we prefer to believe that improving someone’s work is much easier to do than doing it from scratch. However, revision of others component without the absence of making it perfectly done guarantees the originality of a thought.
Some scenarios these days are copying others work with or without the authors’ knowhow. But sometimes it leads to failure of a component for the fact that incorrect revision takes place. First issue of incorrect revising is not getting the real idea of the original author. But who’s to be blame when such things happen? Is it in the side of the original author or the one who revised it? Sometimes we revised work in order for us to correct, update and improve the original text but usually we lack analysis and better perception of the point of the original component.
When we revised someone else’s component, we come to different conclusions and update previous estimate in order to make it more accurate or even realistic. But the fact that nothing ends up perfectly makes me apprehend that both of the two (less from the original author and more from the one who revised) are legally responsible for whatever failures occur. Considering the time when the component hasn’t revised yet, we don’t know if it is correctly written and can lead to more errors when revision takes place.
But unauthorized revising of someone else’s component has legal and ethical implications. They say that when a things has been done and done well, take it and copy it without hesitation. As people in a new generation we prefer to believe that improving someone’s work is much easier to do than doing it from scratch. However, revision of others component without the absence of making it perfectly done guarantees the originality of a thought.
Which of the following questions might be asked at the preliminary design review? At the critical design review?
You have been hired by a computer consulting firm to develop an income tax calculation package for an accounting firm. You have designed a system according to the customer’s requirements and presented your design at a design review. Which of the following questions might be asked at the preliminary design review? At the critical design review? At both? Explain your answers.
a) What computer will it run on?
b) What will the input screens look like?
c) What reports will be produced?
d) How many concurrent users will there be?
e) Will you use a multiuser operating system?
f) What are the details of the depreciation algorithm?
Under the design review procedures, some firms provide a preliminary and critical design review. In the preliminary design review, the possible questions that might be asked are those factors that need to be considered first in preparation for something of greater size and importance. This includes the physical environment in which locations, equipment functions and environmental restrictions are considered. Other than these are the interface or what will the input screens look alike. Will the input comes from one or more other systems? Is the output going to one or more other systems? Is there described way in which the data must be formatted and is there a prescribed medium that the data must be used?
In the both preliminary and critical design review, user and human factors such as who will use the system and will there be several types of user are also questions that need to be measured. Functionality, resources, security and quality assurance might also be asked. This will help in determining the several mode of operation and when will be the system be changed and enhanced. Skill level of every type of user and what training is required for each type of user are just few questions found in both preliminary and critical review. When you have designed a system you also need to know if how difficult would it be for a user to misuse the system and how easy will it be for the user to understand and use the system. Details of the depreciation algorithm will be asked in either critical or preliminary design review.
Designing a system according to the customer’s requirements are not enough, you need to consider some factors that will ensure the quality of the system.
a) What computer will it run on?
b) What will the input screens look like?
c) What reports will be produced?
d) How many concurrent users will there be?
e) Will you use a multiuser operating system?
f) What are the details of the depreciation algorithm?
Under the design review procedures, some firms provide a preliminary and critical design review. In the preliminary design review, the possible questions that might be asked are those factors that need to be considered first in preparation for something of greater size and importance. This includes the physical environment in which locations, equipment functions and environmental restrictions are considered. Other than these are the interface or what will the input screens look alike. Will the input comes from one or more other systems? Is the output going to one or more other systems? Is there described way in which the data must be formatted and is there a prescribed medium that the data must be used?
In the both preliminary and critical design review, user and human factors such as who will use the system and will there be several types of user are also questions that need to be measured. Functionality, resources, security and quality assurance might also be asked. This will help in determining the several mode of operation and when will be the system be changed and enhanced. Skill level of every type of user and what training is required for each type of user are just few questions found in both preliminary and critical review. When you have designed a system you also need to know if how difficult would it be for a user to misuse the system and how easy will it be for the user to understand and use the system. Details of the depreciation algorithm will be asked in either critical or preliminary design review.
Designing a system according to the customer’s requirements are not enough, you need to consider some factors that will ensure the quality of the system.
How can we demonstrate the reliability of a system that is required never to fail?
Non-functional requirements describe the restriction of the system between systems that limits our choice for constructing a solution to the problem. In systems engineering, non-functional requirements are requirements that specify criteria that can be used to judge the operation of a system rather than specific behaviors. This defines how a system is supposed to be. But how can we demonstrate that these requirements are testable? How can we exhibit the reliability of a system that is required never to fail?
With computers becoming a highly factor nowadays, there is a decisive need to ensure that systems continue to function even when a component fails. The reliability of a system is the probability of failure-free software operation for a specified period of time in a particular environment. Identifying non-functional requirements are also an important factor affecting system reliability. Measurement in software is still in its infancy. No good quantitative methods have been developed to represent software reliability without excessive limitations. Various approaches can be used to improve the reliability of software.
With the advent of the computer age, computers, as well as the software running on them, are playing a vital role in our daily lives. We may not have noticed, but with a continuously lowering cost and improved control, processors and software controlled systems offer compact design, flexible handling, rich features and competitive cost. People used to believe that software never breaks. Without being proven to be wrong, optimistic people would think that once after the software can run correctly, it will be correct forever. A series of tragedies and chaos caused by software proves this to be wrong. These events will always have their place in history.
Software can make decisions, but can just as unreliable as human beings. Fixing problems may not necessarily make the software more reliable. On the contrary, new serious problems may arise. Once perfectly working software may also break if the running environment changes. This makes us wondering whether software is reliable at all, whether we should use software in safety-critical embedded applications.
With computers becoming a highly factor nowadays, there is a decisive need to ensure that systems continue to function even when a component fails. The reliability of a system is the probability of failure-free software operation for a specified period of time in a particular environment. Identifying non-functional requirements are also an important factor affecting system reliability. Measurement in software is still in its infancy. No good quantitative methods have been developed to represent software reliability without excessive limitations. Various approaches can be used to improve the reliability of software.
With the advent of the computer age, computers, as well as the software running on them, are playing a vital role in our daily lives. We may not have noticed, but with a continuously lowering cost and improved control, processors and software controlled systems offer compact design, flexible handling, rich features and competitive cost. People used to believe that software never breaks. Without being proven to be wrong, optimistic people would think that once after the software can run correctly, it will be correct forever. A series of tragedies and chaos caused by software proves this to be wrong. These events will always have their place in history.
Software can make decisions, but can just as unreliable as human beings. Fixing problems may not necessarily make the software more reliable. On the contrary, new serious problems may arise. Once perfectly working software may also break if the running environment changes. This makes us wondering whether software is reliable at all, whether we should use software in safety-critical embedded applications.
Monday, February 16, 2009
It’s all worth it…
VG…wow...For once on my life, I will never forgot that handwritten two letter word. It’s as if my world stops turning. (ana jud na bsta first time…)Consultation is always as terrible as ever. But sir gamboa make us feel comfortable every time we consult him. Perhaps it’s because of our beautiful faces. (paitah!!!)
I think it’s safe to say we all have some heavy feelings these days. Deadlines are already coming. We need to be ready for future breathtaking consultation. Granted that there are days that I think I won’t be able to do it – but I have fallen into a rut of assuming I can’t rather than committing a try. Completing Planning phase was always fun. Maybe it’s a good start. We will just ensure that we will still stay on track.
The relief I feel as I see things put into their place will give me more room to explore and open up a clearer path to where I want to go. How about a round of applause sa atung pogi na teacher???
Honestly, what is it about a thing that brings about this scenario for memories? Well, I think it’s because of the VG.
It’s all worth it…
I think it’s safe to say we all have some heavy feelings these days. Deadlines are already coming. We need to be ready for future breathtaking consultation. Granted that there are days that I think I won’t be able to do it – but I have fallen into a rut of assuming I can’t rather than committing a try. Completing Planning phase was always fun. Maybe it’s a good start. We will just ensure that we will still stay on track.
The relief I feel as I see things put into their place will give me more room to explore and open up a clearer path to where I want to go. How about a round of applause sa atung pogi na teacher???
Honestly, what is it about a thing that brings about this scenario for memories? Well, I think it’s because of the VG.
It’s all worth it…
Saturday, February 14, 2009
Mistakes may be made on the part of the software developers
Mistakes may be made on the part of the software developers or indeed may be made on the part of the entity requiring the software system. So who exactly is responsible when once a system is built and the system harms someone either physically or financially? In developing systems there are many problems that can result from faulty assumption or system failures which are perceptibly made by the development team. A system, which was developed by the collaboration of a costumer and the user, can encounter some important factors that are needed to ensure that the system would do well.
Since developer takes the biggest role in the making of the system, if anything happens, it is his responsibility. It is already by default that once you are a developer you have the great factor that is important contributor to a system failure.
Since some of the user is improperly trained then the likelihood of them making serious errors is increased due to their lack of knowledge of the system. When a system harms someone physically or financially, user should not be held reliable due to lack of training. A user and a costumer who makes a mistake should not be reprimanded for it if they have not been trained to deal with it. When a developer has made the user and costumer well-trained, then the end users will significantly reduce harms and improve the integrity of the systems.
The responsibility for failures caused by many factors falls squarely on the developer responsible for creating and maintaining the software system. As such measures to reduce poor development practices must center on the development team itself.
Since developer takes the biggest role in the making of the system, if anything happens, it is his responsibility. It is already by default that once you are a developer you have the great factor that is important contributor to a system failure.
Since some of the user is improperly trained then the likelihood of them making serious errors is increased due to their lack of knowledge of the system. When a system harms someone physically or financially, user should not be held reliable due to lack of training. A user and a costumer who makes a mistake should not be reprimanded for it if they have not been trained to deal with it. When a developer has made the user and costumer well-trained, then the end users will significantly reduce harms and improve the integrity of the systems.
The responsibility for failures caused by many factors falls squarely on the developer responsible for creating and maintaining the software system. As such measures to reduce poor development practices must center on the development team itself.
Project managers can increase their productivity in a variety of ways
Project managers can increase their productivity in a variety of ways. The most obvious methods involve automation and computerization which minimize the task that must be performed by employees. The growth of productivity – output per unit of input – is the fundamental determinant of the growth of a country’s material standard of living. The most commonly cited measures of productivity are in terms of a unit of size per unit of time. One cannot have sustained growth in output per person.
Regarding the first issue, measuring productivity in terms of number of lines is somehow futile. It is for the reason that different languages can produce different numbers of lines of code. Nowadays, as a programmer who always runs out of time, we typically make line of source codes shorter but concise to make it easier to decode and manage.
Productivity in lines of code cannot also be measured until an implementation starts. It is only generated during the implementation period. Measuring productivity through this kind of way can somehow take no notice of the other phases of development. Simply because we cannot identify its efficiency not until it’s implemented.
But, on the other hand, programmers may structure code to meet productivity goals ineffective because a programmer is already known on manipulating program making it more efficient.
Total productivity is a productivity measure that incorporates all the inputs required to make a product. Thus measuring productivity by means of lines of source codes are not an effective way but inputs could be grouped in several ways as long as they determine the total inputs required to produce an output.
Regarding the first issue, measuring productivity in terms of number of lines is somehow futile. It is for the reason that different languages can produce different numbers of lines of code. Nowadays, as a programmer who always runs out of time, we typically make line of source codes shorter but concise to make it easier to decode and manage.
Productivity in lines of code cannot also be measured until an implementation starts. It is only generated during the implementation period. Measuring productivity through this kind of way can somehow take no notice of the other phases of development. Simply because we cannot identify its efficiency not until it’s implemented.
But, on the other hand, programmers may structure code to meet productivity goals ineffective because a programmer is already known on manipulating program making it more efficient.
Total productivity is a productivity measure that incorporates all the inputs required to make a product. Thus measuring productivity by means of lines of source codes are not an effective way but inputs could be grouped in several ways as long as they determine the total inputs required to produce an output.
expedite implementation of IS plan
You were invited by the university president to prepare an IS plan for the university, discuss what are the steps in order to expedite the implementation of the IS Plan.
Planning an IS plan can somehow complex. If I were to think of steps in order to expedite the implementation of IS plan to ensure that something takes place or dealt with more quickly than usual I would rather take into consideration some factors.
• Project management
We should determine the time to be allotted in order to complete the plan. With this we can utilize time management and other factors concerning schedules. Other than managing time we should also consider who will manage the plan and create planning teams that is capable in planning an IS. Project management must be properly supervised and development practices are also one most significant factor to be considered. We need to better understand the plan so that implementation won’t become more complicated. That is why such issues must be put into consideration.
• Adaption of resources and information
Issues involving data conversion and allocation of resources must also be considered. Proper usage of resources must also be recognized because it might cause several failures, either when it comes to implementation or allocation of data.
• Training people
Training is also the most important factor to be considered. IT staffs that are properly trained will make the project easily done. They need to have knowledge in terms of managing data and IS plan implementation. One of the things that are essential to successful continuous improvement in order to expedite implementation of IS plan are strongly matters on the people involve around the plan.
Planning an IS plan can somehow complex. If I were to think of steps in order to expedite the implementation of IS plan to ensure that something takes place or dealt with more quickly than usual I would rather take into consideration some factors.
• Project management
We should determine the time to be allotted in order to complete the plan. With this we can utilize time management and other factors concerning schedules. Other than managing time we should also consider who will manage the plan and create planning teams that is capable in planning an IS. Project management must be properly supervised and development practices are also one most significant factor to be considered. We need to better understand the plan so that implementation won’t become more complicated. That is why such issues must be put into consideration.
• Adaption of resources and information
Issues involving data conversion and allocation of resources must also be considered. Proper usage of resources must also be recognized because it might cause several failures, either when it comes to implementation or allocation of data.
• Training people
Training is also the most important factor to be considered. IT staffs that are properly trained will make the project easily done. They need to have knowledge in terms of managing data and IS plan implementation. One of the things that are essential to successful continuous improvement in order to expedite implementation of IS plan are strongly matters on the people involve around the plan.
Saturday, February 7, 2009
on a real scenario
On a real scenario, there are only very few software projects which are completed in time. As a student, we are trained to face and focus on what we need to know about risk in the pursuit of delivering software projects. Through this we are practicing our best techniques of risk analysis and to be able to develop the process for various organizations.
When we are in the midst of making a software project we always think a lot of risk like we cannot complete the system and will not meet its user needs. That is why we understand its function better than we could for a successful information system development. During the time of making “so called student projects” we face this kind of risk that has been consistently identified by all.
• Lack of Technical knowledge
Since we usually do the research we don’t have enough information for us to better implement our project effectively. And because we are just a simple student we don’t have enough will power to ask questions and help from the people whom we know has the knowledge.
• High cost of requirements
Being in a world with low cost of living, it is and always a problem for us to acquire high cost requirements. This one can also be the reason for project delay or even the worst.
• Time management
Since we don’t have all the time, making it ours is also a main problem. In a group we usually quarrel when managing our time schedule. Sometimes, since night time is the only moment we can gather ourselves together we usually end up making our projects in a sleepless night leading us to force our self doing projects overtime.
• Unpredictable changes and the lack of will to overcome it
As a student, we usually have the aura of being anxious when it becomes to dealing changes. We always keep on running to changes. In a real scenario, we typically lose self-esteem that we end up losing also our self confidence and the drive to finish project.
• Lack of comprehension
Misunderstanding between group members can also be determined as one of the major risk in making projects. We usually fail to understand or interpret something correctly. Minor disagreement can sometimes lead to project failure.
Since risk are everywhere we need to make it part of our own. If we are fugitive when we encounter it, if we have used our strength in fleeing it will surely prevail. But if we do the seeking we will be able to destroy it. If we want to cease being hunted, we must become the hunter.
When we are in the midst of making a software project we always think a lot of risk like we cannot complete the system and will not meet its user needs. That is why we understand its function better than we could for a successful information system development. During the time of making “so called student projects” we face this kind of risk that has been consistently identified by all.
• Lack of Technical knowledge
Since we usually do the research we don’t have enough information for us to better implement our project effectively. And because we are just a simple student we don’t have enough will power to ask questions and help from the people whom we know has the knowledge.
• High cost of requirements
Being in a world with low cost of living, it is and always a problem for us to acquire high cost requirements. This one can also be the reason for project delay or even the worst.
• Time management
Since we don’t have all the time, making it ours is also a main problem. In a group we usually quarrel when managing our time schedule. Sometimes, since night time is the only moment we can gather ourselves together we usually end up making our projects in a sleepless night leading us to force our self doing projects overtime.
• Unpredictable changes and the lack of will to overcome it
As a student, we usually have the aura of being anxious when it becomes to dealing changes. We always keep on running to changes. In a real scenario, we typically lose self-esteem that we end up losing also our self confidence and the drive to finish project.
• Lack of comprehension
Misunderstanding between group members can also be determined as one of the major risk in making projects. We usually fail to understand or interpret something correctly. Minor disagreement can sometimes lead to project failure.
Since risk are everywhere we need to make it part of our own. If we are fugitive when we encounter it, if we have used our strength in fleeing it will surely prevail. But if we do the seeking we will be able to destroy it. If we want to cease being hunted, we must become the hunter.
Subscribe to:
Posts (Atom)