How2Lab Logo
tech guide & how tos..


Seven steps to successful execution of Software projects


Software development is a field which provides scope for creativity and innovation. Developing successful software systems require painstaking efforts, careful study of requirements, taking high-quality design decisions, evolving a futuristic architecture, good programming practice, and a deep sense of commitment to excel.

A passionate software developer is always aspiring to better his skills and methods and keep his creative and innovative faculties alive, exploiting his abilities to the fullest to churn out each project with success. The developer gets an immense sense of achievement, pride and motivation when he sees his own creation put to beneficial real life use. No job can be more gratifying than this.

In this article I will make an attempt to reveal the typical pattern in which successful developers operate to execute software projects. Software development is a process. There are essentially 7 stages to the development process. I will deal with each stage in enough detail so that you understand and appreciate what they entail and why they are important.


STEP 1: Understand the Requirements

A software project begins with a client approaching the developer with a sketchy wish list of requirements. This is the trigger point for the developer to engage and take charge, sit down with the client along with some of their key end-users and carry out a detailed discussion. Listen carefully to the client and each user to get a perspective of what their goals and objectives are and what functionalities they require. Understand their business processes, ask questions, and make suggestions to activate the thought process of the end users.

This engagement will enable a deeper participation of the users who will help come out with a clearer specification. This process helps refine the sketchy wish list and crystallize the requirements. Remember, your client understands their business processes well and have a clear vision of their business needs. However, they do not understand the capabilities and the possibilities of software solution and hence there is a general tendency to simplify the requirements. Simplified description often leads to overlooking some of the key attributes of the business process, which if otherwise implemented in the software, could give them an operational edge. As a software expert, you are expected to facilitate the process of extracting this out from the client's team.

And, mark my words - if you succeed in doing this, you have already crossed the first hurdle of gaining your client's trust and confidence. Your positive contribution to steering this process will make the client comfortable in dealing with you, which means that later when you come out with a concrete proposal you will not have much difficulty in bagging the contract at a good price. Remember one thing - clients do not mind paying more if it gives them the confidence that they will get a product that will deliver and will indeed be beneficial.

Apart from crystallizing the processes, functionalities, and features required, an important activity at this stage is to also get a clear picture of the kind of data that the software should be designed to work upon and the kind of data it will output. You need to have a clear idea of what are the kinds of data that the software should be capable of handling, what is the volume of data it has to work upon daily, and whether there are any extreme data conditions. To appreciate what I mean by this let us look at an example.

A car dealer in a small town sells 2 cars everyday and hence generates 2 invoices per day. A large book store in the busy Connaught place market in Delhi generates 300 invoices per day. In a month the car dealer would populate the invoice database with 60 records, while the book store would have 9000 records. Over a period of 1 year the database of the book store would swell to more than 100,000 records while the car dealer would have a very small sized database. Further, invoices generated by the car dealer may contain 1-3 items, viz. the car, and perhaps few additional accessories that some customers may purchase. On the other hand, the book store may be supplying to schools and colleges and some invoices may contain a list of 200-300 books thereby running into several pages. Software design considerations would be quite different in these two cases of data situation. Planning for the output data, viz. the printed invoice will also be different in case of single page invoice viz-a-viz multi-page invoice.

Another aspect that you may need to understand at this stage is whether the client wants data of the immediate past to be fed into the software system, for the sake of smooth transition from manual system to software system. This may also be relevant when client already has an existing software system which is being revamped, in which case you may perhaps be asked to port the entire data from the old system to the new system. This would entail making special provisions in your software to facilitate quick/automated data migration and/or bulk data entry. Additional design consideration that will come into play in the latter case is to design a system that will enable switch over from the old system to the new system in the shortest possible time.

So, examining the data is an important aspect of the requirements gathering process.

Once the user requirements are clearly and fully understood, it will become much easier for you to devise a software solution for it. Bear in mind that despite all your diligent efforts at this stage, some things may still get missed out. Good developers, therefore, keep the end users engaged during the design and development stages as well. This is done by frequently demonstrating the software and various user interfaces, as they are built. This activity helps plug any functionality or features that were missed out, thus making it easier for you to incorporate them at an early stage of development rather than doing it after the entire software is built and deployed.



STEP 2: Freeze the Scope of work & Timeline

Once the general requirements are gathered from the client, you need to sit down with your own team to prepare a detailed scope of work document. Detailed description of functionalities, user interfaces, reports generated, etc. must be worked out in as much detail as possible. This document should also clearly state the exclusions, to avoid ambiguity and subsequent conflict.

As each component of work involves cost to you, this detailing is extremely important and your entire profitability will depend upon how clearly you have envisaged and communicated the scope of work to the client.

The scope of work document should also be accompanied by a project execution plan with clear-cut phase wise timelines and the overall project timeline. Cost incurred at the end of each phase of the development process should be worked out accurately and a payment schedule should also accompany your scope of work document. For large development projects professional project management software are used to create a detailed plan of resource versus timeline using PERT technique.

