Software Development Life Cycle

The ideas about the software development life cycle (SDLC) have been around for a long time and many variations exist, such as the waterfall, and the V-model. These variations have many versions varying from those which are just guiding principles, to rigid systems of development complete with processes, paperwork, and people roles. However underlying all these are a set of common principles.

SDLC Common Principles

The common principles behind the SDLC are: 1. The process of developing software consists of a number of phases. 2. These phases are arranged in a precedence sequence of when they start. 3. The sequence of phases represents the passage through time of the software development. 4. Phases can and do overlap as previous phases are revisited, when more information becomes available. 5. The software becomes more complex and useful as the phases are followed. These principles apply to whichever particular variation of the SDLC is looked at, with emphasis being placed on particular principles in each variation

SDLC Common Phases

As you look at the various methods they all have a number of particular phases they recommend. On myV-Model page I show a specific set of phases. This set is practical, but is not the definitive answer for all software development. The VModel example is just to demonstrate the issues to be considered in development and how they affect each other. I propose the 4D model as a generic model for understanding the larger issues. This has four phases: Decide What is it you want to build in software? Design How will you map these decisions to a software environment? Develop Build the software according to the designs. Demonstrate Prove that the software delivers what was required.

Decide Phase

The Decide phase covers all those activities involved in deciding what it is that you want to build. The products from this phase typically include: Business cases to justify what is wanted in terms of business benefit. Feature lists of what is wanted to be included to deliver that benefit. Use Cases to explore how the features would work together. Non-functional requirements are the performance and development constraints placed on the system. System Specification which maps between what is wanted in the real world and what is possible in a computer system.

This phase is frustrating one it is necessary but it can be perceived as delaying the eventual system. Also it requires a large commitment of users time to decide this, often while they are involved in doing their normal day job. As a result many projects have a poor set of deliverables from the Decide phase before the Design phase starts. If however there is a process to allow modification of these products throughout the project then the Decide products will improve.

Design Phase
The Design phase takes the products from the Decide phase and creates a design of the architecture and detail working of how the software system will deliver what is wanted. The key thing to note is that despite many efforts over the years there is no automatic way of deriving the Design products from the Decide products. Where this has been claimed before inevitably it has been by restricting the way the Decide products are written and forcing them to be expressed in the form of a computer design. However it is possible, and necessary, to compare the Design products with the Decide products to see if what is wanted has been included. The Design phase is done by the analyst and design team who should work closely with developers in the Develop team.

Develop Phase
The Develop phase is what most users consider to be what software development is about. Paradoxically in many ways it is the least important of the phases, even though it will consume a lot of the resources. The reason is that most systems are constructed from a set of standard parts with some configuration, some customisation, and some bespoke parts to make the system unique. These decisions would have been taken in the Design phase, and in the Develop phase the work of converting them into a software system takes place. The products from this phase then have to be shown to work.

Demonstrate Phase
The Demonstrate phase is about proving that the delivered system works and is what was wanted. This phase is not just about testing but contains activities such as document reviews and code walkthroughs. It has a high degree of overlap with the other phases as the earlier you can catch a problem results in higher quality in the final product. This phase is done by both the developers and the users.

SDLC Diagrams

Diagram 1 4D SDLC model

I have called these four phases a 4D model as it implies it is multi-dimensional including a time dimension. However these models are always depicted as a twodimensional diagram and as a result some of the universal features of a SDLC are obscured or lost. Diagram 1 - 4D SDLC - is a non standard way of showing a SDLC showing several of the principles including: 1. There are four phases representing different things to be done. 2. The phases follow each other in sequence shown by the overlap and moving up the complexity and time scales. 3. They move along the time scale. 4. Phases overlap implying that there is no fixed finish between the start of one phase and the start of the next. It also implies that previous phases are revisited when further information is found. 5. The phases rising up imply both increasing complexity and also the amount of effort required to reach a final product. This diagram is different compared with the normal waterfall approach such as in diagram 2 - Traditional SDLC.

Diagram 2 Waterfall SDLC model

