Pages

Sunday, September 2, 2012

Software development process

Many students are well trained in coding because a majority of their time in university is focusing on coding but little on software development process. Some students consider software development is an individual work as they often receive individual assignments that each must do and most assignments are about writing code. When they go to work, many have a tendency to start coding immediately after receive an assignment without fully understand the problem. As requirements often change and they have to modify their code, they often make mistakes that need fixing. The more they are fixed, the more complex their code becomes. Eventually, it will be too difficult to understand the structure of their code and their logic for testing or maintaining. If developers just code and fix and do whatever they want then it would be difficult to integrate their codes into a cohesive software product.

When students are trained on software development process, they understand that development is not just writing code and it is a team effort. Before starting, the team must have common understanding of the problems that they must solve, the project goals, the project activities where each team member has certain roles and responsibilities for the work. The software process is a roadmap that shows the team how to develop software from the high level to the detail level. There is a sequence order called the development life cycle where the entire process is dividing into several phases and each has certain roles, responsibilities for team members.

The software process starts with the understanding of the problem by verify the requirements with customers. Because customers often do not describe their needs clearly and often change their minds, the team must make sure what customers have asked for is what they needs. Only when these requirements are discussed and confirmed, the team begins to document them into the software requirements specification. By following the process, the team understands that the most common cause of project failure is unstable or poorly defined requirements and by having the requirements fully validated they can reduce the risk of changing requirements. After having customers approved the requirements document, the team starts their own discussion to make sure that every team member understands the problem well enough before they divide the project into smaller tasks that they must do.

By following the software process, the team defines the architect of the system with several components. Team members identify the interfaces between these components and then verify that all components can be traced back to the requirements so that the product will meet customer’s needs. This is important because any error in architecture can create issues during software integration in later phase. When a project moves from requirements phase to architecture phase, the team will discover that there are many “Derived requirements” that need to be done. Sometime the list of derived requirements is much more than the original requirements because an architect must consider things such as performance, scalability, usability, and maintainability that customers expect but do not ask for. Based on the architecture, the team selects software tools that they will use to build the system. At the same time, team members can begin to create a set of unit tests to be applied once they finish their code. Many developers do not think about testing until they finish coding but if they start to develop unit tests early during architecture phase, they can avoid many mistakes that often happen during design phase. By working on unit tests early, they understand the requirements better that help them to design the product better.

Design phase is where the internal logic of each component is organized. During this phase, team members work on the details of the data structures and the algorithmic of each component. In architect phase, the main focus is on identifying the components and the relationship of these components and how they interact with each others. During the design phase, the focus is on designing the logic for each of the components. Team members follow a process and using a set of techniques and guidelines such as problem partitioning and abstraction. The use of abstraction allows team members to focus one task at a time, without worrying about the details of other tasks. When all tasks are done, the team should follow a verification process by having a review of the design of each component. Typically, the project manager, the system architect, and the quality assurance must participate in the review to make sure that all works are done according to the plan, the overall system architect, and in compliance with the standard process.

When a design is fully verified and approved. Team members can start the implementation phase (Coding). Many people like to write code right away but if they follow the process, they must select data structure that meets the needs of the design; keep the logic structure as simple as possible; select meaningful variable names consistent with the standards. By select data structure first, then start with a logical organization of the coding structure they can avoid a lot of mistake often happen during this phase. After complete the first coding, team member must conduct a code walk through to review their code to make sure they follow the coding standard and their structures are consistent with the way the project is organized and planned. Each team member must perform unit tests and correct uncovered errors before move to the next phase.

In the testing phase, team members transfer their code to the testing team. Testing is the process of executing a program with the intent of finding error. A good test is one that has a high probability of finding error. By following the process, team members understand that tests should be planed early during architecture phase and all tests should be traceable to customer requirements. Testing should start in the smallest part and progress toward testing in the larger part and eventually the entire software product. (Unit test, Function test, Integration test, System test etc.)
Prof John Vu    Carnegie Mellon University
Original source: http://www.segvn.org/forum/mvnforum/viewthread_thread,1461

0 comments:

Post a Comment