Professional Documents
Culture Documents
In this most simple model of software development, the product is constructed with minimal requirements and generally no specifications nor is any attempt at design, and testing most often neglected. This is a representation of what is happening in many software development projects. Note that this way of doing is not only a counter-example: it has its benefits in some situations.
Advantages
Disadvantages
Unsatisfying approach for products of reasonable size. Cost is higher for larger projects.
All these phases are cascaded to each other so that the second phase is started as and when a defined set of goals are achieved for first phase and it is signed off, and hence the name waterfall model. All the methods and processes undertaken in the waterfall model are more visible.
Disadvantages
1. Highly customized limiting re-usability 2. Applied differently for each application 3. Risk of not meeting budget or schedule 4. Risk of not meeting budget or schedule
Advantages
At each project start, the V-Model can be tailored into a specific project V-Model, this being possible because the V-Model is organization and project independent.
Limits
The placing of contracts for services is not regulated. The V-Model addresses software development within a project rather than a whole organization.
Extreme Programming methodology takes its name from the idea that the beneficial elements of traditional software engineering practices are taken to "extreme" levels. This methodology is best suited for large size projects wherein the project requirements may change over a period of time. We at, "Flash Application Development" are committed to deliver higher-end software projects based on XP model. The key features of Extreme Programming are as follows:
Project Division into Iterations Expecting Changes in the Project Requirements Simplicity & Clarity in Writing Programs Extensive Program Code Review Unit Testing & Flat Management Structure Frequent Client Interaction
Test-driven development
Test-driven development (TDD) is a software development process that relies on the repetition of a very short development cycle: first the developer writes a failing automated test case that defines a desired improvement or new function, then produces code to pass that test and finally refactors the new code to acceptable standards. Kent Beck, who is credited with having developed or 'rediscovered' the technique, stated in 2003 that TDD encourages simple designs and inspires confidence Test-driven development is related to the test-first programming concepts of extreme programming, begun in 1999,but more recently has created more general interest in its own right. Programmers also apply the concept to improving and debugging legacy code developed with older techniques
Project Lifecycle
The Unified Process divides the project into four phases:
Scrum (development)
For many developers in the software industry, the agile methodology is nothing new. Most folks know that agile was a direct response to the dominant project management paradigm, waterfall, and borrows many principles from lean manufacturing. In 2001, as this new management paradigm began to pick up momentum, agile was formalized when 17 pioneers of the agile methodology met at the Snowbird Ski Resort in Utah and issued the Agile Manifesto. Their manifesto is now considered the foundational text for agile practices and principles. Most importantly, the manifesto spelled out the philosophy behind agile, which places a new emphasis on communication and collaboration; functioning software; and the flexibility to adapt to emerging business realities. But for all of the strides the Agile Manifesto made in revising a philosophical approach to software development, it didnt provide the concrete processes that development teams depend on when deadlines and stakeholders start applying pressure. As a result, when it comes to the nuts and bolts of running a team with agile every day, organizations turn to particular subsets of the agile methodology. These include Crystal Clear, Extreme Programming, Feature Driven Development, Dynamic Systems Development Method (DSDM), Scrum, and others. At my organization, we use Scrum and Ive found it to be an incredibly effective management methodology for everyone involved, including developers and stakeholders. If youre interested in learning about the other agile methodologies, there are plenty of resources out there. This blog is designed to provide some essential background for those who are new to Scrum.
Software Processes
The software process is the way we produce software. It incorporates the methodology(Section 1.11) with its underlying software life-cycle model ( Chapter 2 ) and techniques,the tools we use (Sections 5.6 through 5.12), and most important of all, the individualsbuilding the software.Different organizations have different software processes. For example, consider theissue of documentation. Some organizations consider the software they produce to be selfdocumenting;that is, the product can be understood simply by reading the source code. Other organizations, however, are documentation intensive. They punctiliously draw upspecifi cations and check them methodically. Then they perform design activities painstakingly,check and recheck their designs before coding commences, and give extensivedescriptions of each code artifact to the programmers. Test cases are preplanned, the resultof each test run is logged, and the test data are meticulously fi led away. Once the producthas been delivered and installed on the clients computer, any suggested change must be proposedin writing, with detailed reasons for making the change. The proposed change can be made only with written authorization, and the modifi cation is not integrated into the productuntil the documentation has been updated and the changes to the documentation approved.
Requirements analysis is critical to the success of a development project.Requirements must be documented, actionable, measurable, testable, related to identified business needs or opportunities, and defined to a level of detail sufficient for system design. Requirements can be architectural, structural, behavioral, functional, and non-functional.
Requirements engineering
Systematic requirements analysis is also known as requirements engineering. It is sometimes referred to loosely by names such as requirements gathering, requirements capture, or requirements specification. The term requirements analysis can also be applied specifically to the analysis proper, as opposed to elicitation or documentation of the requirements, for instance. Requirements Engineering can be divided into discrete chronological steps:
Requirements elicitation, Requirements analysis and negotiation, Requirements specification, System modeling, Requirements validation, Requirements management.
Design specification
A design specification provides explicit information about the requirements for a product and how the product is to be put together. It is the most traditional kind of specification, having been used historically in public contracting for buildings, highways, and other public works, and represents the kind of thinking in which architects and engineers have been trained. Its use is called for where a structure or product has to be specially made to meet a unique need. For example, a design specification must include all necessary drawings, dimensions, environmental factors, ergonomic factors, aesthetic factors, cost, maintenance that will be needed, quality, safety, documentation and disposal
Implementation
In the implementation phase, the team builds the components either from scratch or by composition. Given the architecture document from the design phase and the requirement document from the analysis phase, the team should build exactly what has been requested, though there is still room for innovation and flexibility. For example, a component may be
narrowly designed for this particular system, or the component may be made more general to satisfy a reusability guideline. The architecture document should give guidance. Sometimes, this guidance is found in the requirement document. The implementation phase deals with issues of quality, performance, baselines, libraries, and debugging. The end deliverable is the product itself. There are already many established techniques associated with implementation. This thesis does not depend on which technique is followed.
Coding
There are a number of key points to remember when writing your code:
Linearity If using a procedural language make sure your code is linear and starts at the first executable statement and continues to a final return or end of block statement. If constructs - Avoid complicated "if" constructs. It is better to use several simpler nested "if" constructs rather than a complicated compound one. Generally keep it simple. Layout - Code layout is very important. It should be formatted to provide visual clues to the flow of the implementation. It is useful to agree on factors such as indentation, location of brackets, use of white space and line spacing used before the project starts. For example how long will your lines be? Will you use tabs or spaces? External Constants - Define constant values outside of the code as this makes maintenance easier. Changing hard-coded constants can be time-consuming and prone to human error. Error Handling - It is also important that you write in some form of error handling into the code. Portability - Portable code allows the source file to be compiled with any compiler and executed on any machines and operating system. Creating portable code is fairly complex. It is useful to keep machine dependent and machine independent code in separate files.
Integration
In engineering, system integration is the bringing together of the component subsystems into one system and ensuring that the subsystems function together as a system. In information technology, systems integrationis the process of linking together different computing systems and software applications physically or functionally,to act as a coordinated whole. The system integrator brings together discrete systems utilizing a variety of techniques such as computer networking, enterprise application integration, business process management or manual programming.
Testing
Software testing is an investigation conducted to provide stakeholders with information about the quality of the product or service under test.[1] Software testing can also provide an objective,
independent view of the software to allow the business to appreciate and understand the risks of software implementation. Test techniques include, but are not limited to, the process of executing a program or application with the intent of finding software bugs (errors or other defects). Software testing can be stated as the process of validating and verifying that a software program/application/product:
1. meets the requirements that guided its design and development; 2. works as expected; and 3. can be implemented with the same characteristics.
Software testing, depending on the testing method employed, can be implemented at any time in the development process. However, most of the test effort traditionally occurs after the requirements have been defined and the coding process has been completed. Although in the Agile approaches most of the test effort is, conversely, on-going. As such, the methodology of the test is governed by the software development methodology adopted. Different software development models will focus the test effort at different points in the development process. Newer development models, such as Agile, often employ test driven development and place an increased portion of the testing in the hands of the developer, before it reaches a formal team of testers. In a more traditional model, most of the test execution occurs after the requirements have been defined and the coding process has been completed.
Documentation
Software documentation or source code documentation is written text that accompanies computer software. It either explains how it operates or how to use it, and may mean different things to people in different roles.
Deployment
Software deployment is all of the activities that make a software system available for use.
The general deployment process consists of several interrelated activities with possible transitions between them. These activities can occur at the producer site or at the consumer site or both. Because every software system is unique, the precise processes or procedures within each activity can hardly be defined. Therefore, "deployment" should be interpreted as a general process that has to be customized according to specific requirements or characteristics. A brief description of each activity will be presented later.
To enable you to "Transform the Process of Innovation", Siemens PLM Software provides learning solutions that can transform the process of educating your staff. We have developed a training solutions tool set that provides you with faster time to value, increased productivity, and lower overall implementation costs. Our commitment to a 'blended solutions' approach provides our customers with a choice of training products and services that can be leveraged to fit the diverse needs of your user base.
Support
Once your system is installed, your focal point for software support is the Global Technical Access Center (GTAC). The center provides both your application and operating systems software support through telephone and electronic access. GTAC electronic support is available 24 x 7 at http://www.siemens.com/gtac. GTAC telephone support is available M - F from 5:00 AM to 5:00 PM Pacific Time in the US and Canada, and during normal business hours internationally.
Maintenance
Software maintenance in software engineering is the modification of a software product after delivery to correct faults, to improve performance or other attributes. A common perception of maintenance is that it merely involves fixing defects. However, one study indicated that the majority, over 80%, of the maintenance effort is used for non-corrective actions (Pigosky 1997). This perception is perpetuated by users submitting problem reports that in reality are functionality enhancements to the system Software maintenance and evolution of systems was first addressed by Meir M. Lehman in 1969. Over a period of twenty years, his research led to the formulation of Lehman's Laws (Lehman 1997). Key findings of his research include that maintenance is really evolutionary development and that maintenance decisions are aided by understanding what happens to systems (and software) over time. Lehman demonstrated that systems continue to evolve over time. As they evolve, they grow more complex unless some action such as code refactoring is taken to reduce the complexity.
The release management process is a relatively new but rapidly growing discipline within software engineering of managing software releases. As software systems, software development processes, and resources become more distributed, they invariably become more specialized and complex. Furthermore, software products (especially web applications) are typically in an ongoing cycle of development, testing, and release. Add to this an evolution and growing complexity of the platforms on which these systems run, and it becomes clear there are a lot of moving pieces that must fit together seamlessly to guarantee the success and long-term value of a product or project.
But in an OO program, youd simply tell the shape to draw itself, and the shape would know, based on its own type, what to do: you write a specialized drawing function when you define each shape, and when you send a "draw" message to any shape, it automatically calls the one for the correct shape type. Polymorphism eliminates the need for you to check what kind of shape it is: you just have to know that shapes can draw themselves, and let the shape worry about how it actually happens. Another important OO principle is encapsulation, the ability to bundle code and data together in one place and hide that data from the outside world, forcing anyone who wants to access it to go through the associated code. For example, all shapes have a location and a size, but the best representation might be different. A circle only needs three numbers (center X, center Y, and radius) but a rectangle needs four (top, bottom, left, right). Structured programming encourages code everywhere to deal directly with the innards of data structures, so most likely youd need to use the same representation for all shapes in order to avoid checking the type every time you wanted to measure a shape, even though that representation is wasteful for circles. Object oriented programming addresses that problem two ways: first, encapsulation says that the internal representation of a shape is off-limits to anyone else, so if you want to know how big a shape is, you have to call its getSize() method instead of reading its size directly out of memory. Second, polymorphism allows different shapes to implement their getSize() methods differently, allowing circles to use a more efficient version while presenting the same interface to the outside world. Finally, theres inheritance, which makes it easy to extend existing structures to produce new structures with slightly different behavior. For example, a filled circle is mostly the same as a regular circle, but it draws itself differently and also has a fill color. In a structured program, youd probably handle filled circles by adding a fill color to all shapes and a flag that indicates whether the shape is filled or not, and the fill color would simply go unused (wasting memory) in unfilled shapes. In an object-oriented program, you can make FilledCircle a subclass of Circle, inheriting all the existing circle behavior, and then replace the draw() method and add a place to store the fill color. Then if you changed something about Circle later, the change would automatically propagate to FilledCircle, while changes you made to FilledCircle would not affect any other shapes. Design vs. Language Whether your code is object oriented or merely structured depends partly on your choice of language, but also on your design. For example, the C language doesnt offer any features for object oriented programming, but with enough discipline you can still write object-oriented code in C, such as the GTK windowing library. On the other hand, you can write a Java program that completely fails to take advantage of Javas OOP features, by putting all your code in a single class and using classes with public members just as youd use structs in C.