Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 3 years ago.
Improve this question
Our investor wants a SDLC. I've never written one before, and I don't have enough time to go and buy a book, or spend much time learning about them. From what I've been told about them, they consist of requirements (what needs to be done), and a list is done. Is this correct?
Update:
I have found this article which really helps to explain things in simple terms and very quickly. Not that I think an SDLC should be done quickly. In my case, I have no other option.
There are lots of ideas about SDLC out there. You can't swing a cat without hitting one.
What have you done to develop software that attracted your investor in the first place? Can't you describe that? Why do you have to go out and "learn one"?
There's a number of choices:
Waterfall: requirements->design->build->test->deploy,
all in sequence
Iterative: similar to waterfall, but you break the design into smaller pieces, of 1-2 week duration, that are delivered at the end of the iteration.
Extreme Programming (XP): Kent Beck's approach; no BDUF (Big Design Up Front). Everything is designed, built, and delivered in small pieces.
Scrum: Agile, iterative, but not as dogmatic as XP.
Rational Unified Process: Waterfall from IBM.
Not really; that's more project management. That's what you need at the point where you've figured out how you're going to develop software.
For the 'how' of developing Software, the two 'biggies' are Agile and Waterfall; with a weird hybrid in between the two.
But that's only one part of the Software Development Life Cycle: You still have to have a maintenance and deployment plan.
My question for you: If someone's giving you money, and they want a plan, isn't it in your best interest to read a book about the SDLC and give them a plan?
If your investor wants you to describe the SDLC, he wants that you describe how looks the life of a software project which is done by you from its plan, birth, through growth to maturity and death. That is the reason why it has "life" in its name. The result of SDLC should be "software" hence the first word. The "development" part comes from the fact that you are responsible for planning, specifying, designing and implementation of the software, you should create (develop) the software. And finally, "cycle" means that, when the investor looks at you SDLC and thinks it is good (it produces quality and business value), he can ask you to use the same process once again in another project.
A complete SDLC meaning you need to perform Requirement gathering and Analysis-> Design (Design document creation) -> Coding and Unit testing -> Testing (System and Integrated testing) -> Deployment and Support -> Maintenance
I found this Blogg really helpful.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
I am building a 'software as a service' website that will be charging users a small monthly fee. I am considering changing the Github repository over from Private to Public. Essentially open sourcing it. Is this suicide? I would like the community to be able to benefit from the code. It is unlikely that I will accept any push request so I'm not going to gain anything in that regard. It is community based, so I think most of the value would be lost by someone self hosting it. It is for a very niche audience so I doubt someone else will start a competing hosting. I would really like the code to be in the open, but not at the expense of my idea of course. How does everyone else feel about this? What is common practice?
Conclusion, I'm keeping it closed for the time being. I may look to open source sometime after launch however.
Since you are not going to accept pushes you might as well hold on get your code stable and then publish it for others to learn and benefit from. You are still building the service, so its not going to attract too many eyeballs either.
From a business point of you, you might want to have a reasonable community around your service before you opensource it. if you are still budding who knows if its taken up by a stronger competitor. If your idea is patented its a different story.
To be honest, and this is not likely going to be a popular answer, but to myself, I would keep it closed for a period of time.
The reasons for this are simple, establish your foothold in the marketplace, build your userbase, your brand, then it gives you a mechanism to market your product further by selectively or completely open sourcing components of your system.
I say do it for both personal benefit and potential strategic benefit ... afterall, alot of software IS a service
Most open-source projects stand to provide a return in the right circumstances. Don't forget, unless you have a patent or some massive advance that is so complex and unfathomable that nobody can re-implement it .. if they want to they will anyway, so you have little protection staying closed source anyway ... even more interesting is that the open-source equivalent may well overtake your proprietary one if it garners support.
People may send you great ideas you never thought of, or take your codebase in a direction you would not have predicted. Unless you have significant value in terms of IP or strategic position tied up in the source code ... releasing it will probably do more good than harm.
Also, by being first to the open-source arena with your code, you gain control over any resulting community driven development ... if somone reimplemented your functionality and went open source ... could you compete on any front?
I know it is a cliche, but probably for good reason, but read The Cathedral and the Bazaar and the essay Open Source as a Signalling Device - An Economic Analysis which is an interesting read. Michael E. Porter's texts on competition analysis are interesting when held up against the mixed value economics and competitive forces of open source and shows how disruptive open-sourcing a product can be to competitors ... and how it can add value to your market position. Also, whilst counterintuative, it can raise the barriers to a successful entry by competitors.
More food for thought on the advantages and disadvantages of open sourcing:
What the DoD thinks of open source
Alfred H. Essa "Innovation and strategic advantage: lessons from open source" (warning, journal link)
I like to fix flaws wherever I see them, and perhaps I am one of your users. I'd rather send a patch than send a potentially nagging-sounding email any day.
What benefit are you hoping to gain from making the code open source? If you don't want the input of other developers then there are very few advantages and a whole lot of potential disadvantages.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
We're a medium sized engineering shop (10-20). We are great at prioritizing and structuring work on our user facing stories and making customers happy. But the cobbler's children have no shoes. If it isn't about customers, we have 0 process.
I'm looking for systems to ensure we correctly prioritize and accomplish the non user facing work to keep a dev shop running: QA environments (pretty heavy, in our case), continuous integration systems, the packaging, and so forth.
Now, resources are always limited. We don't want to give the cobblers children 10 pair of the fanciest shoes, and specialized bike shoes to boot. We want to do the right, necessary work, with the same scrummy discipline that is applied to the rest of our development.
Tell me what system works for you: how to you prioritize and organize non-user facing work ? I want systems that are simple and integrate smoothly with scrum.
(I'm aware of a red box at the top of this text, indicating that Stack Overflow's automated question parser thinks this is a subjective question that can't be answered - I think there are likely 2 or 3 excellent answers that can be or have been proven viable - and process is integral to programming. So here is some psuedocode representing our process. Fix this algorithym).
IBacklog GetBacklogForWork(IWork requestedWork)
{
if(requestedWork.IsUserFacing) return new PrioritizedBacklogRepository();
// Everything else. Priority largely based on spare time and who thinks its a neat idea
return new RandomizedPriorityRepository();
}
void HandleIncomingSuggestionsForWork(IEnumerable(IWork) ideas)
{
foreach(work in ideas) GetBacklogForWork(work).Insert(work);
}
Someone involved is using and depending on the results of the project. This is necessarily true; if it weren't true, why would you be doing it?
When you identify the person who most depends upon, or cares most about, the results of the project, you have the "user" that your project is facing. Make that person the customer.
IMO something like "QA environments" is, in a sense, user-facing work.
Quality is admittedly a "non-functional" requirement (so there isn't necessarily an associated "story"). But, you may have a non-functional requirement like "the software must be tested before it's shipped". You can assign a relative priority to such a requirement ("how important is it that software be tested?"), and then execute as usual (decide how to implement that requirement, estimate how long it will take to implement, schedule the implementation, assign the implementation, etc.).
What we do where I work is to have a percentage, right now around 15% give or take a few percent, that is spent on internal tasks that are non-user facing work. This way the technical debt is handled and if the task backlog becomes rather large then a sprint may be spent on it instead of new functionality. The way that last one would get pitched to the user or customer is that there will be a time where just maintenance and preventive work is done so there aren't any new functions coming after the next sprint.
That's one idea that can be tweaked a bit though it isn't necessarily fully flushed out yet.
The way I've seen it work more or less ok is to try to do as much as possible of the non-functional/non-user-facing as PART of a related user-facing activity, or the first user-facing activity that requires it.
This is the easiest to cope with, as it just reflects the needs of the development organization in order to maintain sustainable velocity moving forward.
Additional work which cannot be related will be done using a percentage as described by JB King.
The alternative of pitching it as an investment with such and such ROI to the PO is a theoretically sexy concept, but with real life POs I've seen it rarely works.
Its very hard to get POs to understand the investment, not to mention actually being strong enough to delay functionality for it.
Its sometimes the difficult role of the development teams to be the guys that "slow things down" in order to keep a sustainable situation.
Dev managers sometimes feel really bad about this whole sitation, regardless of the chosen approach. My recommendation both as someone who's been in that spot, as well as an Agile coach, is that as long as you feel you are doing the right thing for the business, focusing on non-functional work that is required NOW and has a relatively quick ROI, you should feel ok about this.
Cautionary note: This is an area where self-organization is really put to the challenge. Organization needs to trust the team to do the right thing, and the team needs to earn and not abuse that trust. Its a sign of maturity for an individual or a team to know the right balance.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
I am working in a small team on some projects in my spare time. We are having the problem that we seem to go in circles and are not able to get our products developed - however this is not a problem during my day job. The lack of face-to-face communication seems to have a real impact on productivity.
Any examples of software or methodologies in use by the open source development community would be appreciated.
If you read the history of most open source projects, they start with one person doing a lot of the initial work. If there's a team, it's small, and one person actually leads the team.
To pick one example. In the Python community, they refer to Guido van Rossum as the Benevolent Dictator for Life (BDFL). His word is (more-or-less) final. In many cases there are folks don't agree with him -- but for the sake of the Python community -- they seem to acquiesce to his judgment.
I think every open source project has a (singular) lead programmer who assures that decisions get made, and made in a consistent way.
Back in the olden days, Fred Brooks (The Mythical Man Month) described "chief programmer teams". Same concept. Someone is in charge of the technical content. Emphasis on the one. Nowadays we call the the "architect" or some such term.
No real methodology here, but I think 2 things are important:
Have well defined goals and
responsibilities.
Let each developer
have the last say in how their
allocated part should be done.
In open source projects the only real and strongest motivation is the fun to be had coding the product. Relating to #2 above, if people are told what to do, and they don't agree with it, the motivation starts lacking. Of course there will always be a bit of give-and-take like in any other type of relationship.
Also about the face time, Skype is great for having face to face meetings, which I recommend at least once a week or month (depending on the size and momentum of the project)
This is a difficult question to answer because "open source projects" is a very broad selection of projects. I think the defining characteristic is the project has a single unifying goal (perhaps, a set of related goals).
Are you on any open source mailing lists? I am subscribed to my favorite distro's mailing list and the developers e-mail each other many times a day. Also, there are other avenues of communication such as IRC / Instant Messenger.
I am not a RoR developer, but I would suggest skimming through Getting Real for some inspiration.
My guess is that your private projects are all run and coded by developers. Developers are known to... keep on developing. The big difference, in my experience is that a company has experienced managers that can define when things are DONE. I'd recommend putting someone on the task of defining goals and decide when things are done.
I've been on some projects where we had a lot more talkers than developers. My inclination is to ignore the talkers and listen to the coders. Even then there's usually one person who is in charge of accepting patches. There may be political issues they have to tread lightly around, but for all intents and purposes they have final say.
Linus has had some fairly famous issues with the same problem. Take note of this thread from 2006: Talk is cheap. Show me the code.
One more thing. Since you say in the comments that you do have code, just a lot of rewrites, I'd highly suggest you read Eric Raymond's The Cathedral and the Bazzaar. Eric's a bit of a nutter actually, but the essay is priceless for anyone wanting to run a Free Software project.
I'd have a think about your and your team mate's motivation and goals in this project. Are they to:
a) Create an awesome product
or
b) play around with software, and learn some new things
Both answers are equally valid, and i'm guessing it'd be a mix with a leaning towards one or the other.
If it's more of (a) then look at suggestions on methodology etc. Maybe even consider forming a company around your awesome idea. Because making such a thing takes work.. and well you probably get enough of that at work.
If it's mostly (b) then you're going to have a harder time making an awesome product, but an easier time in that you can forgive yourself for not getting there right away and suffering multiple re-writes. And you will all be learning new skills each time you look at it and work together which are very applicable to your long term careers.
Firstly i suggest you all be clear with each other on why you are there. Then look at paring back on what you are planning on doing, and release early and release often. If your project is made up of three components and one is complete, then release that as a separate component and start building a community of users. This will pay off as these users will possibly help you with your code, plus form a solid core of users for the full product and let you assess how you are going early rather than later.
Good luck.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I have a problem to solve that I think will take 4 days, but if I had a feature request sorted and a snapshot release then I reckon I could have it done in one. Superficially this creates a budget of 3 x my daily rate to get it the feature-request actioned.
So my questions are, have you ever paid an O/S project member to fix something for you? Did it work out OK? How did you sell the idea to your manager / colleagues and where did the money come from?
Most importantly how did you go about asking nicely? Is there an etiquette for these things? Are the project leaders likely to be receptive to the idea?
In case it matters, the software with the the missing feature is a JBoss project - the home of professional open source - and I'm able to claim expenses as I'm a contractor.
At work, we've had good luck hiring open source maintainers to enhance libraries that we use.
Here are some projects we've done in the past:
We needed to integrate Quake 2 with wxWidgets. We hired Vadim Zeitlin, a major contributor to wxWidgets. In less than 4 days, he built a wxQuake2 widget by adapting the Windows version of Quake 2.
Later on, we needed portable access to raw bitmaps. So we hired Vadim again, and worked with him to produce a new raw bitmap API. This involved a substantial bit of design work, but we really liked the resulting API, and we use it to this day.
At a later date, we hired another one of the core contributors to improve wxWidgets accessibility support. As it turned out, we ended up not using this code right away, for various technical reasons. But other people have been enhancing this code since then, and we hope to use it some day.
In other words, hiring open source maintainers is a lot like hiring any other kind of contractor. But some things are a bit different, too. Here's some advice based on our experiences:
You'll have the most luck if you want to enhance an existing project and release the changes as open source.
In general, you want to hire members of the core team. They have the best track records, they're the most productive, and they have the best chance of getting your changes merged upstream.
You want to get your changes merged upstream. If you don't, you'll be maintaining a local fork, which is a headache.
Before hiring, do some research. Who works on the features you care about? Are they somebody you'd enjoy working with? Read the mailing lists and glance at the version control history, and pick out a few people to approach.
During the design phase, there may be a bit of give-and-take. The developers are looking at the larger health of the project, and you're looking at the needs of a specific business. This has occasionally made negotiations a bit more complicated for us, but the final result has typically been a better design than we would have chosen on our own.
And most importantly, don't be shy. In any sufficiently large open source project, several members of the core team will already run consulting businesses. In smaller open source projects, you'll generally find several contributors who want to run consulting businesses.
And if you're still hesitant to approach somebody, you can always ask, "Do you know anybody who'd be interested in getting paid to work on $FEATURE?" If they're not interested, you haven't put them on the spot, and they may tell you who to ask.
On the whole, we've been impressed with the professionalism and productivity of open source maintainers, and I would recommend this route for others.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
Sooo...it's only sort of programming related, but I figure it's election day, right? Is there a single good reason why they aren't, not necessarily open source in that anyone can contribute, but open source in that anyone could inspect the source?
Voting machines aren't open-source because lobbyists for the "electrical till" industry successfully hoodwinked politicians not qualified to make technology choices into buying their snake-oil. This was accomplished with a mix of anti-FOSS FUD and good ol' fashioned bribery campaign contributions.
Update: I will try to post links here from time to time that show how vendors respond to critical examination. Feel free to add your own. (Pro-OSS–only: "the man" can make his own post!)
Interesting Email from Sequoia
In Belgium, the sourcecode for the voting machines is freely downloadable.
In the context of this discussion, you might find this paper interesting:
Secret-Ballot Receipts: True Voter-Verifiable Elections
It's written by David Chaum, the cryptographer responsible for DigiCash, among other things. From his bio page on Wikipedia, I also found End-to-end auditable voting systems.
Update! Now it seems we can see if this really works: First Test for Election Cryptography.
Looking back in time now, I've read a couple of articles on the experiment in Takoma Park, and this system actually seems different from the one described in the original paper. However, it is still by David Chaum, and still supports the end-to-end audit properties. The system is called Scantegrity II.
The reason they aren't open source, is because, as Kent mentioned, it wouldn't help. You could open source the code. But there's no way to ensure that the voting machine you are using is actually running the code that is open sourced.
There is no reason that open source code is better than closed source in this case.
How you voted must always remain a secret for obvious reasons. The ONLY real safeguard is the paper trail.
I WORKED with these machines and if so inclined I would have made malicious code that flips votes the way I wanted after 10 cast ballots to defeat whatever ridiculous Logic and Accuracy tests were thrown at the machine before deployment (We never went past one test vote).
Randomly pick a certain percentage of machines and compare the paper trail to the electronic tally. If Diebold had been confident of its machines then they would have insisted that this be the last step in any election.
Security Through Obscurity!
the problem is opensourcing the software would be a no-op.
They don't have any decent cryptography, and there has been demonstrated and relatively easy ways to contravene them simply by hot-swapping a ROM chip in the voting booth, or Having a device that augments the records in the record cartridge.
Youtube: Sequoia Part 1 Those with access can hack with programmed ROM chip
Youtube: Sequoia Part 2 Logic and Accuracy Test vs Election Mode with vote-stealing firmware
Youtube: Sequoia Part 5 Manipulating Sequoia Voting Results Cartridges from Precincts
#Mnementh The bad cryptography and the possibility to swap the ROM-chip has nothing
to do with open-sourcing the code? So there is the point?
There are only 3 logical reasons for opensourcing this code:
To put under scrutiny how the votes are counted to be certain its doing it right.
For somebody to be able to modify that code for their own needs.
To put the software into public domain so public committers can improve on it.
Points 1 and 3 are blown out of the water in terms of usefulness and "proving your vote counts" because you have no assurance that the code you are seeing/improving runs on these devices.
So that leaves only condition 2 being useful, and as you are not going to own your own voting machine, and have no need for one for anything more than nefarious causes or to simply prove their vulnerability.
For the majority of cases all it would mean is that there would be more information publically available on how to contravene these machines, so you would no longer need physical access to one in order to attempt reverse engineer their software and develop compromised ROM chips for use in said devices, grossly reducing the barrier to entry for the compromise of the voting system.
Granted, even in a non-opensource state this information can still leak, and you just have a false sense of security because you assume "theres no leak, I am safe", but on the contrary, if you open source it people will assume "hundreds of people have looked at the source code, I am safe" which is an equally bad false sense of security.
People are looking for a silver bullet safe way of voting, and sadly, there is none. Not without growing a race of purified peoples whom are brought up by non-committal monks in isolationist shrines to have a breed of people simply for the task of witnessing and counting votes accurately, whom are trained to be amoral and can't be bribed to switch the vote.
( It would sort of be like the 'dark angel' series except with voting agents instead of assassins, and we all know how that show works out, one of them would go rouge, we'd trust them, and they'd screw us all )
Because politicians buy them. Anything politicians get their hands in goes to shit, because 99% of the time they're only experience is in running for office, not doing things like adequately vetting hardware and software.
Also, kickbacks.
The truth hurts, doesn't it?
There is no specific reason not to open-source the software (and even opening the hardware-layout) of voting machines. It has no security impact, as some try to state, because if closed or open source, the ROM can be switched. The machine need some sort of verifier to check, if the code loaded is really the one certified for the election. Open-Sourcing would make no difference.
Because if they were they would not be able to blame inaccurate votes on calibration-errors on the touchscreen.
The people responsible have a "security by obscurity" bad meme stuck somewhere
The people building the software don't want to help competitors
The people building the software fear embarrassment
There are not enough people in the legislative process who understand the flaws in all of the above
So far, most replies have been technical in nature, but most likely, voting machines are not open source because the company under contract to develop them has no incentive to make them open source.
If a company develops an open source voting system, anyone came come around later to support that system. And, quite honestly, I doubt the government would accept the equivalent of a SourceForge project as the basis for an entire election.
Perhaps there should be an honest-broker authority that oversees the development of an open-source voting system, and contributors to that system should be vetted before they can view or commit source code.