I start by rating each coders “effective productivity” where for an hour worked, how much time/code actually gets generated. Some will be.5:1 if they have to stop frequently to answer questions, some will be at.75:1 if they code well, know what they need to do and are stationed in a broom closet so they aren’t interrupted, some will be.25:1 or even.1:1 because they are an intern or a new recruit.
Then I consider how long it will take to produce each section of the product (just broken down into logical groups) in a “perfect world” where everyone is coding at 1:1. I then apply each members effective productivity to that time for each logical group. I then add 20%-40% to each individual module I broke it down into, depending on how complete the requirements, specifications, etc are going into that module where 20 is better, 40 is worse (usually). So if I had five modules, time of each would expand by at minimum 20%+ the expansion of the effective productivity of those working on it. Then add all the time up, add 30% for testing then 20% buffer and you’ll find, surprisingly, you’re stabbing at a number that is as realistic as you can make it this early in the game. You also have a number that can be presented to those outside of IT and, dressed up with the math, presents an estimate that is based on real numbers and is quite hard to argue with. Ultimately, it’s a more formalized SWAG, all programming estimates have Some Wild Ass Guess in them though, as quantifying the time involved in being creative is quite hard to do.
Kohath / Techno-vampire commented "IT people setup security that's needlessly inconvenient".
A paper from HotSec '07 http://www.usenix.org/event/hotsec07/tech/full_papers/florencio/florencio.pdf titled "Do Strong Web Passwords Accomplish Anything?" addresses the principal of requiring users to use ridiculously strong passwords. In practice, this tends to have the adverse effect by making systems too cumbersome to log into and passwords that are so hard to remember they are often written down. How strong do passwords need to be in order to be effective? The paper argues (and the math confirms) that even relatively weak passwords (20 bits) when used with password rotation and "three strike" policies are enough to make brute-force attacks on a single account unrealistic.
My employers previous user/pass policy was mixed case, 8 char min, #'s and punctuation requirement, with 90 day rotation and three-strikes - BUT the username was made public, so only 1/2 the credential pair was private. My approach was to make both the user and the pass non-public, keep the rotation & three-strike policy and reduce the complexity requirement of the password slightly. The result puts more of the security burden on the systems and less on the users (by not having to remember complex passwords). This results in higher overall security of credential pairs and made the userâ(TM)s daily experience easier and less cumbersome.
Keyboard -> motherboard -> jump to ground, no, but the system as a whole (not the u fluctuations of the individual components there in) was (this was early 90's) be detectable. Not detectable in the "1011011 = exact data sequence" sense of the word but in a active/inactive "is the keyboard in use" sense... sure.
While it is "bogus" in that there is no new information here, it isn't bogus in the sense that it can't be done. When I was getting my EE, I was able to do a POC with nothing more than a bread board and an oscilloscope. In conjunction with using a laser to pull sound off windows (used by the CIA also) the possibilities with serious funding are truly endless.
While working for the USAF developing a PTT (Part Task Trainer) for the new "glass cockpit" on KC-135R Aerial Refueler, my coding partner and I worked at the largest non-commercial airport in the US. Our office was a 6x9 closet. We were located by the fuel station, so every afternoon when the news choppers and flight for life choppers would refuel, the ventilation system pumped AvGas directly into the "office". It would get so bad that we would have to stop working from 3-5. After attempting to work through it at first, we would get dizzy from the fumes.
Slashdot Mirror
I start by rating each coders “effective productivity” where for an hour worked, how much time/code actually gets generated. Some will be .5:1 if they have to stop frequently to answer questions, some will be at .75:1 if they code well, know what they need to do and are stationed in a broom closet so they aren’t interrupted, some will be .25:1 or even .1:1 because they are an intern or a new recruit.
Then I consider how long it will take to produce each section of the product (just broken down into logical groups) in a “perfect world” where everyone is coding at 1:1. I then apply each members effective productivity to that time for each logical group. I then add 20%-40% to each individual module I broke it down into, depending on how complete the requirements, specifications, etc are going into that module where 20 is better, 40 is worse (usually). So if I had five modules, time of each would expand by at minimum 20%+ the expansion of the effective productivity of those working on it. Then add all the time up, add 30% for testing then 20% buffer and you’ll find, surprisingly, you’re stabbing at a number that is as realistic as you can make it this early in the game. You also have a number that can be presented to those outside of IT and, dressed up with the math, presents an estimate that is based on real numbers and is quite hard to argue with. Ultimately, it’s a more formalized SWAG, all programming estimates have Some Wild Ass Guess in them though, as quantifying the time involved in being creative is quite hard to do.
Kohath / Techno-vampire commented "IT people setup security that's needlessly inconvenient". A paper from HotSec '07 http://www.usenix.org/event/hotsec07/tech/full_papers/florencio/florencio.pdf titled "Do Strong Web Passwords Accomplish Anything?" addresses the principal of requiring users to use ridiculously strong passwords. In practice, this tends to have the adverse effect by making systems too cumbersome to log into and passwords that are so hard to remember they are often written down. How strong do passwords need to be in order to be effective? The paper argues (and the math confirms) that even relatively weak passwords (20 bits) when used with password rotation and "three strike" policies are enough to make brute-force attacks on a single account unrealistic. My employers previous user/pass policy was mixed case, 8 char min, #'s and punctuation requirement, with 90 day rotation and three-strikes - BUT the username was made public, so only 1/2 the credential pair was private. My approach was to make both the user and the pass non-public, keep the rotation & three-strike policy and reduce the complexity requirement of the password slightly. The result puts more of the security burden on the systems and less on the users (by not having to remember complex passwords). This results in higher overall security of credential pairs and made the userâ(TM)s daily experience easier and less cumbersome.
Keyboard -> motherboard -> jump to ground, no, but the system as a whole (not the u fluctuations of the individual components there in) was (this was early 90's) be detectable. Not detectable in the "1011011 = exact data sequence" sense of the word but in a active/inactive "is the keyboard in use" sense... sure.
While it is "bogus" in that there is no new information here, it isn't bogus in the sense that it can't be done. When I was getting my EE, I was able to do a POC with nothing more than a bread board and an oscilloscope. In conjunction with using a laser to pull sound off windows (used by the CIA also) the possibilities with serious funding are truly endless.
Ah - lol - got it.
Nope. Deployed, even got extra to give to the boom operators so they could see how the fuel moved around the aircraft using the fuel panel simulation.
While working for the USAF developing a PTT (Part Task Trainer) for the new "glass cockpit" on KC-135R Aerial Refueler, my coding partner and I worked at the largest non-commercial airport in the US. Our office was a 6x9 closet. We were located by the fuel station, so every afternoon when the news choppers and flight for life choppers would refuel, the ventilation system pumped AvGas directly into the "office". It would get so bad that we would have to stop working from 3-5. After attempting to work through it at first, we would get dizzy from the fumes.