Home work

Build-and-fix modelIn 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

Cost efficient for very small projects of limited complexity.

Disadvantages

Unsatisfying approach for products of reasonable size. Cost is higher for larger projects.

The Waterfall ModelWaterfall approach was first a 'Process Model' to be introduced and followed widely in software engineering to ensure success of the project. In the waterfall approach, the whole process of software development is divided into separate phases. These phases in waterfall model are:

a. Requirement specifications phaseb. Software designc. Implementationd. Testing and maintenance

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.

Advantages of the Waterfall Model

There is clear compartmentalization of work and control in the waterfall model. Since there is compartmentalization, it is easier to set schedule for the tasks to be completed within a specified time period.

Disadvantages of the Waterfall Model

The project is not partitioned in phases in a flexible way.

Spiral Model of Software Development

Spiral model is an evolutionary version of incremental prototyping, developed by Boehm in 1988. Each iteration of the prototype represented as a cycle in the spiral. The Spiral software development model is a risk-oriented. Spiral software development model may be applicable to projects where: The projects requirements are very difficult

Where new technologies are used

Advantages

1-Estimates (i.e. budget, schedule, etc.) become more realistic as work progresses, because important issues are discovered earlier.2-It is more able to cope with the (nearly inevitable) changes that software development generally entails.

Disadvantages

1. Highly customized limiting re-usability2. Applied differently for each application3. Risk of not meeting budget or schedule4. Risk of not meeting budget or schedule

V-Model (software development)The V-model represents a software development process (also applicable to hardware development) which may be considered an extension of the waterfall model. Instead of moving down in a linear way, the process steps are bent upwards after the coding phase, to form the typical V shape. The V-Model demonstrates the relationships between each phase of the development life cycle and its associated phase of testing. The horizontal and vertical axes represents time or project completeness (left-to-right) and level of abstraction (coarsest-grain abstraction uppermost), respectively.

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.

LimitsThe placing of contracts for services is not regulated.

The V-Model addresses software development within a project rather than a whole organization.

Extreme Programming (XP)"Extreme Programming (XP)" is one of the several agile processes, it stresses more on customer satisfaction rather than project delivery deadlines. It empowers software developers to confidently respond to changing customer requirements, even late in the life cycle. As a type of agile software process, it aims at dividing the entire software development project into smaller parts, which helps in reducing the cost of change or modification.

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

Agile software developmentAgile software development is a group of software development methods based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. It promotes adaptive planning, evolutionary development and delivery, a time-boxed iterative approach, and encourages rapid and flexible response to change. It is a conceptual framework that promotes foreseen interactions throughout the development cycle. The Agile Manifesto introduced the term in 2001.

The Agile software development life cycle is a set of methodologies as follows:

Scope. The Agile software development life cycle recognizes the complexity of system development.

Planning. The planning stage of the Agile software development life cycle involves the following considerations: specifying the opportunity available at hand, strategizing, and feasibility.

Initiation

Construction IterationsRelease

Iterations

Test-driven developmentTest-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

Test-driven development cycle

Add a test

Run all tests and see if the new one fails

Write some code

Run the automated tests and see them succeed

Refactor code

Repeat

Rapid application developmentRapid application development (RAD) is a software development methodology that uses minimal planning in favor of rapid prototyping. The "planning" of software developed using RAD is interleaved with writing the software itself. The lack of extensive pre-planning generally allows software to be written much faster, and makes it easier to change requirements.

Four phases of RAD

Requirements Planning phase User design phase Construction phase Cutover phase

Another version of RAD phases

Business Modeling: Data Modeling Process Modeling Application Generation Testing and Turn over

Rational Unified Process (RUP) Rational Unified Process (RUP) is an object-oriented and Web-enabled program development methodology. According to Rational (developers of Rational Rose and the Unified Modeling Language), RUP is like an online mentor that provides guidelines, templates, and examples for all aspects and stages of program development. RUP and similar products -- such as Object-Oriented Software Process (OOSP), and the OPEN Process -- are comprehensive software engineering tools that combine the procedural aspects of development (such as defined stages, techniques, and practices) with other components of development (such as documents, models, manuals, code, and so on) within a unifying framework.

RUP establishes four phases of development, each of which is organized into a number of separate iterations that must satisfy defined criteria before the next phase is undertaken: in the inception phase, developers define the scope of the project and its business case; in the elaboration phase

Unified Process Characteristics

Iterative and Incremental

Use Case Driven

Architecture Centric

Risk Focused

Project Lifecycle

The Unified Process divides the project into four phases:

Inception Elaboration Construction

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 didn’t 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 I’ve found it to be an incredibly effective management methodology for everyone involved, including developers and stakeholders. If you’re 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 ProcessesThe 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 client’s 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.

SOFTWARE DEVELOPMENT LIFE CYCLE

Planning/RequirementsRequirements analysis in systems engineering and software engineering, encompasses those tasks that go into determining the needs or conditions to meet for a new or altered product, taking account of the possibly conflicting requirements of the various stakeholders, such as beneficiaries or users.

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 specificationA 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

ImplementationIn 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.

CodingThere 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.

IntegrationIn 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.

TestingSoftware 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; and3. 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.

DocumentationSoftware 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.

Role of documentation in software development

Documentation is an important part of software engineering. Types of documentation include:

1. Requirements - Statements that identify attributes, capabilities, characteristics, or qualities of a system. This is the foundation for what shall be or has been implemented.

2. Architecture/Design - Overview of software. Includes relations to an environment and construction principles to be used in design of software components.

3. Technical - Documentation of code, algorithms, interfaces, and APIs.4. End User - Manuals for the end-user, system administrators and support staff.5. Marketing - How to market the product and analysis of the market demand.

DeploymentSoftware 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.

User training and supportTraining

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.

MaintenanceSoftware 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.

Bug fixes and new releasesA software bug is the common term used to describe an error, flaw, mistake, failure, or fault in a computer program or system that produces an incorrect or unexpected result, or causes it to behave in unintended ways. Most bugs arise from mistakes and errors made by people in either a program's source code or its design, and a few are caused by compilers producing incorrect code. A program that contains a large number of bugs, and/or bugs that seriously interfere with its functionality, is said to be buggy. Reports detailing bugs in a program are commonly known as bug reports, fault reports, problem reports, trouble reports, change requests, and so forth.

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.

Structured Programming versus Object-Oriented Programming Structured programming is task-centric, object oriented programming is data-centric

Task-centric vs. Data-centricStructured programming is based around data structures and subroutines. The subroutines are where stuff actually "happens", and the data structures are simply containers for the information needed by those subroutines.

Object oriented programming, on the other hand, shifts your primary focus to the data itself. Instead of asking "what do I want to do and what will I need to know to do it", you ask "what kind of things do I want to have and what can those things do for me". Instead of designing your functions first and then coming up with data structures to support them, you design types first and then come up with the operations needed to work with them.

Three OOP PrinciplesPerhaps the most important feature of OOP is polymorphism, the ability to identify certain aspects that several data types have in common, and write code that works equally well with all of them by ignoring the differences in situations where they don’t matter.

For example, consider a simple drawing program where you have a set of shapes (circles, rectangles, etc.) that share certain things in common (they all have a location, size, and color) but are different in other ways (how they look or whether they can be rotated). In a structured program, you’d write a function to draw a shape, containing logic like "if the shape is a circle, do ABC; if it’s a rectangle, do XYZ" and so on.

But in an OO program, you’d 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 you’d 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, there’s 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, you’d 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. LanguageWhether 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 doesn’t 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 Java’s OOP features, by putting all your code in a single class and using classes with public members just as you’d use structs in C.