New answers tagged software
-3
I believe in this case, realization is deployment and integration of final product.
2
In my experience, it's usually no more difficult than making a list of everything that needs to get done, then each team member picking something off the list. If you both feel that the same task must be done first, then either work together or break it down further. If you estimate a task to take longer than 20 hours or so, it's probably too big, so break ...
3
First of all, use some kind of project management or bug tracking tool for your tasks. (e.g. Trello, Redmine etc.). That way you could see open tasks and the tasks you are working on. If you decide you need to add more people on the project, they can easily see all the tasks.
Dividing the tasks is the hard part. But some logical way is to separate the tasks ...
8
First of all, you need some sort of source code control. My company uses Team Foundation Server, but there is some free software out there (don't know which one is the best, so I can't recommend). Then, you need to have some sort of shared task list, so you can keep track of what's to be done and who's done what. There are some sites for that also, but I ...
1
In a peer-to-peer architecture, all peers are supposed to be on the same level. There is no distinction between clients, servers, or other special roles.
Broker as integration function is a more central role in hub-and-spoke architectures. The broker typically maps and routes messages. The broker may be part of the central middleware or it can be attached ...
6
That is a syntax diagram. I think I first saw them in Grogono's "Programming in Pascal", from 1980, but they were used in Wirth's 1973 report on PASCAL.
0
Why?
The best documentation is clearly-written code with an obvious purpose and process. Comments to explain what is being done are then superflous. Comments to explain why the code exists are useful, if not obvious from context.
The underlying question is: what is the purpose of the documentation you have in mind?
Documentation for its own sake may be a ...
1
There is a lot of information that could be considered "documentation". Here's my summary, with some best practices for each:
Class, method, function, and variable names. This is critical to having readable code. All other documentation can easily get out of date, but the text that the compiler actually compiles almost by definition cannot. It is the ...
0
JavaDoc documentation may be more or less detailed. For example, the inline documentation (in .NET, similar to JavaDoc) is pretty verbose on one of the projects I'm working on, containing not only the description of a method, but also the list of possible exceptions, the examples showing how to use a method (with demo source code in comments), etc.
Having ...
2
According to this article, the on-board software for the Space Shuttle came very close -- the last three versions of the 420,000 line program had just one error each. The software was maintained by a group of 260 men and women. A large number of these people were verifiers, whose sole purpose was to find errors.
The upgrade of the software to permit the ...
3
Just a hint for LaTeX-Users:
The rail-package allows the generation of such rail-diagramms with (La)TeX.
You may check TeX.SX for an example.
1
Yes.
But as you know, it requires far too much effort to be worth it.
Before I can defend my answer, we must first define what a bug is:
A bug is a behavior that is contrary to the specification.
However, glitches in the specification (e.g. the 0th law of robotics) do not count as software bugs.
Extra features do not count as bugs, unless prohibited by ...
16
That looks like SQLite's syntax diagrams.
Their FAQ says:
How are the syntax diagrams (a.k.a. "railroad" diagrams) for SQLite generated?
The answer is a link to this wiki page on "Generating Syntax Diagrams Using Tk".
The wiki links to this Tcl source code for generating the diagrams.
3
The reasons for not writing bug-free programs are mostly economical.
There are mathematical methods to prove the correctness of a program. In a high-quality Computer Science course they will be mentioned. There are programming languages invented especially for this purpose. In theory, programming without bugs is possible.
Yes, there is the imperfect ...
1
I found Jim Shore's section No Bugs a very useful reading on this topic. The short form: It's not possible to develop without producing bugs - but we can work in such a way that we detect them as early as possible.
During the production of the code itself. For example by writing and running Unit Tests frequently during development, we constantly assure the ...
2
Errare humanum est
Even if you write code with a formal language, like B-method, that you can use to mathematically prove that requirements are met,
Even if you use a formal specification language,
There is always a human step consisting in extracting the user's needs from one or more brains to a computer.
This human step is error-prone, and the worm is ...
1
If you have a sufficiently tight and restricted specification, you might be able to prove a bug-free program, but only based on unprovable assumptions about the correct functioning of everything else in the system. This leaves as a given that there's no way to prove that the specifications would be considered correct by whomever posed the original problem, ...
5
No.
David Hilbert proposed his second problem of mathematics back in 1900 that essentially asked the world to prove that the arithmetic worked as intended. He later propsed "the Entscheidungsproblem", which asked something similar in logical terms. Kurt_Gödel's "first incompleteness theorem" proved in 1931 that no theory of elementary arithmetic could be ...
0
exploratory Development == experimental. new to the world or new to you or your company. means trying something and then maybe having the guts to leave it and go some other way.
Incremental means doing in stages. so you can test and be agile and have more releases and hopefully happier customers OR just more involved QA
23
As Mikey mentioned, writing bugless code is not the goal. If that is what you are aiming for, then I have some very bad news for you.
The key point is that you are vastly underestimating the complexity of software.
First things first--You're ignoring the bigger picture of how your program runs. It does not run in isolation on a perfect system. Even the ...
7
Essentially, no but you should do your best anyway.
I'll explain why (or just skip to the conclusion if you don't have enough patience)
Consider a problem as trivial as the implementation of binary search. One very popular implementation had a bug that went undetected for around two decades. If twenty lines take twenty years to get bug-free being widely ...
10
Mathematically it MIGHT be possible to write 'bugless' software of such complexity, depending on how you define 'bug'. Proving it MIGHT also be mathematically possible, by designing a test system that would exercise every line of code in every possible way - every possible use case. But I am not sure - if you are dealing with a system that does complex ...
Top 50 recent answers are included