Comparing this against the 5 principles shows: 1. 2. 3. 4. It also clearly shows the four phases. It also shows the precedence order. They also move along the time scale. However the diagram implies that there is a clear finish of each phase before the next starts. Very few Softeare Development Life Cycles recommend this, but this is the impression the diagram gives. 5. The products falling down give the visual impression of little effort being required, nor does it give an impression of the greater complexity being built up. In practise if people are thoroughly aware of what needs to be done then it does not matter what diagram is used. Therefore in the rest of this site we will use similar waterfall type diagrams.

Conclusion
There are many ways of structuring a software development life cycle, but all of them should follow the 4D phases. I illustrate two of these the Waterfall and V-Model on this site to show how they map against these common points.

Waterfall and V-Model Examples

Waterfall Model - the seven stages of a waterfall model and how they match the four phases of the SDLC. From Waterfall model to V-Model - how the V-Model is derived from the waterfall model. Types of Testing - what the V-Model is and the testing stages. Verification and Validation links to the V-Model.

Stakeholder may refer to: Stakeholder (corporate), a person, group, organization, or system who affects or can be affected by an organization's actions Consumer stakeholder, a person or group with an interest in a business or

organization Project stakeholder, a person, group or organization with an interest in a project Stakeholder theory, a theory that identifies and models the groups which are

stakeholders of a corporation or project event Stakeholder (law), a third party who temporarily holds money or property while its owner is still being determined Stakeholder analysis, the process of identifying those affected by a project or

Scope (project management)

From Wikipedia, the free encyclopedia

In project management, the term scope has two distinct uses: Project Scope and Product Scope. Project Scope "The work that needs to be accomplished to deliver a product, service, or result with the specified features and functions." [1] Product Scope "The features and functions that characterize a product, service, or result." [2] Notice that Project Scope is more work-oriented, (the hows,) while Product Scope is more oriented toward functional requirements. (the whats.) If requirements are not completely defined and described and if there is no effective change control in a project, scope or requirement creep may ensue. Scope creep management is important for effective project management. Projects are expected to meet strict deadlines with resource restraints, and an unvetted and unapproved change in the scope can affect the success of the project. Scope creep sometimes causes cost overrun. Scope creep is a term which refers to the incremental expansion of the scope of a project, which may include and introduce more requirements that may not have been a part of the initial planning of the project, while nevertheless failing to adjust schedule and budget. There are two distinct ways to separate scope creep management. The first is business scope creep, and the second is called features (also technology) scope creep. The type of scope creep management is always dependent upon on the people who create the changes.

Business scope creep management occurs when decisions that are made with reference to a project are designed to solve or meet the requirements and needs of the business. Business scope creep changes may be a result of poor requirements definition early in development, or the failure to include the users of the project until the later stage of the systems development life cycle. Scope management plan is one of the major Scope communication documents. The Project Scope Management Plan documents how the project scope will be defined, managed, controlled, verified and communicated to the project team and stakeholders/customers. It also includes all work required to complete the project. The documents are used to control what is in and out of the scope of the project by the use of a Change Management system. Items deemed out of scope go directly through the change control process and are not automatically added to the project work items. The Project Scope Management plan is included in as one of the sections in the overall Project Management plan. It can be very detailed and formal or loosely framed and informal depending on the communication needs of the project. Features (Technology) scope creep occurs when the scope creep is introduced by technologists adding features not originally contemplated. Customer-pleasing scope creep occurs when the desire to please the customer through additional product features adds more work to the current project rather than to a new project proposal. Gold-plating scope creep occurs when technologists augment the original requirements because of a bias toward "technical perfectionism" or because the initial requirements were insufficiently clear or detailed.

Basic constraints
Updated: January 21, 2005 Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

Basic constraints
Certification authorities (CAs) must have a certificate before they can issue certificates. They use the private key associated with this certificate to digitally sign issued certificates. When a CA obtains a certificate from another CA, the parent CA may want to control whether that certificate can be used to issue certificates to other certificate servers. This is a basic constraint. Basic constraints are used to ensure a certificate is only used in certain applications. An example is the path length that can be specified as a basic constraint. A path length is the maximum number of CA certificates above this one in a certification path. This path length constraint is used to ensure that CA certificates can only issue end entity certificates, not CA certificates. This is used to ensure that some certificates are used by a CA and some are used by other subjects.

