Are there any online repositories of completed real-world projects with their timescales that I can use to callibrate my own development time estimates?
If such a repository existed, how would you expect to correlate your project to find matches?
To expand; every software development project has unique aspects - particularly with regard to project participants - and will therefore have unique dynamics that affect estimates, possibly by orders of magnitude.
To apply past project metrics to future projects and hope they hold up you would need to assume a few things;
Developers are interchangeable (they
aren't)
Building software is like building a house or a brick wall (it isn't)
Project risks are negligible (maybe you'll get lucky?)
Finally, if all you need is a ball-park number then isn't "calibration" overkill? Just ask your most experienced developer how long they think - they are usually in the ball park.
I don't think relating your project to a set of generic other projects to determine a time est. would be hugely beneficial. You can compare to other projects for defect rates - here's a good starting point for that: http://www.scribd.com/doc/7758538/Capers-Jones-Software-Quality-in-2008
My suggestion would be to look at prior projects in your company with the same relative technology and resources and develop a table (via function points) and then a continual resync. If there is no prior info and/or the technology is new and/or the resources are different - then it's best to use the team's prior experience from prior jobs.
Here's a good book: Software Estimation: Demystifying the Black Art
Related
We have an application with 10 millions lines of code in 4GL(Progress) and a database also OpenEdge with 300 Tables. My Boss says we should migrate it to a new Programming language and a new Database Management system.
My questions are:
Do you think we should migrate it? Do you think Progress has a "future"?
If we should migrate it, how, are there any tools? Or should we begin with programming from scratch?
Thank you for the help.
Ablo
Unless your boss has access to an unlimited budget, endless user patience and a thirst for frustration and agony you should not waste any time thinking about rewrites.
http://www.joelonsoftware.com/articles/fog0000000069.html
Yes, Progress has a future. They probably will never be as sexy an option as Microsoft or Oracle or whatever the cool kids are using this week. But they have been around for 30 years and they will still be here when you and your boss retire.
There are those who will rain down scorn on Progress because it isn't X or it doesn't have Y. Maybe they can rewrite your 10 million lines of code next weekend and prove just how right they are. I would not, however, pay them for those efforts until after the user acceptance tests are passed and the implementation is completed.
A couple of years later (the original post being from 2014 and the answers being from 2014 to 2015) :
The post, which has gotten the most votes is argumenting basically two fold :
a. Progress (Openedge) has been around for a long time and is not going anywhere soon
b. Unless your boss has access to an unlimited budget, endless user patience and a thirst for frustration and agony you should not waste any time thinking about rewrites: http://www.joelonsoftware.com/articles/fog0000000069.html
With regard to a:
Yes, the Progress OpenEdge Stack is still around. But from my experience the difficulty to find experienced and skilled Openedge has gotten even more difficult.
But also an important factor here, which i think has evolved to much greater importance, since this discussion started:
The available Open Source Stacks for application development have gotten by factors better, both in terms of out-of-box functionality and quality and have decisively moved in direction of RAD.
I am thinking for instance of Spring Boot, but not only, see https://stackshare.io/spring-boot/alternatives. In the Java realm Spring Boot is certainly unique. Also for the development of rich Webui's many very valid options have emerged, which certainly are addressing RAD requirements, just some "arbitrary" examples https://vaadin.com for Java, but also https://www.polymer-project.org for Javascript, which are interestingly converging both with https://vaadin.com/flow.
Many of the available stacks are still evolving strongly, but all have making life easier for the developer as strong driver. Also in terms of architectures you will find a convergence of many of this stacks with regard basic building blocks and principles: Separation of Interfaces from Implementation, REST API's for remote communication, Object Relational Mapping Technologies, NoSql / Json approaches etc etc.
So yes the Open Source Stack are getting very efficient in terms of Development. And what must also be mentioned, that the scope of these stacks do not stop with development: Deployment, Operational Aspects and naturally also Testing are a strong ,which in the end also make the developers life easier.
Generally one can say the a well choosen Mix and Match of Open Source Stacks have a very strong value proposition, also on the background of RAD requirements, which a proprietary Stack, will have in the long run difficulty to match - at least from my point of view.
With regard to b:
Interestingly enough i was just recently with a customer, who is looking to do exactly this: rewrite their application. The irony: they are migrating from Progress to Progress OpenEdge, with several additional Open Edge compliant Tools. The reason two fold: Their code is getting very difficult to maintain and would refactoring in order to address requirements coming from Web Frontends. Also interesting, they are not finding enough qualified developers.
Basically: Code is sound and lives , when it can be refactored and when it can evolve with new requirements. Unfortunately there many examples - at least from my experience - to contrary.
Additionally End-of-Lifecyle of Software can force a company, to "rewrite" at least layers of their software. And this doesn't necessarily have to bad and impossible. I worked on a Project, which migrated over 300 Oracle Forms forms to a Java based UI within less then two years. This migration from a 2 tier to a 3 tier architecture actually positioned the company to evolve their architecture to address the needs of Web Ui's. So actually in the end this "rewrite" and a strong return of value also from the business perspective.
So to cut a (very;-)) long story short:
One way or another, it is easy to go wrong with generalizations.
You need not begin programming from scratch. There is help available online and yes, you can contact Progress Technical Support if you find difficulties. Generally, ABL code from previous version should work with only little changes. Here are few things that you need to do in order to migrate your application:
Backup databases
Backup source code and .r files
Truncate DB bi files
Convert your databases
Recompile ABL code and test
http://knowledgebase.progress.com articles will help you in this. If you are migrating from some older versions like 9, you can find a good set of new features. You can try them but only after you are done with your conversion.
If you are migrating from 32-bit to 64-bit and if you are using 32-bit libraries, you need to replace them with 64-bit
The first question I'd come back with is 'why'? If the application is not measuring up that's one thing, and the question needs to be looked at from that perspective.
If the perception is that Progress is somehow a "lesser" application development and operating environment, and the desire is only to move to a different development and operating environment - you'll end up with a lot of resources in time, effort, and money invested - not to mention the opportunity cost - and for what? To run on a different database platform? Will migrating result in a lower TCO? Faster development turn-around time? Quicker time to market? What's expected advantage in moving from Progress, and how long will it take to recover the migration cost - if ever?
Somewhere out there is a company who had similar thoughts and tried to move off of Progress and the ABL. The effort failed to meet their target performance and functionality metrics, so they eventually gave up on the migration, threw in the towel, and stayed with Progress - after spending $25M on the project.
Can your company afford that kind of risk / reward ratio?
Progress (Openedge) has been around for a long time and is not going anywhere soon. And rewriting 10 Million lines of code in any language just to use the current flavor of the month would never be worth it unless your current application is not doing what you need. Even then bringing it up to current needs would normally be a better solution.
If you need to migrate your current application to the latest version of Openedge (Progress) you would normally just make a copy of your database(s) and convert it/them to the new version of Openedge and compile your your code against the new databases and shake the bugs out. You may have some keyword issues, but this is usually pretty minor.
If you need help with programming I would suggest contacting Progress Software and attending the yearly trade show or going to https://community.progress.com/ and asking/looking for local user groups. The local user groups would be a stellar place to find local programming talent.
Hope this helps.....
I need your recommendations for continuous build products for a large (1-2MLOC) software development project. Characteristics:
ClearCase revision control
Approx 80% C++; 15% Java; 5% script or low-level
Compiles for Green Hills Integrity OS, but also some windows and JVM chunks
Mostly an embedded system; also includes some UI pieces and some development support (simulation tools, config tools, etc...)
Each notional "version" of the deliverable includes deployment images for a number of boards, UI machines, etc... (~10 separate images; 5 distinct operating systems)
Need to maintain/track many simultaneous versions which, notably, are built for a variety of different board support packages
Build cycle time is a major issue on the project, need support for whatever features help address this (mostly need to manage a large farm of build machines, I guess..)
Operates in a secure environment (this is a gov't program) (Edited to add: This is a classified program; outsourcing the build infrastructure is a non-starter.)
Interested in any best practices or peripheral guidance you might offer. The build automation issues is one of several overlapping best practices that appear to be missing on the program, but try to keep your answers focused on build infrastructure piece and observations directly related.
Cost is not the driving concern. Scalability and ease of retrofitting onto an existing infrastructure are key.
(Edited to address #Dan's comment. ;-)
From my experience with similar systems, there are approximately two parts to this problem:
A repeatable method for checking out sources, building the software, and testing it (if you want to do continual testing as well as building), using a small number of command-line invocations.
A means of calling these command lines on various servers in the build farm.
For the latter, we've been using BuildBot, which seems to work pretty well.
For the former, we have a homegrown solution that started out as a simple bash shell script and grew ... rather substantially. From experience, I'd suggest starting out in python rather than bash -- you'll spend far more code in handling setup and configuration than in actually invoking programs. (Also, it's probably easier to run it on Windows if you're doing that.)
The things I've found to be really key in our script's usefulness are:
Ironclad repeatability. We have a standard set of build tools, and the scripts start out by scrubbing environment variables. There are very few command-line options; everything goes into configuration files, and those go in version control.
Logging. We produce a log of every command that the build script executes.
Configuration file inheritance. Each variant of our software gets a configuration file, and those files can include more-general settings (which include even-more-general settings).
Extensibility. When we add a new source component, it's pretty easy to add a set of instructions for building that component (and the instructions can be arbitrary bash code). The "can be arbitrary code" part is probably key here; no way is a pre-existing product going to be able to do all of the quirky things that you need for a large complex real-world system.
You can get started with a reasonably simple script and let it grow organically as the need arises; honestly, although ours is a bit messy, I think we got a much more usable result that way than we would have with heavy top-down design.
Cost isn't an object? I've worked for GreenHills, and they've solved these issues for their in-house build/test farms. Ask them to do the same for you.
When I see emphasis on things like scalability and security in a build system, I start thinking that you might be a candidate for the enterprise class build systems / CI systems. Conveniently, it sounds like you can afford them as well. A year old SD Times article provides a basic breakdown between the enterprise and team level build tools.
My company makes AnthillPro and we've worked with a number of companies on large embedded projects as well as highly secure projects. IBM is probably the largest other player in the space with BuildForge.
AnthillPro puts some extra emphasis on what you do with the images in the minutes/hours/days post build (do you install them onto simulators / hardware and run automated tests? stage them? promote them?) but we also see folks using it for just build.
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
Is It possible to perform a system analysis and design for a Website ( particularly a social Network ) ?
What are the Expected contents will be , In the document ?
can u provide an example , please ?
{ I made a social network (www.sy-stu.com) as to be my graduation project and I want to add a full analysis study to the graduation document , I do have experience in UML and Usecases just the Idea of an analysis of a website is not clear and never perform one before }
thanx in advance
This sounds very ambitious, but I'm sure it's possible. Unfortunately, I've forgotten a bit of System Analysis, but do adhere to many of its guiding principles for my own projects. In fact, I would say that most data-driven Web sites are excellent candidates for Systems Analysis and should be used always during Web planning for any project you plan on putting into production.
Straight from the wiki:
The development of a feasibility
study, involving determining whether
a project is economically, socially,
technologically and organizationally
feasible.
Conducting fact-finding
measures, designed to ascertain the
requirements of the system's
end-users. These typically span
interviews, questionnaires, or
visual observations of work on the
existing system.
Gauging how the
end-users would operate the system
(in terms of general experience in
using computer hardware or
software), what the system would be
used for etc.
For the first point, I would analyze different technologies such as ASP.NET, Ruby on Rails and PHP. Each technology has its strengths and weaknesses. One key thing to keep in mind is if you plan on making your social network free, you may consider open source technologies over proprietary - as many servers and application frameworks for proprietary projects are costly. I would also consider Web startup and hosting fees. If you plan on getting a reseller account with Host Gator, then you would need to factor in monthly billing costs. If you plan to host your own servers, you may be amazed at the cost of doing so. For a truly stable system, you would need to put a lot of work and cash into managing your own Web servers.
For the second point, you could probably locate plenty of information on user requirements from similar sites - just check out forums for DIY social networks and see what people are having issues with in the Technical Support section. Obviously, looking into technology based articles and magazines would be a good place to search on end user expectations - or even just joining Facebook and Twitter - see what they are doing since people seem content.
For the third point, again you can consult your competition and see how the user interface works out. Is it easy to use? Is it difficult in some aspects? If you had to use their system for 8 hours a day at least 5 days a week, what would drive you mad and how would you do it better? And keep in mind logical work flow as well. Knowing your user base is important too. In some systems, you may be developing for other programmers. Using strong jargon may be fine, but for a social network you must remember that they aren't familiar with Web site data flow and terminology. So your controls should still make sense to a computer novice and still work securely (don't forget system security too!) and in an organized fashion.
Finally, remember that things happen. I recently created a back-end site for a client of mine. I though the system worked very well - and they were very pleased, but I just got an email today that they want the way order items are stored to work differently. This is why there's a maintenance aspect to the System Development Life Cycle - things change after you finish deploying. It could also be said that if I had communicated with my client's needs more closely, this could have been resolved. Fortunately, the change is relatively minor, and we do live in a real world where things don't always work as we expect. We just do our best :)
As I said earlier, Systems Analysis is a lot of work and should be. The point of it is to determine that what you are trying to accomplish is feasible and practical without committing to a long term project that could span years. And always remember that no plan is perfect. If there were perfect plans, we wouldn't need new systems :).
I am assessing some tools to manage software develpment projects. Dotproject seems a good one, but i would like to learn of other's experinces using it for software development.
Thanks.
I've been using Assembla for a small team and loving it. The web interface is very elegant, and it gives me power and simplicity at the same time.
My favorite feature is the strong ticketing system which allows me to create tickets on the web, assign them to developers, associate them with other tickets, estimate the time it takes to close the ticket, and aggregate those times graphically. It really shines, though, with its version control and ticket integration. Being able to specify that this commit is related to ticket #45, fixes bug #78, and closes ticket #32 is very nice.
They offer version control hosting for multiple version control systems - including SVN and GIT.
They offer free and paid packages.
For more information, check out their usage videos here.
Oh, and do let us know what you decide and why :)
An old post, I know...
I used to be a core member of the dotproject team and used it for years and set up many organizations on it... ranging from small non-profits and software shops to major government projects. It tended to work relatively well. Unfortunately, due to the crawl of development, half the dotproject team split to form web2project and we've been there almost two years.
At present, we (web2project) does a quarterly release and have done major work on the code. We've closed ~100+ bugs, added dozens of features like iCal feeds, and improved performance by 95% and cut about 1/3 of the code overall. And yes, we have an upgrade path from dotProject.
Do you use a wiki in your company? Who uses it and what for. Do you share information between projects / teams / departments or not?
We use ours to store
Coding Style docs
Setup and Deployment procedures for web servers and sites
Network diagrams (what are all the servers in Dev, Staging, QA and Production called etc.)
Project docs (pdfs, visios, excel, docs, etc.) are stored in SVN. For the non-techies we have links to those docs in the wiki that point to an up-to-date share on my box. (tip: some wikis provide source control integration but ours doesn't)
Installation and Setup procedures for development tools
Howto's on things like using our bug tracking system, our unit testing philosophy
When doing research on a topic I often capture the important information in a wiki page for others to learn from
I've seen them used to keep seating charts in medium to large size organizations for the new people
At my previous company all of the emergency contacts and procedures for handling a critical outage where available on the front page of the wiki
The best part about a wiki is that it's searchable. Some wiki's support searching inside uploaded or linked docs as well.
If you setup a wiki and encourage or even require people to use it the amount of information that will accumulate can be amazing. It's definately worth the effort especially if you have someone in IT with some spare time on their hands to set it up.
Do you use a wiki in your company?
= We use it for the purpose of a Knowlede Based. Basically it is a wiki but many more functionalities intagrated.
Who uses it and what for
= Employees. Knowledge Sharing, Preparation of collaborative-documents, etc.
Do you share information between projects / teams / departments or not?
= Depends on the requirements. It is possible to set permissions between users.
We use a wiki, for documenting our systems. It's updated gradually as things update and evolve. It should go without saying that there's benefit in that, however whether you use a wiki or other methods is worth thinking about.
A wiki is great for collarborative editing. The information shouldn't go stale in theory, because as people use the systems they have the opportunity to keep it up to date.
However we have found in our organisation that people struggle a little with wiki markup. Especially tables. I think a solution that has wysiwyg editing would be better if you have non-highly-technical people editing it. Sharepoint springs to mind, but it's expensive.
I use a wiki as my virtual "story wall" for agile development. All of my stories are written and organized in the wiki. While my customers are reasonably local (we can have face-to-face meetings), they aren't co-located. To enable better customer interaction I've resorted to a wiki instead of a wall-based story tracking mechanism. It also works a little better for me due to the fact that I often have multiple, concurrent projects and limited wall space in my cube. In a larger team with more focused projects and more wall area, I'm not sure I'd make the same choice.
My company uses a wiki for project-planing but also for storing documentation and ideas.
I have found that a wiki is a great way to link the programmers in the company with the business-people.
When someone who are not on the programming-team comes up with an idea or finds a bug, it's a loot simpler to let that person document it in the wiki.
I think it's an important aspect for a small company like mine to easily synchronize the business-team with the development-team. A wiki helps with that, since it gives the feeling of being a part of the development process, instead of having to ask the programmer directly about every little detail.
we have MediaWiki to store technical information that is not ready to be published in other formats - specification drafts, diagrams (via GraphViz extension), results of short investigations, etc.
I also think this question is a wiki too :)