MFB - eftpostst3 server

TMS: Deployment Check List
Public IP address: http://195.29.102.125/mercur/ OK
web address: http://eftpostst3.telekomcloud.hr/mercur/ ok
VPN Access Private address: 10.240.131.14: OK
IIS OK
Perl OK
MTFiskal OK
Netapp 6210 storage - Netshare Disk OK
Filezilla FTP access / NO
Set Netshare Disk Alias on Filezilla FTP Server / OK
Setting of virtual directories on IIS to point at Netapp 6210 storage / NO
Setting MTFiskal Paths and FINA configuration parametres / NO

.........................................................................................................
Ove dvije stvari se moraju podesiti da bi aplikacija radila pod željenim userom:
a. Application pool
b. Pristup fizičkom direktoriju
Slike u prilogu
Account: etranet_dkovacic@tcloud.local
Pass: Passw0rd
.........................................................................................................
.........................................................................................................
Ovo je potrebno napraviti vezano za MTFiskal i FileUpload aplikacije.
.........................................................................................................

MTFiskla:
- potrebno je dodati u Computer Certificate Store pod trusted CA root od FINA-e produkcijiski certifikat. Možda sam ga već dodao, ali nisam siguran.
- u web.config datoteci od MTFiskala potrebno je promijeniti URL na FINA web service. Najbolje je otvoriti conifg file od produkcijskog MTFiskala i kopirati URL
- u slučaju da se mijenja putanja do certifikata potrebno ju je također promijeniti u web.config datoteci

FileUpload
- u slučaju da će path do direktorija biti drugačiji od testnog potrebno je otvoriti web.config datoteku i promijeniti path-ove do direktrorija

.........................................................................................................


ON QUALITY
Yes in the traditional proprietary software, higher quality means higher purchase cost, but the true value proposition of quality is that the total cost of ownership (i.e. taking into account all expenses related to running and managing a solution, not just getting it installed and deployed), is lower.
.
.
Quality is pretty much in tune with the old adage "you get what you pay for" in many instances.
However do not confuse what the customer pays with the sticker price upon purchase. Many opensource/free software products are very high quality yet sticker price is 0. You may choose to contract commercial support to baseline the TCO, or the organization may opt to take on the cost itself it feels it has the capability to do so.
The true value open source/free software products provide is choice as to how you manage your after-purchase cost, either buying commercial support, or relying on internal or community support.
All in all this is something that needs evaluation on a case-by-case basis.
And of course IT Architects are the ones best positioned to understand the trade-offs and determine what is the most beneficial solution to the organization.
-------------------------------
quality has value: there is a value proposition. He is also right that "architects are the ones best positioned...."

However, architects are generally not inclined to try to measure such things as value. In my experience, I would say that about 10% of IT architects are interested in assessing value quantitatively (the only way that matters when it comes to funding), and only a tenth of those have experience with techniques for assessing the value of quality in a credible way.

IT cannot claim a value from the functionality of a system to be built. The reason is that the functionality can be built by any outsource provider. It is a commodity in a sense.

Nevertheless, IT is in a position to add a-lot of value to the systems that it builds, and the business processes that it enables - on top of the functionality. The main sources of IT value are all of the "ilities". Qualities such as reliability, maintainability, secur(ability), extensibility - these things all lead to lower TCO and higher long term value. But to estimate these things one has to estimate future events such as how often will a system be extended, what will be the future costs of system failures (low reliability), what will be the future costs of security failures (including loss of brand value), and so on. These all have to do with lost market share, and so the numbers are generally not accessible to IT people unless they ask the business. And we all know that IT has problems communicating with the business.
--------------------------------------------
In my 30+ years of software architecting, design, and development, my experience is that quality (of design, code, testing,...) has a NEGATIVE cost, i.e. a payoff! If a shop is low quality, there is of course a cost associated with improving that quality, but it's an investment that pays off handsomely in lower ongoing costs and risk, enhanced agility, higher developer morale and skills, etc.
---------------

Stephen is right in saying quality is inversely proportional to cost. Though initial overheads are high, ultimately quality drives down the costs. For Instance, a good quality code written as per the standards will be easy to maintain, change, debug etc. The long term benefits of the quality code, applications definitely outweigh the initial costs (buying quality products, training resources for develop quality applications)
------------
software architects should know about infrastructure. They are often the interface between the purely functional and the deployment.
-------------
.