Software Characteristics
General Specifications Elise is an assembly of homogenous softwares gathered within leading frame. Each functionnality has its own corresponding executable file, enabling a soft and modular evolution of the software. These modules are gathered within menus according to the three steps of the modelling and simulation processes : definition, calculation, vizualisation.

Description of the user's interface The modules are composed of graphic user's interfaces, both user friendly and ergonomic. The validity of the input data is controlled, an error window warning the user in case of error.

TECHNICAL CHARACTERISTICS

SOLARIS platforms, Languages : C, C++ The simulation calculation code was written in Fortran 77 language. The user's interfaces were written in OSF/Motif and IlogViews (for the most recent modules) languages. The graphic traces are displayed in X11 and GMT ( The Generic Mapping Tools ). The common methods are thematically grouped in several libraries : mathematics, geography, data, communications, etc ...

What is the Waterfall Model?

The waterfall model is a sequential software development model in which development is seen as flowing steadily downwards (like a waterfall) through several phases.

History of the Waterfall Model

In 1970 Royce proposed what is now popularly referred to as the waterfall model as an initial concept, a model which he argued was flawed (Royce 1970). His paper then explored how the initial model could be developed into an iterative model, with feedback from each phase influencing previous phases, similar to many methods used widely and highly regarded by many today. Despite Royce's intentions for the waterfall model to be modified into an iterative model, use of the "waterfall model" as a purely sequential process is still popular, and, for some, the phrase "waterfall model" has since come to refer to any approach to software creation which is seen as inflexible and non-iterative.

Usage of the waterfall model

In Royce's original waterfall model, the following phases are followed perfectly in sequential order:

Requirements specification

o
Design

Requirements are captured and set in stone.

A "blueprint" is drawn up for the developers to implement.

Implementation Integration Testing Installation Maintenance

The waterfall model maintains that one should move to a phase only when its preceding phase is completed and perfected. Phases of development in the waterfall model are thus discrete, and there is no jumping back and forth or overlap between them. As many find this approach particularly rigid, modifications have been made over the years and new variants of the model have emerged.

Criticism of the waterfall model

The waterfall model however is argued by many to be a bad idea in practice, mainly because of their belief that it is impossible to get one phase of a software product's lifecycle "perfected" before moving on to the next phases and learning from them. A typical problem is when requirements change midway through, resulting in a lot of time and effort being invalidated due to the "Big Design Up Front". In summary, the criticisms of a non-iterative development approach (such as the waterfall model) are as follows:

Poor flexibility; the majority of software is written as part of a contract with a client, and clients are notorious for changing their stated requirements. Thus the software project must be adaptable, and spending considerable effort in design and implementation based on the idea that requirements will never change is neither adaptable nor realistic in these cases. Unless those who specify requirements and those who design the software system in question are highly competent, it is difficult to know exactly what is needed in each phase of the software process before some time is spent in the phase "following" it. Constant testing from the design, implementation and verification phases is required to validate the phases preceding them. Users of the waterfall model may argue that if designers follow a disciplined process and do not make mistakes that there is no need to constantly validate the preceding phases. Frequent incremental builds (following the "release early, release often" philosophy) are often needed to build confidence for a software production team and their client. It is difficult to estimate time and cost for each phase of the development process. The waterfall model brings no formal means of exercising management control over a project and planning control and risk

management are not covered within the model itself.

Only a certain number of team members will be qualified for each phase, which can lead at times to some team members being inactive.

Gantt chart
From Wikipedia, the free encyclopedia

"Gantt" redirects here. For other uses, see Gantt (disambiguation).

A Gantt chart showing three kinds of schedule dependencies (in red) and percent complete indications.

