Provide three examples of software projects that would be amenable to the component-based model
Answers
Explanation:
Official tender with closed set of requirement and fixed price. Usually tender covers up to X% of “changes and additional requirements”, so small stuff can be changed and added later, but everything beyond that - nope.
You get an Excel or Word with several thousands of requirements (big and complex and trivial, with one line can cost zero and other can cost $1M to develop), you estimate the effort, add risk factors, and submit your proposal together with technical and managerial descriptions.
Good luck.
Anything that both satisfies their requirements as-written, and fits into technical description that was submitted will (must) be accepted by the customer - or they will have to bargain like “let’s cancel this requirement, but instead please implement that one”.
For governmental / military project managing all those requirements, what was amended, what was added, who owes what to whom, how it affects timelines, subcontractors (sometimes they are enforced by the customer and paid directly by him), is a full time and very non trivial job.
There are many types of projects that can’t be managed in Agile way, or delivered in Agile way (they still can be developed in Agile way, as it is internal matter of the dev team).
Customer won’t see anything before first review (that was requested as part of the tender, and was budgeted for).
Oh, forgot the reviews.
Interface Design Review, Integration Design Review, HMI Design Review, Safety Committee, Cyber Committee, Field Experiment Design Review, most of them come twice (preliminary and critical), for some you can add third - “Readiness Review”.
For big project that are delivered in phases you do the whole set two-tree times, for features of each phase (obviously first set takes the most effort).
Don’t forget logistics - spare parts program, operator training, technician training, certification programs, delivery of trainers and simulators.
Multiple pair-integration sessions, separate entity that manages integration and coordination of all systems (not only software. To be able to deploy in X hours your software must boot up, but hardware must be able to work for some time even before AC lowered temp in the shelter to the “long-running-threshold” value. Think about hundreds of interdependencies).
Everything must be coordinated.
Then come field tests. Test grounds must be booked, plans reviewed, safety issues validated, roads and air space closed, all the stuff shipped, engineers and technicians sent over (sometimes hundreds of them). To prepare all that takes months if not years. and usually you can’t “move” it in time. If something is not ready - or experiment will be delayed (very big issue), or this feature won’t be tested at all (bad), or experiment plan will be amended to allow testing of whatever can be tested (non ideal, but acceptable).
Then, when everything works and you deliver it - sometimes it is only IOC - initial operational concept. That means - pilot version. Customer will play with it for a year or two, and then order more - with changes, both in hardware and software, to cover for all deficiencies discovered in this “evaluation” period.
So trust me, there are many projects where “push-to-production” just doesn’t have a chance.
You can’t “eventually” get Air Traffic Control system (and I am talking about ground component only, not real avionics) if you start with something that can handle one plane that flies on the straight line, and continuously improve it.
You can’t deliver a “minimally valuable product” for nuclear station management system, and improve it with two-weeks sprints.
You can develop it in this way “internally”, you can give it to QA so they will test only very specific stuff (use-cases and scenarios) that is already implemented, but you never give anything to the customer until is passes FAT, SAT and full integration tests.
Version release process (you know, from check-in through Jenkins etc) can take months, and cost hundred thousands of $$$ (and I don’t include field tests, let’s assume everything can be done in QA/Integration laboratories).
Cost is not an exaggeration:
$1M is cost of employing 6–8 engineers for a year. So if version validation takes 2–3 months (different subcontractors, different countries, supervision from the customer and various certification authorities), and all over there are 10 people working on that (system engineers, programmers, part of managerial effort goes into that, QA people, integrators) you easily get into $K250–300 area for a main contractor. Add to it internal expenses of the customer (it cost them too to get a new version, redeploy, train, etc) and subcontractors, and you are in half-million area. This is for small “maintenance” release, not major delivery of significantly new functionality.
So yes, there are projects that are rather be done using Waterfall approach
Answer:
Commercial off – the shelf software components, developed by vendors who offer them as products , can be used when software is to be built. These components provide targeted functionality with well defined interfaces that enable the component to be integrated into the software.
Regardless of the technology that is used to create the components, the component – based development model incorporates the following steps.
• Available component – based products are researched
• Component integration issuers are considered
• Comprehensive testing is conducted to ensure proper functionality.
Example projects:
(1) All business application projects
Ex: Banking – operations like withdraw, deposit are same for any bank. So these can be developed into a component and can be reused.
(2) Airport traffic controllers
This project deals with traffic controlling in the airports.
Checking the flight arrival & departures.
(3) Many projects that use object – orientation paradigm are generally component
based.
Explanation: