Multimedia Application Development Phases

An application is a collection of programs that satisfies certain specific requirements (resolves certain problems). The solution could reside on any platform or combination of platforms, from a hardware or operating system point of view.As with other operating systems, a multimedia application development is usually composed of the following phases:

• Design phase
• Gather requirements.
  • User, hardware and software requirements
  • Perform analysis.
  • Develop the design in its various iterations:
    • High-level design
    • Detailed design
  • Hand over the design to application programmers.
• Code and test application.
• Perform user tests.

User tests application for functionality and usability.

• Perform system tests.
  • Perform integration test (test application with other programs to verify that all programs continue to function as expected).
  • Perform performance (volume) test using production data.
• Go into production–hand off to operations.
• Ensure that all documentation is in place (user training, operation procedures).
• Maintenance phase--ongoing day-to-day changes and enhancements to application.

Figure 1 shows the process flow during the various phases of the application development life cycle.

Figure 1. Application development life cycle




Figure 2 depicts the design phase up to the point of starting development. Once all of the requirements have been gathered, analyzed, verified, and a design has been produced, we are ready to pass on the programming requirements to the application programmers.

Figure 2. Design phase




The programmers take the design documents (programming requirements) and then proceed with the iterative process of coding, testing, revising, and testing again, as we see in Figure 3.

Figure 3. Development phase



After the programs have been tested by the programmers, they will be part of a series of formal user and system tests. These are used to verify usability and functionality from a user point of view, as well as to verify the functions of the application within a larger framework (Figure 4).

Figure 4. Testing




The final phase in the development life cycle is to go to production and become steady state. As a prerequisite to going to production, the development team needs to provide documentation. This usually consists of user training and operational procedures. The user training familiarizes the users with the new application. The operational procedures documentation enables Operations to take over responsibility for running the application on an ongoing basis.
In production, the changes and enhancements are handled by a group (possibly the same programming group) that performs the maintenance. At this point in the life cycle of the application, changes are tightly controlled and must be rigorously tested before being implemented into production (Figure 5).

Figure 5. Production




As mentioned before, to meet user requirements or solve problems, an application solution might be designed to reside on any platform or a combination of platforms. As shown in Figure 6, our specific application can be located in any of the three environments: Internet, enterprise network, or central site. The operating system must provide access to any of these environments.

Figure 6. Growing infrastructure complexity



To begin the design process, we must first assess what we need to accomplish. Based on the constraints of the project, we determine how and with what we will accomplish the goals of the project. To do so, we conduct interviews with the users (those requesting the solution to a problem) as well as the other stakeholders.
T
he results of these interviews should inform every subsequent stage of the life cycle of the application project. At certain stages of the project, we again call upon the users to verify that we have understood their requirements and that our solution meets their requirements. At these milestones of the project, we also ask the users to sign off on what we have done, so that we can proceed to the next step of the project.

Figure 7. Specification
Specification is the task of precisely describing the problem description, often in a mathematically rigorous way, in most cases actually building a more or less complete model of the problem to be solved. A wide array of specification techniques exist, and many application areas rely on dedicated specification techniques. In practice, most successful specifications are written to understand and fine-tune applications that were already well-developed. Specifications are most important for external interfaces, that must remain stable. This is often refered to as software interface specifications. Note that internal software interfaces are generally established in the design phase of development, which makes this kind of specification a design artifact. However, some systems have external software interfaces with other existing systems. The specification of these interfaces then becomes something that is very important to specify in the early phases of development, and is thus really considered a specification artifact.


Figure 8. Implementation
Reducing a design to code may be the most obvious part of the software engineering job, but it is not necessarily the largest portion. A common fallacy in software development practice is that coding should be the main focus in software development. Such a misconception is a popular reason for low software quality or software project failure. Note that effective programmers have to deal with quality factors, and provide qualities such as code readability, maintainability, and often test the code as they are writing it.


Figure 9. Documentation
An important (and often overlooked) task is documenting the internal design of software for the purpose of future maintenance and enhancement. Without documentation, software maintainers (who are in most cases the authors of the code they maintain) only have extremely low level design information, i.e. the code itself, to unserstand the software they have to change. For example, good software documentation presents the software in various levels of abstraction, permitting the reader to easily understand the functioning of the software and to assess the location and impact of the chages to be applied.


Figure 10. Maintenance
Maintaining and enhancing software to cope with newly discovered problems or new requirements can take far more effort than the initial development of the software. Not only may it be necessary to add code that does not fit the original design but just determining how software works at some point after it is completed may require significant effort. About 2/3 of all software engineering work is maintenance, but this statistic can be misleading. A small part of that is fixing bugs. Most maintenance is extending systems to do new things, or adapti it to a new environment, which in many ways can be considered new work. Similarly, about 2/3 of all civil engineering, architecture, and construction work is maintenance.

Figure 11. Requirements Analysis
Extracting the requirements of a desired software product is the first task in creating it. While customers probably believe they know what the software is to do, it may require skill and experience in software engineering to recognize incomplete, ambiguous or contradictory requirements. Requirements analysis can itself be broken down in sub-activities. This phase is often the topic of processes itself, often refered to as the requirements process, or even requirements engineering process, the latter title being debatable. Requirements analysis methodologies have been created, one of the most popular being the use case driven methodology.


Figure 12. Coding
If you're part of a group and you chose to create the project with OOP, everyone can work on a part of the software, thus saving time for troubleshooting. Compilation of works can be done either at the very end or at every functional block of the program. I suggest completing the working first before changing it's looks to make it more appealing.

Figure 13. Launch
Make sure that your client is knowledgeable about the full workings of the project by giving a brief. Although it is easier to go with a silent launch, with the software simply slipping into the market, it's better for both your client and probable customers if information about it is made available. Make a site about the software and provide FAQs and customer support.

Figure 14. Research
Choose the platform you wish to implement your software. Several factors like OS compatibility, the overall budget of the software from development to launch as well as maintenance, reliability, portability etc, depends entirely on what language you will be using. Some languages are best suited for one type of job while others are not. Be flexible to adapt what language suits your project better than what you are more comfortable with. Your choice of platform should include other details like databases, web servers etc. Make certain that they fit your project's purpose and can withstand the load/s it will receive.

Figure 15. Testing and Optimization
More often referred to as "debugging," testing uses the Use Case entries of the UML. In simple terms, you simply use and re-use your program with on a give "case" and figure out if things are working properly. If you see things are working perfectly, check for any part of the software where slow-downs and inconsistencies occur. You can release demos and beta versions to the public and have the users report any bugs and/or complaints they have with the project. It also serves as advertising of sorts.

Figure 16. Modeling
Focus first on the backbone processes of your system. Try to emulate what functions or methods are necessary to complete the basic flow of your software project and generate an output. At this point, you should decide whether to implement everything with classes or not. Class implementation can be time consuming, especially for large projects, and is probably the most difficult aspect of programming at times which is why many novices shy away from OOP. Using classes all keeps your code neat and easy to read, saving you hours of frustrations in maintenance and troubleshooting. Additional features can be added after you've completed the essential sections of your project.


Sources:
1. http://newton.cs.concordia.ca/~paquet/wiki/index.php/Software_Development_Phases

2. http://sylv3rblade.hubpages.com/hub/Stages_of_Software_Development