A Gantt chart is a type of bar chart that illustrates a project schedule. Gantt charts illustrate the start and finish dates of the terminal elements and summary elements of a project. Terminal elements and summary elements comprise the work breakdown structure of the project. Some Gantt charts also show the dependency (i.e., precedence network) relationships between activities. Gantt charts can be used to show current schedule status using percent-complete shadings and a vertical "TODAY" line as shown here. Although now regarded as a common charting technique, Gantt charts were considered revolutionary when they were introduced[citation needed]. In recognition of Henry Gantt's contributions, the Henry Laurence Gantt Medal is awarded for distinguished achievement in management and in community service. This chart is used also in Information Technology to represent data that has been collected.
Contents
[hide]

1 Historical development 2 Advantages and limitations 3 Example

4 See also 5 References 6 External links

[edit]Historical

development

The first known tool of this type was reportedly developed in 1896 by Karol Adamiecki, who called it a harmonogram. Adamiecki did not publish his chart until 1931, however, and then only in Polish. The chart is named after Henry Gantt (18611919), who designed his chart around the years 19101915.[1]
[2]

One of the first major applications of Gantt charts was during the First World War. On the initiative of General William Crozier, then Chief of Ordnance these included that of theEmergency Fleet, the Shipping Board, etc.[3] In the 1980s, personal computers allowed for widespread creation of complex and elaborate Gantt charts. The first desktop applications were intended mainly for project managers and project schedulers. With the advent of the Internet and increased collaboration over networks at the end of the 1990s, Gantt charts became a common feature of web-based applications, including collaborative groupware.

[edit]Advantages

and limitations

Gantt charts have become a common technique for representing the phases and activities of a project work breakdown structure (WBS), so they can be understood by a wide audience all over the world. A common error made by those who equate Gantt chart design with project design is that they attempt to define the project work breakdown structure at the same time that they define schedule activities. This practice makes it very difficult to follow the 100% Rule. Instead the WBS should be fully defined to follow the 100% Rule, then the project schedule can be designed.[4] Although a Gantt chart is useful and valuable for small projects that fit on a single sheet or screen, they can become quite unwieldy for projects with more than about 30 activities[citation needed]. Larger Gantt charts may not be suitable for most computer displays. A related criticism is that Gantt charts communicate relatively little information per unit area of display. That is, projects are often considerably more complex than can be communicated effectively with a Gantt chart. Gantt charts only represent part of the triple constraints (cost, time and scope) of projects, because they focus primarily on schedule management. Moreover, Gantt charts do not represent the size of a

project or the relative size of work elements, therefore the magnitude of a behind-schedule condition is easily miscommunicated. If two projects are the same number of days behind schedule, the larger project has a larger impact on resource utilization, yet the Gantt does not represent this difference. Although project management software can show schedule dependencies as lines between activities, displaying a large number of dependencies may result in a cluttered or unreadable chart. Because the horizontal bars of a Gantt chart have a fixed height, they can misrepresent the timephased workload (resource requirements) of a project, which may cause confusion especially in large projects. In the example shown in this article, Activities E and G appear to be the same size, but in reality they may be orders of different magnitude. A related criticism is that all activities of a Gantt chart show planned workload as constant. In practice, many activities (especially summary elements) have front-loaded or back-loaded work plans, so a Gantt chart with percent-complete shading may actually miscommunicate the true schedule performance status.

[edit]Example
In the following example there are seven tasks, labeled A through G. Some tasks can be done concurrently (A and B) while others cannot be done until their predecessor task is complete (C cannot begin until A is complete). Additionally, each task has three time estimates: the optimistic time estimate (O), the most likely or normal time estimate (M), and the pessimistic time estimate (P). The expected time (TE) is computed using the formula (O + 4M + P) 6.

Time estimates Activity Predecessor Opt. (O) Normal (M) Pess. (P) Expected time

4.00

5.33

5.17

10

6.33

B, C

5.17

4.50

5.17

Once this step is complete, one can draw a Gantt chart or a network diagram.

A Gantt chart created using Microsoft Project (MSP). Note (1) the critical path is in red, (2) the slack is the black lines connected to non-critical activities, (3) since Saturday and Sunday are not work days and are thus excluded from the schedule, some bars on the Gantt chart are longer if they cut through a weekend.

Linear Sequential Models

updated Jun 15, 2009 6:11 pm | 13,061 views

[edit]

