The most important task in creating a software product is extracting the requirements. Customers typically know what they want, but not what software should do, while incomplete, ambiguous or contradictory requirements are recognized by skilled and experienced software engineers. Frequently demonstrating live code may help reduce the risk that the requirements are incorrect.
Specification is the task of precisely describing the software to be written, possibly in a rigorous way. In practice, most successful specifications are written to understand and fine-tune applications that were already well-developed, although safety-critical software systems are often carefully specified prior to application development. Specifications are most important for external interfaces that must remain stable.
The architecture of a software system refers to an abstract representation of that system .Architecture is concerned with making sure the software system will meet the requirements of the product, as well as ensuring that future requirements can be addressed. The architecture step also addresses interfaces between the software system and other software products, as well as the underlying hardware or the host operating system.
Reducing a design to code may be the most obvious part of the software engineering job, but it is not necessarily the largest portion.
Testing of parts of software, especially where code by two different engineers must work together, falls to the software engineer.
An important (and often overlooked) task is documenting the internal design of software for the purpose of future maintenance and enhancement. Documentation is most important for external interfaces.
A large percentage of software projects fail because the developers fail to realize that it doesn't matter how much time and planning a development team puts into creating software if nobody in an organization ends up using it. People are occasionally resistant to change and avoid venturing into an unfamiliar area, so as a part of the deployment phase, its very important to have training classes for the most enthusiastic software users (build excitement and confidence), shifting the training towards the neutral users intermixed with the avid supporters, and finally incorporate the rest of the organization into adopting the new software. Users will have lots of questions and software problems which leads to the next phase of software.
Maintaining and enhancing software to cope with newly discovered problems or new requirements can take far more time 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 by a software engineer. About ? 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, which in many ways can be considered new work. In comparison, about ? of all civil engineering, architecture, and construction work is maintenance in a similar way.
V-Model
The V-Model defines a uniform procedure for IT product development. It is the standard for German federal administration and defense projects. As it is publicly available many companies also use it. It is a project management method comparable to PRINCE2 and describes methods for project management as well as methods for system development.
The current version of the V-Model is the V-Model XT (http://www.v-modell-xt.de) which was finalized February 2005. It is not really comparable to CMMI. While CMMI only describes "What" has to be done, the V-Model also describes "How" and "When" it has to be done and "Who" is responsible for doing it.
The V-model was developed to regulate the software development process within the German federal administration. It describes the activities and results that have to be produced during software development.
The V-model is a graphical representation of the system development lifecycle. It summarizes the main steps to be taken in conjunction with the corresponding deliverables within computerized system validation framework.
The left tail of the V represents the specification stream where the system specifications are defined. The right tail of the V represents the testing stream where the systems are being tested (against the specifications defined on the left-tail). The bottom of the V where the tails meet, represents the development stream.
The testing stream generally consists of
The salient features of our Application Development methodology are
- Installation Qualification
- Operational Qualification
- Performance Qualification
- The development stream can consist (depending on the system type and the development scope) in customization, configuration or coding
- Provide a great work environment and treat each other with respect and dignity.
- Apply the highest standards of excellence to the design, development ,Testing and delivery of our products and services.
- Prove and continuously build customer confidence.
- Contribute positively to our community and our environment.
- Recognize that profitability and growth are essential to our continuing success.
We adopt an elaborate Delivery Model for our Application Development projects.
- Integration of best of breed process and practices
- Flexibility in complying with customer specific or commercial AD framework
- A common Project Management framework for different project types / AD methods
- Robust process with suitable entry / exit criteria for full life cycle or phase level solutions.
- Automation of AD processes and usage of Metrics for process improvement.
Classical Waterfall Methodology
In the traditional Waterfall Methodology, first comes the analysis phase, then the design phase, followed by the implementation phase, with testing completing the process. Each of the phases have defined entry and exit criteria. Phase transition is triggered through management decision point by signing off phase-end deliverables. This methodology is called the Waterfall Methodology because each phase flows naturally into the next phase like water over a series of falls.
This methodology is best suited when the requirements are frozen up front and they are well-documented without any ambiguity.It is typically used for small projects.
Iterative and Incremental Development is a project development and management methodology, which allows for iterative project development and periodic progress measurement. This development methodology is derived from the well documented "helix /iterative" software engineering models.
The entire project cycle is sub-divided into vertical segments, called "slices" wherein each slice is a deliverable. Each slice is developed in isolation using the “waterfall model”. Developers will analyze, design, code and test in a tight loop.
The slices are vertical i.e. they are not sub-systems. Slices cut across as much of the functionality of the system as possible, being tangible sets of functionality that allow the user to get a look and feel. Slices represent features. In case of schedule slippages, certain functionality releases may be differed .Slices are executable and demonstrable. A slice typically will take a few weeks to complete.
This allows a tangible part of the project to be complete at the end of a slice. Complete testing is carried out in each iteration. The deliverables for each of the slices include an executable that meets the functionality, associated analysis and design documentation and test results.
This methodology facilitates better risk management, better control on the project schedule through better monitoring and early corrective actions and better requirements management in an incremental mode.
This methodology facilitates requirement evolution during the development as well as helps in managing larger projects
Top-down and bottom-up are strategies of information processing and knowledge ordering, mostly involving software, and by extension other humanistic and scientific system theories (see systemic's).
In the top-down model an overview of the system is formulated, without going into detail for any part of it. Each part of the system is then refined by designing it in more detail. Each new part may then be refined again, defining it in yet more detail until the entire specification is detailed enough to validate the model. The top-down model is often designed with the assistance of "dark boxes" that make it easier to bring to fulfillment but insufficient and irrelevant in understanding the elementary mechanisms.
In bottom-up design, first the individual parts of the system are specified in great detail. The parts are then linked together to form larger components, which are in turn linked until a complete system is formed. This strategy often resembles a "seed" model, whereby the beginnings are small, but eventually grow in complexity and completeness.
