The two approaches highlighted here are Agile Software Development and Software Engineering.

Agile software development is a group of software development methodologies that allow for evolving requirements. As requirements evolve through collaboration between different groups within organizations, it allows for more adaptive planning as the project develops on an evolutionary basis. Software development and delivery approaches encourage rapid and flexible response to change. It is a conceptual framework that promotes foreseen interactions throughout the development cycle.

Software engineering (SE) is the application of a systematic, disciplined, quantifiable approach to the software development process. In other words, it is the application of engineering to software development.  It is a systems approach to the application of engineering to software. Because it integrates significant mathematics, computer science and practices whose origins are in engineering.

A systems approach to the analysis, design, assessment, implementation, testing, maintenance and reengineering of software is at the core of engineering to software.

Our next software development post will discuss how to combine and blend the two approaches for optimal results.

When you come to PSI for systems and software engineering, the first thing we’ll do is listen. We want to make sure we understand the need that you’re trying to meet or the problem that you’re trying to solve. Once we know exactly what you want, we’ll put our team of experts to work for you. Our teams act as analysts and consultants, as well as engineers. We’ll help you find the answer that works best for your company, technically, managerially, and financially. If your company could use some assistance working out an engineering need, PSI should be your first and final stop.

If your company needs help developing a unique ERT System, call us at 215-672-1860. Our skilled team will be happy to help you develop the program you are looking for.

You may be thinking of developing it for yourself. Start by investigating the start-up costs and requirements. Begin your research with the understanding that they are quite different for Android apps and Apple apps, and if you’d like to release in both environments, its double. Also know that you’ll likely be splitting the revenue 70/30 with the app store in which your application is for sale. These things are all important, but they are ancillary to the biggest consideration. Are you comfortable with developing in objective C or java within the iOS or Android framework, respectively? You’ll want to have a bit of prowess in development for both PCs and embedded devices in order to timely turn your idea into a saleable app. After all, you may not be the only one undertaking an app like yours.

You may decide to go the route of having someone develop it for you. Before you approach a company, know and be comfortable with the answers to a few questions. How would you like to share in the risks and rewards of your idea? Will you be covering the cost of development in full or in part? If in part, are you willing to share the revenue from your idea with the company that helped you develop it? Also, be prepared to share enough about your idea to gauge the company’s interest and ability to develop it for you. Once you’ve shared some basics, you may want to request a mutual non-disclosure agreement or provide one of your own to ensure that the intellectual property you’ll be sharing is protected. Most importantly, make sure you can be comfortable working with the company. To bring a well thought-out, intuitive, and usable Android or iOS app to the market, you’ll be communicating frequently and discussing complex ideas in detail. One final note, be weary of a company that will offshore any of your development. Not every place around the globe affords the same level of intellectual property protection, and after all, content is king.

Couldn’t everyone use a vendor that provides high quality products and service and is continually improving?

Where are the documents? Does the potential vendor normally develop the project planning and design documentation UP FRONT? If they can’t be held to a plan and a design, it’s hard to hold them to a budget or a due date.

Do they regularly report their status? Does the potential vendor provide a weekly update on progress and planned activity? Can you get it in writing? Status reporting in plain language, on paper, gives you a gauge of the vendor’s progress and provides a structured means of feedback between design reviews.

How’s their past performance? Ask for references and call on them. In my experience, companies are more than willing to tell other (non-competitor) companies how a vendor has served them.

Look for answers to “How do they work?” over, “Have they done a job just like mine before?”. Experience relatable to your project is important, but it’s likely you aren’t making a replica of an existing device. I believe, it’s how a group handles the details of your particular application that will make or break your development.