Linear Sequential Model

It is also called Classic Life Cycle or Waterfall model or Software Life Cycle suggests a systematic and sequential approach to software development that begins at the system level and progresses through analysis, design, coding, testing and support. The waterfall model derives its name due to the cascading effect from one phase. In this model each phase well defined starting and ending point, with identifiable deliveries to the next phase Analysis-->Design-->Coding-->Testing
[edit]

Advantages
Simple and a desirable approach when the requirements are clear and well understood at the beginning. It provides a clear cut template for analysis, design, coding, testing and support. It is an enforced disciplined approach

[edit]

Disadvantages
It is difficult for the customers to state the requirements clearly at the beginning. There is always certain degree of natural uncertainty at beginning of each project. Difficult and costlier to change when the changes occur at a later stages. Customer can see the working version only at the end. Thus any changes suggested here are not only difficult to incorporate but also expensive. This may result in disaster if any undetected problems are precipitated to this stage

Rational Unified Process (RUP)

E-mail Print A AA AAA LinkedIn Facebook Twitter Share This Reprints Rational Unified Process (RUP) is an object-oriented and Web-enabled program development methodology. According to Rational (developers of Rational Rose and theUnified 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
LEARN MORE

Software Quality Resources

Traditional Models (RUP, V-Model, CMMI, Waterfall)

the elaboration phase, developers analyze the project's needs in greater detail and define its architectural foundation; in the construction phase, developers create the application design and source code; and in thetransition phase, developers deliver the system to users. RUP provides a prototype at the completion of each iteration. The product also includes process support for Java 2 Enterprise Edition (J2EE) and BEA (WebLogic) development, and supplies an HTML-based description of the unified process that an organization can customize for its own use. Getting started with use Rational Unified Process To explore how Rational Unified Process is used in the enterprise, here are some additional resources for learning about RUP: Rational Unified Process learning resources: 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. Book excerpt: Implementing the IBM Rational Unified Process and Solutions (A Guide to Improving Your Software Development Capability and Maturity) This chapter focuses on key points to bring awareness and generate excitement about RUP. It outlines the ROI you might expect from implementing RUP and IBM Rational Solutions, common problems that these methods may solve and how to sell the executives on this process solution and tools. session prediction (credential/session prediction) , CGI scanner, session hijacking (TCP session hijacking) , Trusted Computing Group (TCG),release, pigs and chickens, Software Process Improvement and Capability dEtermination (SPICE) , denial of service (DoS) , HTTPS (HTTP over SSL or HTTP Secure), work breakdown structure (WBS)
RELATED GLOSSARY TERMS:

Analysis Modeling
The Analysis Model is the first technical representation of a system. Analysis Modeling uses a combination of text and diagrams to represent software requirements (data, function, and behavior) in an understandable way. Building analysis models helps make it easier to uncover requirement inconsistencies and omissions. Two types of analysis modeling are commonly used:

(1) Structured Analysis (2) Object-Oriented Analysis Data Modeling uses Entity-Relationship Diagrams to define data objects, attributes, and relationships. Functional Modeling uses Data Flow Diagrams (DFD) to show how data are transformed inside the system. Behavioral Modeling uses State Transition Diagrams to show the impact of events. Analysis work products must be reviewed for completeness, correctness, and consistency.

Work Products of Analysis Modeling:

Data object descriptions Entity relationship diagrams Data flow diagrams State transition diagrams Process specification and Control specifications

Analysis Model Elements:

Data dictionary

Lies at the core of the model. It is a repository that contains the descriptions of all data objects consumed or produced by the software.

Three different diagrams surround the core.

(1) Entity relationship diagram (ERD):

Depicts relationships between data objects

(2) Data flow diagram (DFD):

Serves two purposes: To provide an indication of how data are transformed as they move through the system; To depict the functions (and sub-functions) that transform the data flow (a function is represented in a DFD using a process specification or PSPEC)

(3) State transition diagram (STD):

Indicates how the system behaves as a consequence of external events, states are used to represent behavior modes. Arcs are labeled with the events triggering the transitions from one state to another (control information is contained in control specification or CSPEC)