It is also a good idea to include a list of functionalities and features for future enhancement, thus opening the door to more work from the client in future and a continuing relationship.

The scope of work document would eventually become a legal document so that if there are ever disputes, any ambiguity of what was promised to the client can be clarified. An agreement on the scope of work should be reached, and written approval should be taken from the client. Eventually when you bag the order, this document should form a part of the clients order document.



STEP 3: Design the Solution

This is the most important stage and brings your real experience and expertise to the fore. In this stage you conceptualize the entire system before getting down to code writing. You focus on all technical and operational requirements and keep an overall vision of what the software system should do and how it should do it. The overall structure of the entire system is worked out without getting distracted by the nitty-gritty of coding and implementation details. Abstraction is the key.

The system is conceived to consist of multiple building blocks referred as software elements/components, with each element deemed to perform well defined roles and functions. Each element will serve a purpose, and the elements will interact with each other to make the complete software system. The entire process of planning and designing the solution is referred as architecting the system.

Software architecting is a vast subject. For brevity, I will list out some of the salient activities and considerations that this process entails. Activities include, conceptualizing and preparing the complete solution, documenting it well and communicating to all stake holders. A software architect has to work closely with the development team and also interact with the client during the entire architecting and development stage.


Key architecting activities

Here is summary of various activities at this stage:

  1. Conceptualization of the overall system structure.
  2. Break down of the structure into well defined elements/components each capable of performing a set of roles and functions and delivering a specialized service. These elements will form the building blocks of the software system.
  3. Identification of relationships among the software elements.
  4. Identification of cross-cutting components. Cross cutting components are those that operate across the entire breadth of the software system and interact with most of the other software elements. The functionalities these components handle, include - user authentication and authorization, exception management, communication, notification, caching, instrumentation & logging, data validation, etc.
  5. Defining standardized protocol(s) for communication amongst the software elements and cross-cutting components.
  6. Deciding on appropriate combination of architectural styles to use for interoperability of the software elements. The architectural styles considered, include - client/server, component-based architecture, domain driven design, layered architecture, message bus architecture, n-tier/3-tier, object-oriented, and service-oriented architecture. Suitable combinations of one or more of these architectural styles will be used depending upon the manner in which the software elements inter-operate to deliver service and the quality attributes required. Selection of architectural styles is also influenced by several other constraints such as existing infrastructure at the client, budget constraints, specific client preferences, capabilities and experience of your developers, etc.
  7. Selection of technology platform on which the software system will operate. The codes will be written accordingly using appropriate programming languages.
  8. Design of database, database tables and entity relationship diagrams.

Key design considerations

The key quality attributes that are kept in view while working with the above activities, include - performance efficiency, capacity to handle multiple users concurrently, reliability, security, fault-tolerance, maintainability, manageability, scalability, and adaptability to change in business processes and technology with time.

Other considerations include - configurability, reusability of design components and software elements, and ability to plug in additional functionalities without disruption after the software is deployed and is live. There are economic considerations as well which call for tradeoffs due to budget and technology constraints.


Simplification & organizing

When designing the system, the architect aims to minimize complexity by separating the design into three broad areas of concern, viz. business processing, data access, and user interface. Within each area, the components & software elements are designed to focus on that specific area and do not mix code from other areas of concern. For instance, user interface processing components will not include code to directly access a data source, instead it will make a service call to either business components or data access components to retrieve data.


Communicating your design

Communicating your design is critical for architecture reviews with client, as well as to ensure it is implemented correctly by your developers. You must communicate your architectural design to all the stakeholders including the development team, system administrators and operators, business owners, and other interested parties.


Periodic review of the architecture

It is important to revisit and review the architecture at major project milestones, as the development progresses. This will help identify and fix architectural problems at the earlier stage and will help prevent cost and time over-runs.


Documentation

Detailed recording of the design generated during the software architecting process is important. Documentation helps communicate the entire system to the developers and the client. It also helps in future maintenance and enhancements. This is treated as the final technical specification for the project and all developers are expected to code with strict adherence to the architecture, so that conceptual system integrity is preserved.


STEP 4: Build the System

After the architecture of the software system has been built and documented, a team of programmers/developers sit down to build the system. This stage is also known as the development stage and takes the longest time. The developers have at their disposal, a well documented design specification along with instructions on processes, standards and tools to be used. Now, they have to convert the design prepared by the architect, into a working system that takes care of all the requirements addressed in the design document. The next stage, viz. testing, also commences as the developers go along building the system.


