Question:
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?
The Preliminary Design Review (PDR) is a formal inspection of the high-level architectural design of an automated system and its software, which is conducted to achieve confidence that the design satisfies the functional and nonfunctional requirements and is in conformance with CMS' enterprise architecture. Overall project status, proposed technical solutions, evolving software products, and associated documentation are reviewed at a high level to determine completeness and consistency with CMS standards, to raise and resolve any technical and/or project-related issues, and to identify and mitigate project, technical, security, and/or business risks affecting continued detailed design and subsequent development, testing, implementation, and operations & maintenance activities. http://www.cms.hhs.gov/SystemLifecycleFramework/Downloads/PDR.pdf
From the above definition PDR must be conducted to ensure that the automated system or application being designed is in conformance with CMS' enterprise architecture and design standards. It involves scientific and technical objectives of the system. A detailed information and overall system design covering all aspects (electronic, mechanical, software) of the project or even the preliminary designs (block diagrams). For the instrument being used there should be a detailed interface specification between the hardware and software. Detailed budget and project plan and most of all major areas of risk and risk mitigation plans.
All the questions above are being discussed in the PDR stage because all the questions above involves reviewing the specific plans of the project, and should be conducted before any significant acquisitions or fabrication begins, and before any finalizations are produced. Budget and project plans should be refined and agreed to.
The question above implies are for the future implementation, it implies before the system should be design. Those questions are for PDR because it expresses before the fabrication of the system.
The CDR is generally intended to evaluate the proposed final designs, sometimes including constructed prototype modules or subsystems, but prior to commitment to final production. https://safe.nrao.edu/wiki/bin/view/GBT/ProjectReviews
As what I understand from above definition, CDR is for final polishing from the PDR stage of your system. It will just evaluate the proposed final designs. It will not touch those questions being tackled at the PDR stage. CDR is for ensuring if the system achieves the requirements being discussed during their PDR stage.
Thursday, February 19, 2009
Activity4a_SE1
Question:
Among the many nonfunctional requirements that can be included in a specification are those related to safety and reliability. How can we demonstrate that these requirements are testable? How can we demonstrate the reliability of a system that is required never to fail?
Non-functional requirements are requirements that specify criteria that can be used to judge the operation of a system, rather than specific behaviors. This should be contrasted with functional requirements that specify specific behavior or functions. In general, functional requirements define what a system is supposed to do whereas non-functional requirements define how a system is supposed to be. Non-functional requirements are often called qualities of a system. http://en.wikipedia.org/wiki/Non-functional_requirement
From the definition above, Non-functional requirements are the most critical factor in the success of your project. Without including it in your specification, your system will not be reliable enough and not secured to use.
In the question of how can we demonstrate that these requirements are testable? Is the same way of answering of how we can demonstrate the reliability of the system? The answer is to fully document both the functional and non-functional requirements. Both play different rules but of the same weight, I guess, because without the presence of one of the requirements in your system, it will definitely not work. Maybe that’s the main reason why functional and non-functional are included in developing a system because both are important in the completion of a project.
The main factor to consider in doing it is to have a better understanding of the performance your system and the usability of your system. One needs to study and have knowledge in documenting these requirements because without any knowledge of how it should be gathered or start with is useless. One needs to have a better and deep understanding about it. How can one or your group test your system without having it studied furthered?
The reliability and safety of you system depend on who develop the system. Who gathers the data needed and who list the requirements of the system. The group must have a root analysis in everything they do. It’s very important especially when you want your system to be on its peak when it will be implemented.
Among the many nonfunctional requirements that can be included in a specification are those related to safety and reliability. How can we demonstrate that these requirements are testable? How can we demonstrate the reliability of a system that is required never to fail?
Non-functional requirements are requirements that specify criteria that can be used to judge the operation of a system, rather than specific behaviors. This should be contrasted with functional requirements that specify specific behavior or functions. In general, functional requirements define what a system is supposed to do whereas non-functional requirements define how a system is supposed to be. Non-functional requirements are often called qualities of a system. http://en.wikipedia.org/wiki/Non-functional_requirement
From the definition above, Non-functional requirements are the most critical factor in the success of your project. Without including it in your specification, your system will not be reliable enough and not secured to use.
In the question of how can we demonstrate that these requirements are testable? Is the same way of answering of how we can demonstrate the reliability of the system? The answer is to fully document both the functional and non-functional requirements. Both play different rules but of the same weight, I guess, because without the presence of one of the requirements in your system, it will definitely not work. Maybe that’s the main reason why functional and non-functional are included in developing a system because both are important in the completion of a project.
The main factor to consider in doing it is to have a better understanding of the performance your system and the usability of your system. One needs to study and have knowledge in documenting these requirements because without any knowledge of how it should be gathered or start with is useless. One needs to have a better and deep understanding about it. How can one or your group test your system without having it studied furthered?
The reliability and safety of you system depend on who develop the system. Who gathers the data needed and who list the requirements of the system. The group must have a root analysis in everything they do. It’s very important especially when you want your system to be on its peak when it will be implemented.
Wednesday, February 18, 2009
Activity 3b_SE1
Developers work together with customers and users to define requirements and specify what the proposed system will do. If, once it is built, the system works according to the specification but harms someone physically or financially, who is responsible?
If in case it would happen, there is no need to blame someone in particular because in the first place it’s a group project and everyone is responsible with each other and you yourself must also know how to take good care of yourself. When the group was starting the project you knew that maybe in the long run, the group may encounter some problems or even accident. Prepare yourself for it. Accidents happen in no specific time, place or even season. So, everyone should be responsible and think that maybe if it would happen, the problem was in the group itself. Maybe the group lack something while doing the system or maybe forgot to set first safety precautions as the project was pursued.
While the group was doing the project, everybody doesn’t give any deep or advance study to what the outcome would be. Risk Analysis must be tackled here and should bare in mind to each member that it should be studied thoroughly (from Tangible and Non-Tangible Assets) and while the project is on the process of developing the group must set some Safety Precautions or Recommended Control to avoid some of the risk that the group may encounter, so that as the system will be implemented then the risk or any problems has enough remedy or get rid someone to be a victim of any unnecessary effect to their health, money, emotional or even physical.
In the long run, it’s a group project and each member is responsible of what they are doing and set in mind the safety of the group or individual before anything else. Everyone is responsible of what may the outcome be.
In the part of the customer, there are just imparting or lending what the group wants them to have. So customer here has nothing to do with the system because customer has no idea of what those codes are for. They are just expressing their desire to what they want the system should be and pays the necessary bills. The full responsibility of the situation is on the part of the group who accepted the project. They should know what they are doing and take some legal, right and deep study for any actions they would do.
If in case it would happen, there is no need to blame someone in particular because in the first place it’s a group project and everyone is responsible with each other and you yourself must also know how to take good care of yourself. When the group was starting the project you knew that maybe in the long run, the group may encounter some problems or even accident. Prepare yourself for it. Accidents happen in no specific time, place or even season. So, everyone should be responsible and think that maybe if it would happen, the problem was in the group itself. Maybe the group lack something while doing the system or maybe forgot to set first safety precautions as the project was pursued.
While the group was doing the project, everybody doesn’t give any deep or advance study to what the outcome would be. Risk Analysis must be tackled here and should bare in mind to each member that it should be studied thoroughly (from Tangible and Non-Tangible Assets) and while the project is on the process of developing the group must set some Safety Precautions or Recommended Control to avoid some of the risk that the group may encounter, so that as the system will be implemented then the risk or any problems has enough remedy or get rid someone to be a victim of any unnecessary effect to their health, money, emotional or even physical.
In the long run, it’s a group project and each member is responsible of what they are doing and set in mind the safety of the group or individual before anything else. Everyone is responsible of what may the outcome be.
In the part of the customer, there are just imparting or lending what the group wants them to have. So customer here has nothing to do with the system because customer has no idea of what those codes are for. They are just expressing their desire to what they want the system should be and pays the necessary bills. The full responsibility of the situation is on the part of the group who accepted the project. They should know what they are doing and take some legal, right and deep study for any actions they would do.
Activity 3a_SE1
Question:
Many project managers plan their schedules based on the programmer productivity on past projects. This productivity is often measured in terms of a unit of size per unit of time. For example, an organization may produce 300 lines of code per day or 1200 application points per month. Is it appropriate to measure productivity in this way? Discuss the measurement of productivity in terms of the following issues:
• Different languages can produce different numbers of lines of code for implementation of the same design
• Productivity in lines of code cannot be measured until implementation begins.
• Programmers may structure code to meet productivity goals.
According to what I have read: http://www.kimbly.com/blog/000067.html , this was based on her experience that what matters most when you want a programmers productivity be good is that you must consider so many factors:
1.) First, the fewer developers in the group, the better.
2.) Second, distractions must be minimized.
3.) Third, history and familiarity with the code is very important.
4.) Fourth, management is important.
5.) Fifth, productivity has ceased to improve noticeably over time.
So, what mention above was the factors that a programmer should consider while producing lines of codes. There are only two kinds of programmers in the world: a poor programmer and a good one. But even if a programmer is good, the field of expertise varies. What if she/he is only good in one particular PL? What if she/he needs good environment to do it? A programmer’s productivity I think varies on:
1.) Environment
2.) Field of Expertise
3.) Programming Language being used
4.) Flexibility
5.) Accuracy and efficiency of the code
It is not necessary of who writes code more or less, what important is the accuracy and efficiency of the code and if he/she meets the goal of creating it.
I think we cannot measured once productivity in terms of code because lines of codes doesn’t speak of the programmers capabilities, what more important and should take into consideration is the efficiency and accuracy of the codes. Programmers has many ways on how to interpret into lines of codes certain problems, so what a programmers should have is to produce a good quality of codes in lay mans term, easy to debug and is concise.
Many project managers plan their schedules based on the programmer productivity on past projects. This productivity is often measured in terms of a unit of size per unit of time. For example, an organization may produce 300 lines of code per day or 1200 application points per month. Is it appropriate to measure productivity in this way? Discuss the measurement of productivity in terms of the following issues:
• Different languages can produce different numbers of lines of code for implementation of the same design
• Productivity in lines of code cannot be measured until implementation begins.
• Programmers may structure code to meet productivity goals.
According to what I have read: http://www.kimbly.com/blog/000067.html , this was based on her experience that what matters most when you want a programmers productivity be good is that you must consider so many factors:
1.) First, the fewer developers in the group, the better.
2.) Second, distractions must be minimized.
3.) Third, history and familiarity with the code is very important.
4.) Fourth, management is important.
5.) Fifth, productivity has ceased to improve noticeably over time.
So, what mention above was the factors that a programmer should consider while producing lines of codes. There are only two kinds of programmers in the world: a poor programmer and a good one. But even if a programmer is good, the field of expertise varies. What if she/he is only good in one particular PL? What if she/he needs good environment to do it? A programmer’s productivity I think varies on:
1.) Environment
2.) Field of Expertise
3.) Programming Language being used
4.) Flexibility
5.) Accuracy and efficiency of the code
It is not necessary of who writes code more or less, what important is the accuracy and efficiency of the code and if he/she meets the goal of creating it.
I think we cannot measured once productivity in terms of code because lines of codes doesn’t speak of the programmers capabilities, what more important and should take into consideration is the efficiency and accuracy of the codes. Programmers has many ways on how to interpret into lines of codes certain problems, so what a programmers should have is to produce a good quality of codes in lay mans term, easy to debug and is concise.
Activity 2c_SE1
Even on your student projects, there are significant risks to your finishing your project time. Analyze the making of a student software development project and list the possible risks. What techniques can you use to mitigate each risk?
Risks are spices of life and since we are living, we will experience risk and we need to overcome it. Risks are part of a project to test the efficiency of the project. Below are the lists of risks that the group will encounter.
Project Risks:
1.) Tangible Assets:
a. Hardware = processor, monitors etc.
b. Data = data from developing the project
c. Documentations = back-ups
d. Supplies = materials needed
e. Software = data, applications. programs
f. Money = budget
2.) Additional Assets:
a. Infrastructure = where the project will lend
b. condition of the environment = calamities
Non-Tangible People Risks:
1.) Employee Turnover = quit leaving of a member
2.) Changing Requirements = late to realize something
3.) Attitudes = professionalism and unity
Mitigation:
Project Risks:
1.) Tangible Assets:
Hardware needs to fit the requirements needed for the project to avoid overloaded that may fail you pc’s hardware. Data needed must be in safe to avoid deleted, software must be kept well if in case it would be stolen or pirated, documents needs back-ups if incase it will be lost while in supplies and money it needs to have sufficient budget for the materials and for other purposes.
2.) Additional Assets:
It must also be included in order to the project to be implemented successfully. Secure the area where your group wants the project to reside.
3.) People Risk:
It talks more on the attitude towards the project and each member. The materials, budget and secured environment are useless if each member has misunderstanding and never work as a team. More risks are to be encounter.
All this tangible and non-tangible assets are to be considered since it is badly needed in the completion of the project. To mitigate this is to prevent those things to happen. Be responsible in all you do and think of possible ways to never overcome those things. Everyone should be prepared and think of the best project to make to not complicate things more.
Risks are spices of life and since we are living, we will experience risk and we need to overcome it. Risks are part of a project to test the efficiency of the project. Below are the lists of risks that the group will encounter.
Project Risks:
1.) Tangible Assets:
a. Hardware = processor, monitors etc.
b. Data = data from developing the project
c. Documentations = back-ups
d. Supplies = materials needed
e. Software = data, applications. programs
f. Money = budget
2.) Additional Assets:
a. Infrastructure = where the project will lend
b. condition of the environment = calamities
Non-Tangible People Risks:
1.) Employee Turnover = quit leaving of a member
2.) Changing Requirements = late to realize something
3.) Attitudes = professionalism and unity
Mitigation:
Project Risks:
1.) Tangible Assets:
Hardware needs to fit the requirements needed for the project to avoid overloaded that may fail you pc’s hardware. Data needed must be in safe to avoid deleted, software must be kept well if in case it would be stolen or pirated, documents needs back-ups if incase it will be lost while in supplies and money it needs to have sufficient budget for the materials and for other purposes.
2.) Additional Assets:
It must also be included in order to the project to be implemented successfully. Secure the area where your group wants the project to reside.
3.) People Risk:
It talks more on the attitude towards the project and each member. The materials, budget and secured environment are useless if each member has misunderstanding and never work as a team. More risks are to be encounter.
All this tangible and non-tangible assets are to be considered since it is badly needed in the completion of the project. To mitigate this is to prevent those things to happen. Be responsible in all you do and think of possible ways to never overcome those things. Everyone should be prepared and think of the best project to make to not complicate things more.
activity 2b_SE1
Many studies indicate that two of the major reasons that a project is late are changing requirements and employee turnover. Discuss this projection and state real world scenarios.
Well, based on my experience especially group project at school (presently, I will not mention the subject), group project start at team building and set some rules, boundary and assigned task evenly and just. After which of creating a team, the team will decide of what project should be implemented. For those two activities alone, it will consume time and be deducted to the time allotted for them to do the project.
As the team agreed to pursue the project and start developing it (long journey starts), then the time come that the group will realize that they don’t want the project anymore and change to another one because maybe they are starting to face those complications which the group can’t solve or later realize that its not worth it and need some big revision (start all over again), perhaps the subject teacher don’t want it and decide that the group must change. So many reasons why members of the group suddenly change their project or change requirements to fully fit what the teacher wants and what are needed factors to consider external and internal.
In employee turnover it talks more to the member of the group. From the start, the group was made and members were there and fixed. Suddenly after the groups has been made and take the long journey, theirs a sudden twist of fate, a group member has to leave, quit or take into vacation (emergency purposes). So what will happen when the group lost a member or two, while in the first place they were a group who made and decide this project? So, it means that they will have only two options: to have another one or to still continue without the presence of the one member?
With these options, both needed a lot of time. Regarding to the first option, the group needs to recruit another member which they will have to orient since the person is new, while with the second option, no hard experience in finding one but surely well get even complicated since they’ve lost one member and the part or task of that member will be a big burden for them.
Well, based on my experience especially group project at school (presently, I will not mention the subject), group project start at team building and set some rules, boundary and assigned task evenly and just. After which of creating a team, the team will decide of what project should be implemented. For those two activities alone, it will consume time and be deducted to the time allotted for them to do the project.
As the team agreed to pursue the project and start developing it (long journey starts), then the time come that the group will realize that they don’t want the project anymore and change to another one because maybe they are starting to face those complications which the group can’t solve or later realize that its not worth it and need some big revision (start all over again), perhaps the subject teacher don’t want it and decide that the group must change. So many reasons why members of the group suddenly change their project or change requirements to fully fit what the teacher wants and what are needed factors to consider external and internal.
In employee turnover it talks more to the member of the group. From the start, the group was made and members were there and fixed. Suddenly after the groups has been made and take the long journey, theirs a sudden twist of fate, a group member has to leave, quit or take into vacation (emergency purposes). So what will happen when the group lost a member or two, while in the first place they were a group who made and decide this project? So, it means that they will have only two options: to have another one or to still continue without the presence of the one member?
With these options, both needed a lot of time. Regarding to the first option, the group needs to recruit another member which they will have to orient since the person is new, while with the second option, no hard experience in finding one but surely well get even complicated since they’ve lost one member and the part or task of that member will be a big burden for them.
Activity 2a_SE1
Question:
Explain why it takes longer to develop a utility program than an application program and longer still to develop a system program.
Let’s first define what are a utility program and an application program. A utility program is a systems program designed to perform a specific task related to the operation of the computer when requested to do so by the computer user. An application program is an application program (sometimes shortened to application) is any program designed to perform a specific function directly for the user or, in some cases, for another application program.
From the definition above it is clearly stated what are their distinctions, to further understand it lets have some examples with utility program and application program, utility can either be used to complete a screen dump, format a disk, or convert the format of a data file so that it can be accessed by a different applications program. Application program examples are: word processors; database programs; Web browsers; development tools; drawing, paint, and image editing programs; and communication programs.
So from the statement above, utility takes longer development compare to an application program because application program was developed for a specific purpose or by request, it was designed to help people perform a certain type of work, while a utility program caters all factors needed by the user and an application program to work even the computer’s hardware and operating system. Utility performs maintenance or general-purpose chores.
The more complex and complicated the function of software is, the more it needs longer time to develop because it needs to be studied further and consider different factors and large scope.
Explain why it takes longer to develop a utility program than an application program and longer still to develop a system program.
Let’s first define what are a utility program and an application program. A utility program is a systems program designed to perform a specific task related to the operation of the computer when requested to do so by the computer user. An application program is an application program (sometimes shortened to application) is any program designed to perform a specific function directly for the user or, in some cases, for another application program.
From the definition above it is clearly stated what are their distinctions, to further understand it lets have some examples with utility program and application program, utility can either be used to complete a screen dump, format a disk, or convert the format of a data file so that it can be accessed by a different applications program. Application program examples are: word processors; database programs; Web browsers; development tools; drawing, paint, and image editing programs; and communication programs.
So from the statement above, utility takes longer development compare to an application program because application program was developed for a specific purpose or by request, it was designed to help people perform a certain type of work, while a utility program caters all factors needed by the user and an application program to work even the computer’s hardware and operating system. Utility performs maintenance or general-purpose chores.
The more complex and complicated the function of software is, the more it needs longer time to develop because it needs to be studied further and consider different factors and large scope.
Saturday, February 7, 2009
Reflection (Proposal & Consultation)_Assign.6A[SAD1]
Regarding with our proposed system its kinda hard for the first place, because we have gone and wasted so much time just for our system to be approved by our Professor (really!) but actually as we go along we've realized that what are professor wants was something that could help our Institute or might as well our University. It took us so long to decide before we've come up to this idea. Our group proposed the Online USEP Academic Organization Updates which caters more on organizational issues. Our proposed system is somewhat could be compared to the BBS (Bulletin Board System) way back in 1990's. But we are happy that we have come up to this idea since our CCO (Campus Club Organization) have no official site. By this system, we could not only help them to save budget but also we could make CCO and other organizations under their provision, be organize. So far, we are now starting with our documentations.
So much for our proposed system, lets find out what are the emotions towards during our consultation (I'm starting to sweat) ... mmmm.... To start with, during our consultation to have approval for our proposed system it was a bad experience, since this is our first time to be with Dr. Gamboa (me and lizyl - my groupmate) and regarding with the group status during consultation its our first time to have a consultation with Dr. Gamboa. So you see, its so hard.. We really don't know where and when to start. We don't know his rules for consultation (very strict when it comes in disobeying his rules what more on consultation)... hehehehe... As we have our first consultation with him, we are so afraid (that even the AC at faculty room didn't have any effect on us, to think also that there are some faculty staying at their respective tables), but we have no choice but to have our consultation. At first, it was hard, Dr. Gamboa really wants idea (brilliant) coming from the group. He wants you to speak up and defend your system, he wants to know your standing. Its really a battle. Sad to say, our first proposed system was not approved by our Prof.(in a sense that it was a common system (jurasic) as what he describe it)... hehehe.. so we have to find another one and think again. Before our latest proposed system was approved by our Dr. Gamboa, we actually defended our first choice system which was Enrollment and Payroll System but Sir really wants something new that we think could help our department and the University as well, he wants us to think of another system that could satisfy and justify our selves and the course were into.
Presently, we have this new system that caters organizational issues and it was approved and accepted by our Professor. He likes it, he likes what he is seeing to us. We have grown up and we are at the Intellectual Stage (as what he said)...
So much for our proposed system, lets find out what are the emotions towards during our consultation (I'm starting to sweat) ... mmmm.... To start with, during our consultation to have approval for our proposed system it was a bad experience, since this is our first time to be with Dr. Gamboa (me and lizyl - my groupmate) and regarding with the group status during consultation its our first time to have a consultation with Dr. Gamboa. So you see, its so hard.. We really don't know where and when to start. We don't know his rules for consultation (very strict when it comes in disobeying his rules what more on consultation)... hehehehe... As we have our first consultation with him, we are so afraid (that even the AC at faculty room didn't have any effect on us, to think also that there are some faculty staying at their respective tables), but we have no choice but to have our consultation. At first, it was hard, Dr. Gamboa really wants idea (brilliant) coming from the group. He wants you to speak up and defend your system, he wants to know your standing. Its really a battle. Sad to say, our first proposed system was not approved by our Prof.(in a sense that it was a common system (jurasic) as what he describe it)... hehehe.. so we have to find another one and think again. Before our latest proposed system was approved by our Dr. Gamboa, we actually defended our first choice system which was Enrollment and Payroll System but Sir really wants something new that we think could help our department and the University as well, he wants us to think of another system that could satisfy and justify our selves and the course were into.
Presently, we have this new system that caters organizational issues and it was approved and accepted by our Professor. He likes it, he likes what he is seeing to us. We have grown up and we are at the Intellectual Stage (as what he said)...
Subscribe to:
Posts (Atom)