• Search for:

    No middle companies please. I sign contracts directly with the end company. No intermediaries please.
    All customers must provide the current information system analysis and design, prior to engaging into any type of negotiation for any type of contract programming project.
    I can not negotiate anything based on plain ideas, nor a phone conversation. If the “system analysis and design” is not available, hasn’t been created, nor provided, then the first 40 hours or more of any project contracted with me should be devoted to that task “first”, prior to any software development negotiation and final contracting.
    There are two types of contracts that I can negotiate and ultimately accept if the conditions are appropriate to both parties:

    • Information System Analysis and Design.-Design by Contract ( DbC ), also known as contract programming, programming by contract and design-by-contract programming, is an approach for analyzing information systems and designing software. It prescribes that software designers should define formal, precise and verifiable interface specifications for software components which extend the ordinary definition of abstract data types with preconditions, post-conditions and invariants. These specifications are referred to as “contracts”, in accordance with a conceptual metaphor with the conditions and obligations of business contracts.  The DbC approach assumes all client components that invoke an operation on a server component will meet the preconditions specified as required for that operation. Where this assumption is considered too risky (as in multi-channel client-server or distributed computing) the opposite “defensive design” approach is taken, meaning that a server component tests (before or while processing a client’s request) that all relevant preconditions hold true, and replies with a suitable error message if not. The central idea of DbC is a metaphor on how elements of a software system collaborate with each other on the basis of mutual obligations and benefits. The metaphor comes from business life, where a “client” and a “supplier” agree on a “contract” that defines for example that:
      • The supplier must provide a certain product (obligation) and is entitled to expect that the client has paid its fee (benefit).
      • The client must pay the fee (obligation) and is entitled to get the product (benefit).
      • Both parties must satisfy certain obligations, such as laws and regulations, applying to all contracts.

      Similarly, if a routine from a class in object-oriented programming provides a certain functionality, it may:

      • Expect a certain condition to be guaranteed on entry by any client module that calls it: the routine’s precondition—an obligation for the client, and a benefit for the supplier (the routine itself), as it frees it from having to handle cases outside of the precondition.
      • Guarantee a certain property on exit: the routine’s post-condition—an obligation for the supplier, and obviously a benefit (the main benefit of calling the routine) for the client.
      • Maintain a certain property, assumed on entry and guaranteed on exit: the class invariant.

      The contract is semantically equivalent to a Hoare triple which formalizes the obligations. This can be summarized by the “three questions” that the designer must repeatedly answer in the contract:

      • What does contract expect?
      • What does contract guarantee?
      • What does contract maintain?

      Many programming languages have facilities to make assertions like these. However, DbC considers these contracts to be so crucial to software correctness that they should be part of the design process. In effect, DbC advocates writing the assertions first. Contracts can be written by code comments, enforced by a test suite, or both, even if there is no special language support for contracts.
      The notion of a contract extends down to the method/procedure level; the contract for each method will normally contain the following pieces of information:

      • Acceptable and unacceptable input values or types, and their meanings
      • Return values or types, and their meanings
      • Error and exception condition values or types that can occur, and their meanings
      • Side effects
      • Preconditions
      • Post-conditions
      • Invariants
      • (more rarely) Performance guarantees, e.g. for time or space used

      Sub-classes in an inheritance hierarchy are allowed to weaken preconditions (but not strengthen them) and strengthen post-conditions and invariants (but not weaken them). These rules approximate behavioral sub-typing.
      All class relationships are between client classes and supplier classes. A client class is obliged to make calls to supplier features where the resulting state of the supplier is not violated by the client call. Subsequently, the supplier is obliged to provide a return state and data that does not violate the state requirements of the client. For instance, a supplier data buffer may require that data is present in the buffer when a delete feature is called. Subsequently, the supplier guarantees to the client that when a delete feature finishes its work, the data item will, indeed, be deleted from the buffer. Other design contracts are concepts of “class invariant”. The class invariant guarantees (for the local class) that the state of the class will be maintained within specified tolerances at the end of each feature execution.
      When using contracts, a supplier should not try to verify that the contract conditions are satisfied; the general idea is that code should “fail hard”, with contract verification being the safety net. DbC’s “fail hard” property simplifies the debugging of contract behavior, as the intended behavior of each routine is clearly specified. This distinguishes it markedly from a related practice known as defensive programming, where the supplier is responsible for figuring out what to do when a precondition is broken. More often than not, the supplier throws an exception to inform the client that the precondition has been broken, and in both cases—DbC and defensive programming—the client must figure out how to respond to that. DbC makes the supplier’s job easier.
      Design by contract also defines criteria for correctness for a software module:

      • If the class invariant AND precondition are true before a supplier is called by a client, then the invariant AND the post-condition will be true after the service has been completed.
      • When making calls to a supplier, a software module should not violate the supplier’s preconditions.

      Design by contract can also facilitate code reuse, since the contract for each piece of code is fully documented. The contracts for a module can be regarded as a form of software documentation for the behavior of that module.

     

    • Software/Application Development.- A software development process (also known as a software development methodology, model, or life cycle) is a framework that is used to structure, plan, and control the process of developing information systems. A wide variety of such frameworks have evolved over the years, each with its own recognized strengths and weaknesses. There are several different approaches to software development: some take a more structured, engineering-based approach to developing business solutions, whereas others may take a more incremental approach, where software evolves as it is developed piece-by-piece. One system development methodology is not necessarily suitable for use by all projects. Each of the available methodologies is best suited to specific kinds of projects, based on various technical, organizational, project and team considerations.Most methodologies share some combination of the following stages of software development:
      • Analyzing the problem
      • Market research
      • Gathering requirements for the proposed business solution
      • Devising a plan or design for the software-based solution
      • Implementation (coding) of the software
      • Testing the software
      • Deployment

     

    • Maintenance and bug fixing. These stages are often referred to collectively as the software development life-cycle, or SDLC. Different approaches to software development may carry out these stages in different orders, or devote more or less time to different stages. The level of detail of the documentation produced at each stage of software development may also vary. These stages may also be carried out in turn (a “waterfall” based approach), or they may be repeated over various cycles or iterations (a more “extreme” approach). The more extreme approach usually involves less time spent on planning and documentation, and more time spent on coding and development of automated tests. More “extreme” approaches also promote continuous testing throughout the development life-cycle, as well as having a working (or bug-free) product at all times. More structured or “waterfall” based approaches attempt to assess the majority of risks and develop a detailed plan for the software before implementation(coding) begins, and avoid significant design changes and re-coding in later stages of the software development life cycle planning.There are significant advantages and disadvantages to the various methodologies, and the best approach to solving a problem using software will often depend on the type of problem. If the problem is well understood and a solution can be effectively planned out ahead of time, the more “waterfall” based approach may work the best. If, on the other hand, the problem is unique (at least to the development team) and the structure of the software solution cannot be easily envisioned, then a more “extreme” incremental approach may work best.

    Fees and Terms

    I am fully negotiable in situations where a long term contract is anticipated. (Ex: 6/12/18/or 24 month contracts).
    For non-time termed contracts and/or sporadic works, I normally charge: $125.00 USD/hour, for any consulting or programming service. Fees must be paid in advance on a weekly basis. No intermediaries please.
    For example: 40 hours x $125 = $5,000 USD), 8 hrs./day minimum. A work hour includes: 50 minutes of work and 10 minutes of paid time for any necessary preparation and/or personal use at the discretion of the programmer. Personal time should not exceed 10 minutes per hour and/or 1 hour per an 8 hour work day.
    A “PROJECT PROPOSAL” must be able to complete in no later than one week.  But due to the nature of each assignment; it may involve more time than that. Please be aware that producing, revising or analyzing a “Project Proposal” may take longer than one week of work.

    Rules, Refunds, Warranties or Guaranties

    There are no refunds nor warranties or guaranties of any kind (or any type available) on this type of work. All services contracted with me will be performed to the best of my knowledge and expertise, “all in good faith”.
    Unless the project is very extensive, we may need one or more additional weeks to complete the “Project Proposal”. If we both agree to continue with the production in more than one week, you will be billed at the same rate minus a one-time discount of 10% after the first week; otherwise, all works completed to the end of the 5th day of work will be delivered and understood as “job completed”.

    Contracted works must be paid in advance

    Deliveries to the customer will be made in full at the end of each 5th day of work. Both, consulting and programming services are to be considered as “completed at full satisfaction” at the end of each term.
    All work performed has no warranties nor guaranties of any kind. If you decide that a particular module must be changed or improved, you will be billed for the extra time it takes to make those requested changes on the source code, even in circumstances that it was the programmer’s fault and/or mistake.
    Your involvement and/or availability during the production of the “Project Proposal” as well as during the development time itself “is mandatory”. If you are not able to participate, you must designate a person responsible on your behalf. Not being able to participate during the development time, it does not constitute an understanding to postpone or extend the “end-date” or “delivery date” contracted, which it will conclude at the end of the 5th day of each contracted week.
    Days and hours of work are continuous, never alternated nor chosen at free will. You, (the customer), will be billed for all dead time as well, if any.
    Example of weeks contracted: MON-FRI, TUE-MON, WEN-TUE, THR-WEN, or FRI-THR.
    Unless there was a mandatory holiday, most “Project Proposals” for small business applications will be completed in one to two weeks at the most, developing and/or analyzing a Project Proposal “is a requirement” before starting actual development.
    Need more information or wish to negotiate a contract assignment?
    For more information please call anytime at: +1-713-714-7852 Or send me an email to: support@daprose.com
    No middle companies please. I sign contracts directly with the end company. No intermediaries please.