Development activities entail

  • Building all the system elements and components. You must establish a standardized coding style and naming convention for development. Check to see if the client has established coding style and naming standards. If not, you should establish common standards. This provides a consistent model that makes it easier for team members to review code they did not write, leading to better maintainability.
  • Integrating the elements into larger components.
  • Preparing the technical environment/ infrastructure for the system.
  • Building a Proof of Concept. This is a skeleton system that tests key elements of the solution on a non-production simulation of the proposed operational environment. The team walks users through the solution to get their feedback and re-confirm their requirements before full-fledged coding begins.
  • Developing testing tools and pre-populated test data. Unit test cases are created and automated scripts are written to test each of the software elements individually as well as test their inter-operability with other elements.
  • Preparing code documents. As individual software elements and their integration components are built, it is the developers responsibility to document the internal design of the software fully. The documentation must cover - detailing the provisions, specific coding instructions, and procedures for issue tracking. Everything that help explain the functionality of the software must be documented so that the codes can in future be understood by other programmers when they need to do maintenance fine tweaking, or enhancements.
    The Integration documents will describe the assembly and interaction of the software elements with each other and also the interaction of the software elements with the hardware.
  • Preparing Implementation plan. This document will describe how the software system should be deployed in the production environment. Here you define all planned activities to ensure successful implementation of the entire software system.
  • Preparing Operation & Maintenance manual. This document will detail out necessary procedures and instructions that will be required by system administrators and the maintenance team to ensure smooth system operation. Various operational and maintenance procedures must be described, and standards used must be specified.
  • Preparing help documents and training manuals. This document will outline technical and user training needs. It must contain all necessary help instructions and explanations of implemented business rules and processes so that end users fully understand the system capabilities, configurability, and adaptability to change. Each user interface must accompany a context based help page which explains the fields and data validation requirements. Essentially, anything that helps users use the system to its full capability should be described in this documentation.


STEP 5: Test the System

As we have mentioned earlier, development and testing go hand-in hand. The testing process is designed to identify and address potential issues prior to deployment.

During the development stage, each software element is tested independently. Then, when the software elements are integrated together, more testing is done to test the integration fully on various scenarios. Automated scripts are written to perform testing.

After the entire system is ready, further testing is done by users, system administrators and maintenance team to evaluate the system and identify any remaining issues they need to address before releasing for real life use.

Test Analysis Reports are prepared that present a description of the unit tests and the results mapped to the system requirements. Testing helps identify system capabilities and deficiencies and hence proper selection of test data and real life use cases must be done.

The entire gamut of testing covers -

  • Code component testing
  • Database testing
  • Infrastructure testing
  • Security testing
  • Integration testing
  • User acceptance and usability testing
  • Stress, capacity, and performance testing. This will identify any issues with the systems architecture and design itself.


STEP 6: Deploy for Production

After the software system has been tested thoroughly and in its entirety, it is considered ready to be launched and is approved for release by a quality assurance team. Deployment is the final stage of releasing an application for real life use. If you reach this far in your project, you have succeeded - congratulations!

However, there are still things that can go wrong. You need to plan for deployment and you can use the deployment checklist that would have been prepared by the development team while documenting the Implementation plan.



STEP 7: Maintain the System

It is normal practice that clients tend to pass on this activity to the same company that did the development work. This is a continuous process and entails responding to user problems and resolving them quickly. You would be required to have a small dedicated or semi-dedicated team (depending upon the size of the software system), who would engage in the activity of tweaking and fine tuning the codes to accommodate day-to-day arising needs. Normally, a well designed software system should require minimal tweaking. Yet, in reality some minor tweaking may be required..

Maintaining and enhancing software to cope with newly discovered faults or requirements can take substantial time and effort, as missed requirements may force redesign of some modules of the software. This can be kept to the minimum by proper execution of the first 6 stages of the development process..

If you are also entrusted with the task of maintaining the server(s) and hardware infrastructure, server & network management would becaome an important activity. You will have to ensure that the server infrastructure on which your software system is running is up and running all the time. You may have signed an SLA (service level agreement) with the client to ensure a certain uptime say, 99.9% uptime. Ensuring this may require a small team to be constantly monitoring the server and other associated hardware.

Other activities may include taking offline backups, and archiving of old data. Some time of your maintenance team would also get spent in guiding users along.



The above steps are a gross simplification of what is involved in a software project. The sequencing of the 7 steps is not in strict order that after completion of one stage of activity the next stage will begin. Activities of all stages go on during the entire period in which the software development takes place. The sequencing only illustrates that in a relative timeline which stage is presiding over the others. In case of larger development projects, teams of experts are brought in at one or more of the above stages, with months of work and much money invested. The whole art of software development requires practice, years of experience and a diligent implementation of the development methodology. I hope the guidelines given in this article would be of some use to you.


Share:
Buy Domain & Hosting from a trusted company
Web Services Worldwide
About the Author
Rajeev Kumar
CEO, Computer Solutions
Jamshedpur, India

Rajeev Kumar is the primary author of How2Lab. He is a B.Tech. from IIT Kanpur with several years of experience in IT education and Software development. He has taught a wide spectrum of people including fresh young talents, students of premier engineering colleges & management institutes, and IT professionals.

Rajeev has founded Computer Solutions & Web Services Worldwide. He has hands-on experience of building variety of websites and business applications, that include - SaaS based erp & e-commerce systems, and cloud deployed operations management software for health-care, manufacturing and other industries.


Refer a friendSitemapDisclaimerPrivacy
Copyright © How2Lab.com. All rights reserved.