In a personal experience, it already follows that when you enter college you also go through wild imaginings. I have been into many sleepless nights. But regardless the facts that I am undergoing a little bit soul searching at this moment, projects are becoming much more manageable since I realize things that need to be realized.
Days seemed to pass unnoticeable. I still sleep late at night and woke up early in the morning. But I can’t find any reason to complain. And as exhausted as I am, I still have no regrets. It still amazes me because despite all of these I am still more willing to do the work.
Tuesday, March 24, 2009
Tuesday, March 17, 2009
be inspired guyzz....
I have been good in making intuition. Past weeks where one of the days I don’t want to remember. It makes me feel more exhausted knowing the fact that end of the semester is fast approaching and I can still not see a little progress in our requirements. But this day is different, I smell hope. Well, I see some light; it’s the light that reminds me that God is giving me path to walk now. Things are slowly going to the right track. I know time will come that the sufferings will soon be rewarded.
Seeing some groups losing their hope makes us more enthusiastic in finishing what we have started. Funny are the things that keep us strong. We never let ourselves feel we are tired because the more we accept the thought the more exhausted will become. Yes, as eager as we are we always tell ourselves that we can do even more (despite of deadlines). And for this, we find each other that we can make it and that’s there is no limits to what we can accomplish. For God never get tired of guiding us and sir RSG never get tired of reminding us that we can do better than what we expected.
Yesterday, after series of interviews we realize that when you have the will to make it, it keeps you going. Now, our group is now on the road of making these things happen. As long as the desire is there, we can do it. We never get tired and we never will. Mahuman ra lagi ni..Salig lng ta kang BRO…
I just want to be an inspiration to my other colleagues. Be inspired guys…
Seeing some groups losing their hope makes us more enthusiastic in finishing what we have started. Funny are the things that keep us strong. We never let ourselves feel we are tired because the more we accept the thought the more exhausted will become. Yes, as eager as we are we always tell ourselves that we can do even more (despite of deadlines). And for this, we find each other that we can make it and that’s there is no limits to what we can accomplish. For God never get tired of guiding us and sir RSG never get tired of reminding us that we can do better than what we expected.
Yesterday, after series of interviews we realize that when you have the will to make it, it keeps you going. Now, our group is now on the road of making these things happen. As long as the desire is there, we can do it. We never get tired and we never will. Mahuman ra lagi ni..Salig lng ta kang BRO…
I just want to be an inspiration to my other colleagues. Be inspired guys…
Saturday, March 7, 2009
prototyping....
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.
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.
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.
Subscribe to:
Posts (Atom)