.
ON QUALITY
Yes in the traditional proprietary software, higher quality means higher purchase cost, but the true value proposition of quality is that the total cost of ownership (i.e. taking into account all expenses related to running and managing a solution, not just getting it installed and deployed), is lower.
.
.
Quality is pretty much in tune with the old adage "you get what you pay for" in many instances.
However do not confuse what the customer pays with the sticker price upon purchase. Many opensource/free software products are very high quality yet sticker price is 0.
You may choose to contract commercial support to baseline the TCO, or the organization may opt to take on the cost itself it feels it has the capability to do so.
The true value open source/free software products provide is choice as to how you manage your after-purchase cost, either buying commercial support, or relying on internal or community support.
All in all this is something that needs evaluation on a case-by-case basis.
And of course IT Architects are the ones best positioned to understand the trade-offs and determine what is the most beneficial solution to the organization.
.
.
-------------------------------
quality has value: there is a value proposition. He is also right that "architects are the ones best positioned...."
However, architects are generally not inclined to try to measure such things as value. In my experience, I would say that about 10% of IT architects are interested in assessing value quantitatively (the only way that matters when it comes to funding), and only a tenth of those have experience with techniques for assessing the value of quality in a credible way.
IT cannot claim a value from the functionality of a system to be built. The reason is that the functionality can be built by any outsource provider. It is a commodity in a sense.
Nevertheless, IT is in a position to add a-lot of value to the systems that it builds, and the business processes that it enables - on top of the functionality. The main sources of IT value are all of the "ilities". Qualities such as reliability, maintainability, secur(ability), extensibility - these things all lead to lower TCO and higher long term value. But to estimate these things one has to estimate future events such as how often will a system be extended, what will be the future costs of system failures (low reliability), what will be the future costs of security failures (including loss of brand value), and so on. These all have to do with lost market share, and so the numbers are generally not accessible to IT people unless they ask the business. And we all know that IT has problems communicating with the business.
--------------------------------------------
In my 40+ years of software architecting, design, and development, my experience is that quality (of design, code, testing,...) has a NEGATIVE cost, i.e. a payoff! If a shop is low quality, there is of course a cost associated with improving that quality, but it's an investment that pays off handsomely in lower ongoing costs and risk, enhanced agility, higher developer morale and skills, etc.
---------------
Stephen is right in saying quality is inversely proportional to cost. Though initial overheads are high, ultimately quality drives down the costs. For Instance, a good quality code written as per the standards will be easy to maintain, change, debug etc. The long term benefits of the quality code, applications definitely outweigh the initial costs (buying quality products, training resources for develop quality applications)
------------
.


.
Software strategic planning is the process by which the customers and developers envision the future together and set the necessary procedures and operations to achieve the desired software solution.
.
We think that tracking development milestones is a great way to monitor development progress and see which parts of the software are being developed, improved or fixed.
.
We can also see which parts of the software have not been planned, designed, coded and tested yet. The hardest single part of building a software system is deciding what to build, and how to approach to difficult problem, decomposing its complexity, by maintaining high development standards.
.

PLEASE NOTE: The planning process can be viewed as a somewhat spiral flow of topics and action steps, where the results from one step initiate study and action in the next step.
.
However, the development process does not necessarily always flow in one direction. Issues that arise in a particular solution may cause the planning team to go back to an earlier step to do additional work, implement new features and insert new milestones in the roadmap or refine the application functionality.
.
If desired, the order of the MILESTONES can even be altered to suit the particular needs of the planning team. The implementation step also does not end the planning process. Analysis of results could easily result in additional analysis or a change in strategic direction. Also, it is recommended that the plan be reviewed periodically, sometimes even on a daily basis in order to verify that all the base assumptions are still valid and that the implementation plan is progressing according to expectations.
.
.
REFINEMENT OF THE PRODUCT REQUIREMENTS
“The hardest single part of building a software system is deciding what to build. No other part of the conceptual work is as difficult in establishing the detailed technical requirements, including the interfaces to people, to machines, and to other software systems. No other part of the work so cripples the results if done wrong. No other part is more difficult to rectify later. Therefore, the most important function that the software builder performs for the client is the iterative extraction and refinement of the product requirements.”
—Fred Brooks