Term Paper On Software Project Management

Software is one of the core fields of Computer Science.
If we look at the bigger field that is the Information Science and Technology, we will eventually find that how important is the field Software Project Management. Software is considered a product and it is technically too. We here, will understand the outline of Software Project Management. This term paper is written on the topic of Project Management with specific focus on Software area. The paper includes a brief layout of Software Project Management and Software Development Process. The paper has been designed in a structural way to outline the models and schematics of Software Project Management. I tried to deal with all the information regarding Software Project Management in a nutshell. The paper will give every reader a systematic overview of the mentioned topic. Though the topic is specifically meant for Computer Science and Engineering field, the overall paper will also give an objective sense of System Engineering. All the information provided here are collected from public domain documents and websites. All the trademarks and logos are the properties of their respective registered owner. This term paper is produced for educational and research purpose. Any kind of commercial publication is not solicited.
Project Management and Development Process of Software | Page No. 1
Contents:
1. Software A. Software B. History of Software C. Software Schematics 2. Project Management A. Project B. Project Management and Software Project Management C. Approaches of Project Management D. Traditional Approaches of Software Project Management E. Software Project Controlling System F. Systems Development Lifecycle and Software Development Process G. Software Development Life Cycle H. Software Development Models i. ii. iii. iv. v. vi. vii. viii. ix. Waterfall Model Spiral Model Iterative and Incremental Development V Model Dual Vee Model Rapid Application Development Extreme Programming Dynamic Systems Development Method Agile Development P - 10 P - 11 P - 12 P - 16 P - 22 P - 25 P - 30 P - 34 P - 34 P - 36 P - 39 P - 40 P - 44 P - 45 P - 47 P - 48 P - 50 P - 51 P - 52 P - 52 P - 54 P - 55 P - 58 P - 60 P-3 P-4 P-6
I. Management and Control in SDLC i. ii. Work Breakdown Structured Organization Matrix Management
J. Programming Style & Coding Convention i. ii. ISO 9000 (Project Standard) GNU Coding Standards
K. The Mythical Man-Month
3. Biblical Reference
P - 64
Software:
Computer software, or just software, is a collection of computer programs and related data that provides the instructions for telling a computer what to do and how to do it. Software refers to one or more computer programs and data held in the storage of the computer for some purposes. In other words, software is a set of programs, procedures, algorithms and its documentation concerned with the operation of a data processing system. Program software performs the function of the program it implements, either by directly providing instructions to the computer hardware or by serving as input to another piece of software. The term was coined to contrast to the old term hardware (meaning physical devices). In contrast to hardware, software "cannot be touched. Software is also sometimes used in a more narrow sense, meaning application software only. Sometimes the term includes data that has not traditionally been associated with computers, such as film, tapes, and records.
Computer software is so called to distinguish it from computer hardware, which encompasses the physical interconnections and devices required to store and execute (or run) the software. At the lowest level, executable code consists of machine language instructions specific to an individual processor. A machine language consists of groups of binary values signifying processor instructions that change the state of the computer from its preceding state. Programs are an ordered sequence of instructions for changing the state of the computer in a particular sequence. It is usually written in high-level programming languages that are easier and more efficient for humans to use (closer to natural language) than machine language. High-level languages are compiled or interpreted into machine language object code. Software may also be written in an assembly language, essentially, a mnemonic representation of a machine language using a natural language alphabet. Assembly language must be assembled into object code via an assembler.
History of Software:
The first theory about software was proposed by Alan Turing in his 1935 essay Computable numbers with an application to the Entscheidungs problem (Decision problem). The term "software" was first used in print by John W. Tukey in 1958. Colloquially, the term is often used to mean application software. In computer science and software engineering, software is all information processed by computer system, programs and data. The academic fields studying software are computer science and software engineering.
The history of computer software is most often traced back to the first software bug in 1946[citation needed]. As more and more programs enter the realm of firmware, and the hardware itself becomes smaller, cheaper and faster as predicted by Moore's law, elements of computing first considered to be software, joined the ranks of hardware. Most hardware companies today have more software programmers on the payroll than hardware designers, since software tools have automated many tasks of Printed circuit board engineers. Just like the Auto industry, the Software industry has grown from a few visionaries operating out of their garage with prototypes. Steve Jobs and Bill Gates were the Henry Ford and Louis Chevrolet of their times, who capitalized on ideas already commonly known before they started in the business. In the case of Software development, this moment is generally agreed to be the publication in the 1980s of the specifications for the IBM Personal Computer published by IBM employee Philip Don Estridge. Today his move would be seen as a type of crowd-sourcing.
Until that time, software was bundled with the hardware by Original equipment manufacturers (OEMs) such as Data General, Digital Equipment and IBM. When a customer bought a minicomputer, at that time the smallest computer on the market, the computer did not come with Pre-installed software, but needed to be installed by engineers employed by the OEM. Computer hardware companies not only bundled their software, they also placed demands on the location of the hardware in a refrigerated space called a computer room. Most companies had their software on the books for 0 dollars; unable to claim it as an asset (this is similar to financing of popular music in those days). When Data General introduced the Data General Nova, a company called Digidyne wanted to use its RDOS operating system on its own hardware clone. Data General refused to license their software (which was hard to do, since it was on the books as a free asset), and claimed their "bundling rights". The Supreme Court set a precedent called Digidyne v. Data General in 1985. The Supreme
Court let a 9th circuit decision stand, and Data General was eventually forced into licensing the Operating System software because it was ruled that restricting the license to only DG hardware was an illegal tying arrangement. Soon after, IBM 'published' its DOS source for free, and Microsoft was born. Unable to sustain the loss from lawyer's fees, Data General ended up being taken over by EMC Corporation. The Supreme Court decision made it possible to value software, and also purchase Software patents. The move by IBM was almost a protest at the time. Few in the industry believed that anyone would profit from it other than IBM (through free publicity). Microsoft and Apple were able to thus cash in on 'soft' products. It is hard to imagine today that people once felt that software was worthless without a machine. There are many successful companies today that sell only software products, though there are still many common software licensing problems due to the complexity of designs and poor documentation, leading to patent trolls.
With open software specifications and the possibility of software licensing, new opportunities arose for software tools that then became the de facto standard, such as DOS for operating systems, but also various proprietary word processing and spreadsheet programs. In a similar growth pattern, proprietary development methods became standard Software development methodology.
Software Schematics:
A Block Diagram of Software Schematics
Architecture
Users often see things differently than programmers. People who use modern general purpose computers (as opposed to embedded systems, analogue computers and supercomputers) usually see three layers of software performing a variety of tasks: platform, application, and user software.
Platform software: Platform includes the firmware, device drivers, an operating system, and typically a graphical user interface which, in total, allow a user to interact with the computer and its peripherals (associated equipment). Platform software often comes bundled with the computer. On a PC you will usually have the ability to change the platform software. Application software: Application software or Applications are what most people think of when they think of software. Typical examples include office suites and video games. Application software is often purchased separately from computer hardware. Sometimes applications are bundled with the computer, but that does not change the fact that they run as independent applications. Applications are usually independent programs from the operating system, though they are often tailored for specific platforms. Most users think of compilers, databases, and other "system software" as applications. User-written software: End-user development tailors systems to meet users' specific needs. User software includes spreadsheet templates and word processor templates. Even email filters are a kind of user software. Users create this software themselves and often overlook how important it is. Depending on how competently the user-written software has been integrated into default application packages, many users may not be aware of the distinction between the original packages, and what has been added by co-workers.
Documentation
Most software has software documentation so that the end user can understand the program, what it does, and how to use it. Without clear documentation, software can be hard to useespecially if it is very specialized and relatively complex like Photoshop or AutoCAD. Developer documentation may also exist, either with the code as comments and/or as separate files, detailing how the programs works and can be modified.
Library
An executable is almost always not sufficiently complete for direct execution. Software libraries include collections of functions and functionality that may be embedded in other applications. Operating systems include many standard Software libraries, and applications are often distributed with their own libraries.
Standard
Since software can be designed using many different programming languages and in many different operating systems and operating environments, software standard is needed so that different software can understand and exchange information between each other. For instance, an email sent from a Microsoft Outlook should be readable from Yahoo! Mail and vice versa.
Execution
Computer software has to be "loaded" into the computer's storage (such as the hard drive or memory). Once the software has loaded, the computer is able to execute the software. This involves passing instructions from the application software, through the system software, to the hardware which ultimately receives the instruction as machine code. Each instruction causes the computer to carry out an operation moving data, carrying out a computation, or altering the control flow of instructions. Data movement is typically from one place in memory to another. Sometimes it involves moving data between memory and registers which enable high-speed data access in the CPU. Moving data, especially large amounts of it, can be costly. So, this is sometimes avoided by using "pointers" to data instead. Computations include simple operations such as incrementing the value of a variable data element. More complex computations may involve many operations and data elements together.
Quality and Reliability

Software quality is very important, especially for commercial and system software like Microsoft Office, Microsoft Windows and Linux. If software is faulty (buggy), it can delete a person's work, crash the computer and do other unexpected things. Faults and errors are called "bugs." Many bugs are discovered and eliminated (debugged) through software testing. However, software testing rarely if ever eliminates every bug; some programmers say that "every program has at least one more bug" (Lubarsky's Law). All major software companies, such as Microsoft, Novell and Sun Microsystems, have their own software testing departments with the specific goal of just testing. Software can be tested through unit testing, regression testing and other methods, which are done manually, or most commonly, automatically, since the amount of code to be tested can be quite large. For instance, NASA has extremely rigorous software testing procedures for many operating systems and communication functions. Many NASA based operations interact and identify each other through
command programs called software. This enables many people who work at NASA to check and evaluate functional systems overall. Programs containing command software enable hardware engineering and system operations to function much easier together.
License
The software's license gives the user the right to use the software in the licensed environment. Some software comes with the license when purchased off the shelf, or an OEM license when bundled with hardware. Other software comes with a free software license, granting the recipient the rights to modify and redistribute the software. Software can also be in the form of freeware or shareware.
Patents
Software can be patented in some but not all countries; however, software patents can be controversial in the software industry with many people holding different views about it. The controversy over software patents is about specific algorithms or techniques that the software contains, which may not be duplicated by others and considered intellectual property and copyright infringement depending on the severity.
Project:
A project in business and science is typically defined as a collaborative enterprise, frequently involving research or design, that is carefully planned to achieve a particular aim. Projects can be further defined as temporary rather than permanent social systems that are constituted by teams within or across organizations to accomplish particular tasks under time constraints. The word project comes from the Latin word projectum from the Latin verb proicere, "to throw something forward" which in turn comes from pro-, which denotes something that precedes the action of the next part of the word in time (paralleling the Greek ) and iacere, "to throw". The word "project" thus actually originally meant "something that comes before anything else happens". When the English language initially adopted the word, it referred to a plan of something, not to the act of actually carrying this plan out. Something performed in accordance with a project became known as an "object".
Project Management:
Project management is the discipline of planning, organizing, securing, managing, leading, and controlling resources to achieve specific goals. A project is a temporary endeavour with a defined beginning and end (usually timeconstrained, and often constrained by funding or deliverables), undertaken to meet unique goals and objectives, typically to bring about beneficial change or added value. The temporary nature of projects stands in contrast with business as usual (or operations), which are repetitive, permanent, or semi-permanent functional activities to produce products or services. In practice, the management of these two systems is often quite different, and as such requires the development of distinct technical skills and management strategies.
The primary challenge of project management is to achieve all of the project goals and objectives while honouring the preconceived constraints. Typical constraints are scope, time, and budget. The secondaryand more ambitiouschallenge is to optimize the allocation of necessary inputs and integrate them to meet pre-defined objectives.
Software Project Management:

Software project management is the art and science of planning and leading software projects. It is a sub-discipline of project management in which software projects are planned, monitored and controlled.
Approaches of Project Management:

There are a number of approaches to managing project activities including lean, iterative, incremental, and phased approaches. Regardless of the methodology employed, careful consideration must be given to the overall project objectives, timeline, and cost, as well as the roles and responsibilities of all participants and stakeholders.
The Traditional Approach
A traditional phased approach identifies a sequence of steps to be completed. In the "traditional approach", five developmental components of a project can be distinguished (four stages plus control): 1. 2. 3. 4. 5. initiation planning and design execution and construction monitoring and controlling systems completion
Not all projects will have every stage, as projects can be terminated before they reach completion. Some projects do not follow a structured planning and/or monitoring process. And some projects will go through steps 2, 3 and 4 multiple times. Many industries use variations of these project stages. For example, when working on a brick-and-mortar design and construction, projects will typically progress through stages like pre-planning, conceptual design, schematic design, design development, construction drawings (or contract documents), and construction administration. In software development, this approach is often known as the waterfall model, i.e., one series of tasks after another in linear sequence. In software development many organizations have adapted the Rational Unified Process (RUP) to fit this methodology, although RUP does not require or explicitly recommend this practice. Waterfall development works well for small, well defined projects, but often fails in larger projects of undefined and ambiguous nature. The Cone of Uncertainty explains some of this as the planning made on the initial phase of the project suffers from a high degree of uncertainty. This becomes especially true as software development is often the realization of a new or novel product. In projects where requirements have not
been finalized and can change, requirements management is used to develop an accurate and complete definition of the behaviour of software that can serve as the basis for software development. While the terms may differ from industry to industry, the actual stages typically follow common steps to problem solving "defining the problem, weighing options, choosing a path, implementation and evaluation."
Critical Chain Project Management

Critical chain project management (CCPM) is a method of planning and managing project execution designed to deal with uncertainties inherent in managing projects, while taking into consideration limited availability of resources (physical, human skills, as well as management & support capacity) needed to execute projects. CCPM is an application of the Theory of Constraints (TOC) to projects. The goal is to increase the flow of projects in an organization (throughput). Applying the first three of the five focusing steps of TOC, the system constraint for all projects is identified as are the resources. To exploit the constraint, tasks on the critical chain are given priority over all other activities. Finally, projects are planned and managed to ensure that the resources are ready when the critical chain tasks must start, subordinating all other resources to the critical chain. The project plan should typically undergo resource levelling, and the longest sequence of resource-constrained tasks should be identified as the critical chain. In some cases, such as managing contracted sub-projects, it is advisable to use a simplified approach without resource levelling. In multi-project environments, resource levelling should be performed across projects. However, it is often enough to identify (or simply select) a single "drum". The drum can be a resource that acts as a constraint across projects, which are staggered based on the availability of that single resource. One can also use a "virtual drum" by selecting a task or group of tasks (typically integration points) and limiting the number of projects in execution at that stage.
Event Chain Methodology

Event chain methodology is another method that complements critical path method and critical chain project management methodologies. Event chain methodology is an uncertainty modelling and schedule network analysis technique that is focused on identifying and managing events and event chains that affect project schedules. Event chain methodology helps to mitigate the negative impact of psychological heuristics and biases, as well as to allow for easy modelling of uncertainties in the project schedules. Event chain methodology is based on the following principles. Probabilistic moment of risk: An activity (task) in most real-life processes is not a continuous uniform process. Tasks are affected by external events, which can occur at some point in the middle of the task. Event chains: Events can cause other events, which will create event chains. These event chains can significantly affect the course of the project. Quantitative analysis is used to determine a cumulative effect of these event chains on the project schedule. Critical events or event chains: The single events or the event chains that have the most potential to affect the projects are the critical events or critical chains of events. They can be determined by the analysis. Project tracking with events: Even if a project is partially completed and data about the project duration, cost, and events occurred is available, it is still possible to refine information about future potential events and helps to forecast future project performance. Event chain visualization: Events and event chains can be visualized using event chain diagrams on a Gantt chart.
Process-based Management
Also furthering the concept of project control is the incorporation of process-based management. This area has been driven by the use of Maturity models such as the CMMI (capability maturity model integration; see this example of a predecessor) and ISO/IEC15504 (SPICE software process improvement and capability estimation).
Agile Project Management

Agile project management approaches based on the principles of human interaction management are founded on a process view of human collaboration. This contrasts sharply with the traditional approach. In the agile software development or flexible product development approach, the project is seen as a series of relatively small tasks conceived and executed as the situation demands in an adaptive manner, rather than as a completely pre-planned process.
Traditional Approaches of Software Project Management

Traditionally, project management includes a number of elements: four to five process groups, and a control system. Regardless of the methodology or terminology used, the same basic project management processes will be used. Major process groups generally include:

Initiation Planning or development Production or execution Monitoring and controlling Closing
In project environments with a significant exploratory element (e.g., research and development), these stages may be supplemented with decision points (go/no go decisions) at which the project's continuation is debated and decided.
A Block Diagram of Traditional Approaches of Software Project Management
In the following context we will carefully analyse the traditional approaches of project management in Software Industry. This will help conceptualize the pattern and schematics of how a software project management works.
Initiating
The initiating processes determine the nature and scope of the software project. If this stage is not performed well, it is unlikely that the project will be successful in meeting the business needs. The key project controls needed here are an understanding of the business environment and making sure that all
necessary controls are incorporated into the project. Any deficiencies should be reported and a recommendation should be made to fix them. This step is the first and most important step of SPM. Softwares base is depended in this step. A software firm should carefully analyse the following areas: The software needs/requirements in measurable goals Reviewing of the current operations Financial analysis of the costs and benefits including a budget Stakeholder analysis, including users, and support personnel for the project Project charter including costs, tasks, deliverables, and schedule

Planning and Design

After the initiation stage, the project is planned to an appropriate level of detail. The main purpose is to plan time, cost and resources adequately to estimate the work needed and to effectively manage risk during project execution. As with the Initiation process group, a failure to adequately plan greatly reduces the project's chances of successfully accomplishing its goals. Project planning generally consists of:

Determining how to plan (e.g. by level of detail or rolling wave); Developing the scope statement; Selecting the planning team; Identifying deliverables and creating the work breakdown structure; Identifying the activities needed to complete those deliverables and networking the activities in their logical sequence; Estimating the resource requirements for the activities; Estimating time and cost for activities; Developing the schedule; Developing the budget; Risk planning; Gaining formal approval to begin work.
Additional processes, such as planning for communications and scope management, identifying roles and responsibilities, determining what to purchase for the project and holding a kick-off meeting are also generally advisable. For new product development projects, conceptual design of the operation of the final product may be performed concurrent with the project planning activities, and may help to inform the planning team when identifying deliverables and planning activities.
Executing
A Block diagram showing Executing Process Executing consists of the processes used to complete the work defined in the project plan to accomplish the project's requirements. Execution process involves coordinating people and resources, as well as integrating and performing the activities of the project in accordance with the project management plan. The deliverables are produced as outputs from the processes performed as defined in the project management plan and other frameworks that might be applicable to the type of project at hand.
Monitoring and Controlling
A Block Diagram Showing Monitoring and Controlling Processes
Monitoring and controlling consists of those processes performed to observe project execution so that potential problems can be identified in a timely manner and corrective action can be taken, when necessary, to control the execution of the project. The key benefit is that project performance is observed and measured regularly to identify variances from the project management plan. Monitoring and controlling includes: Measuring the on-going project activities ('where we are'); Monitoring the project variables (cost, effort, scope, etc.) against the project management plan and the project performance baseline (where we should be); Identify corrective actions to address issues and risks properly (How can we get on track again); Influencing the factors that could circumvent integrated change control so only approved changes are implemented.

In multi-phase projects, the monitoring and control process also provides feedback between project phases, in order to implement corrective or preventive actions to bring the project into compliance with the project management plan. Project maintenance is an ongoing process, and it includes:

Continuing support of end-users Correction of errors Updates of the software over time
A Block diagram Showing Monitoring and Controlling Cycle
In this stage, auditors should pay attention to how effectively and quickly user problems are resolved. Over the course of any construction project, the work scope may change. Change is a normal and expected part of the construction process. Changes can be the result of necessary design modifications, differing site conditions, material availability, contractor-requested changes, value engineering and impacts from third parties, to name a few. Beyond executing the change in the field, the change normally needs to be documented to show what was actually constructed. This is referred to as change management. Hence, the owner usually requires a final record to show all changes or, more specifically, any change that modifies the tangible portions of the finished work. The record is made on the contract documents usually, but not necessarily limited to, the design drawings. The end product of this effort is what the industry terms as-built drawings, or more simply, as built. The requirement for providing them is a norm in construction contracts. When changes are introduced to the project, the viability of the project has to be re-assessed. It is important not to lose sight of the initial goals and targets of the projects. When the changes accumulate, the forecasted result may not justify the original proposed investment in the project.
Closing
A Block Diagram Showing Closing Processes Closing includes the formal acceptance of the project and the ending thereof. Administrative activities include the archiving of the files and documenting lessons learned. This phase consists of: Project close: Finalize all activities across all of the process groups to formally close the project or a project phase Contract closure: Complete and settle each contract (including the resolution of any open items) and close each contract applicable to the project or project phase.
Software Project Controlling System:

Project controlling should be established as an independent function in project management. It implements verification and controlling function during the processing of a project in order to reinforce the defined performance and formal goals. The tasks of project controlling are also:

the creation of infrastructure for the supply of the right information and its update the establishment of a way to communicate disparities of project parameters the development of project information technology based on an intranet or the determination of a project key performance index system (KPI) divergence analyses and generation of proposals for potential project regulations the establishment of methods to accomplish an appropriate the project structure, project workflow organization, project control and governance creation of transparency among the project parameters
Fulfilment and implementation of these tasks can be achieved by applying specific methods and instruments of project controlling. The following methods of project controlling can be applied:

investment analysis costbenefit analyses value benefit Analysis expert surveys simulation calculations risk-profile analyses surcharge calculations milestone trend analysis cost trend analysis target/actual-comparison
Project control is that element of a project that keeps it on-track, on-time and within budget. Project control begins early in the project with planning and ends late in the project with post-implementation review, having a thorough involvement of each step in the process. Each project should be assessed for the appropriate level of control needed: too much control is too time consuming, too little control is very risky. If project control is not implemented correctly, the cost to the business should be clarified in terms of errors, fixes, and additional audit fees. Control systems are needed for cost, risk, quality, communication, time, change, procurement, and human resources. In addition, auditors should consider how important the projects are to the financial statements, how reliant the stakeholders are on controls, and how many controls existing. Auditors should review the development process and procedures for how they are implemented. The process of development and the quality of the final product may also be assessed if needed or requested. A business may want the auditing
firm to be involved throughout the process to catch problems earlier on so that they can be fixed more easily. An auditor can serve as a controls consultant as part of the development team or as an independent auditor as part of an audit. Businesses sometimes use formal systems development processes. These help assure that systems are developed successfully. A formal process is more effective in creating strong controls, and auditors should review this process to confirm that it is well designed and is followed in practice. A good formal systems development plan outlines: A strategy to align development with the organizations broader objectives Standards for new systems Project management policies for timing and budgeting Procedures describing the process Evaluation of quality of change
Project Manager and his/her Role:

A project manager is a professional in the field of project management. Project managers can have the responsibility of the planning, execution, and closing of any project, typically relating to construction industry, engineering, architecture, computing, and telecommunications. Many other fields in the production engineering and design engineering and heavy industrial have project managers. A project manager is the person accountable for accomplishing the stated project objectives. Key project management responsibilities include creating clear and attainable project objectives, building the project requirements, and managing the triple constraint for projects, which is cost, time, and scope. A project manager is often a client representative and has to determine and implement the exact needs of the client, based on knowledge of the firm they are representing. The ability to adapt to the various internal procedures of the contracting party, and to form close links with the nominated representatives, is essential in ensuring that the key issues of cost, time, quality and above all, client satisfaction, can be realized.
Software Project Management Triangle
The Software Project Management Triangle Like any human undertaking, projects need to be performed and delivered under certain constraints. Traditionally, these constraints have been listed as "scope," "time," and "cost. These are also referred to as the "project management triangle", where each side represents a constraint. One side of the triangle cannot be changed without affecting the others. A further refinement of the constraints separates product "quality" or "performance" from scope, and turns quality into a fourth constraint. The time constraint refers to the amount of time available to complete a project. The cost constraint refers to the budgeted amount available for the project. The scope constraint refers to what must be done to produce the project's end result. These three constraints are often competing constraints: increased scope typically means increased time and increased cost, a tight time constraint could mean increased costs and reduced scope, and a tight budget could mean increased time and reduced scope. The discipline of project management is about providing the tools and techniques that enable the project team (not just the project manager) to organize their work to meet these constraints.
System Development Life Cycle

and
Software Development Process

The Systems development life cycle (SDLC), or Software development process in systems engineering, information systems and software engineering, is a process of creating or altering information systems, and the models and methodologies that people use to develop these systems. In software engineering, the SDLC concept underpins many kinds of software development methodologies. These methodologies form the framework for planning and controlling the creation of an information system: the software development process. The SDLC is a process used by a systems analyst to develop an information system, training, and user (stakeholder) ownership. Any SDLC should result in a high quality system that meets or exceeds customer expectations, reaches completion within time and cost estimates, works effectively and efficiently in the current and planned Information Technology infrastructure, and is inexpensive to maintain and cost-effective to enhance. Computer systems are complex and often (especially with the recent rise of service-oriented architecture) link multiple traditional systems potentially supplied by different software vendors. To manage this level of complexity, a number of SDLC models or methodologies have been created, such as "waterfall"; "spiral"; "Agile software development"; "rapid prototyping"; "incremental"; and "synchronize and stabilize". SDLC models can be described along spectrum of agile to iterative to sequential. Agile methodologies, such as XP and Scrum, focus on lightweight processes which allow for rapid changes along the development cycle. Iterative methodologies, such as Rational Unified Process and dynamic systems development method, focus on limited project scope and expanding or improving products by multiple iterations. Sequential or big-design-up-front (BDUF) models, such as Waterfall, focus on complete and correct planning to guide large projects and risks to successful and predictable results. Other models, such as Anamorphic Development, tend to focus on a form of development that is guided by project scope and adaptive iterations of feature development. In project management a project can be defined both with a project life cycle (PLC) and an SDLC, during which slightly different activities occur. According to Taylor (2004) "the project life cycle encompasses all the activities of the project, while the systems development life cycle focuses on realizing the product requirements". SDLC (systems development life cycle) is used during the
development of an IT project, it describes the different stages involved in the project from the drawing board, through the completion of the project.
History of System Development Life Cycle

The systems life cycle (SLC) is a methodology used to describe the process for building information systems, intended to develop information systems in a very deliberate, structured and methodical way, reiterating each stage of the life cycle. The systems development life cycle, according to Elliott & Strachan & Radford (2004), "originated in the 1960's,to develop large scale functional business systems in an age of large scale business conglomerates. Information systems activities revolved around heavy data processing and number crunching routines". Several systems development frameworks have been partly based on SDLC, such as the structured systems analysis and design method (SSADM) produced for the UK government Office of Government Commerce in the 1980s. Ever since, according to Elliott (2004), "the traditional life cycle approaches to systems development have been increasingly replaced with alternative approaches and frameworks, which attempted to overcome some of the inherent deficiencies of the traditional SDLC".
Systems Development Phases

The System Development Life Cycle framework provides a sequence of activities for system designers and developers to follow. It consists of a set of steps or phases in which each phase of the SDLC uses the results of the previous one. A Systems Development Life Cycle (SDLC) adheres to important phases that are essential for developers, such as planning, analysis, design, and implementation, and are explained in the section below. A number of system development life cycle (SDLC) models have been created: waterfall, fountain, spiral, build and fix, rapid prototyping, incremental, and synchronize and stabilize. The oldest of these, and the best known, is the waterfall model: a sequence of stages in which the output of each stage becomes the input for the next. These stages can be characterized and divided up in different ways, including the following:
Preliminary analysis: The objective of phase1 is to conduct a preliminary analysis, propose alternative solutions, describe costs and benefits and submit a preliminary plan with recommendations. Conduct the preliminary analysis: in this step, you need to find out the organization's objectives and the nature and scope of the
problem under study. Even if a problem refers only to a small segment of the organization itself then you need find out what the objectives of the organization itself are. Then you need to see how the problem being studied fits in with them. Propose alternative solutions: In digging into the organization's objectives and specific problems, you may have already covered some solutions. Alternate proposals may come from interviewing employees, clients , suppliers, and/or consultants. You can also study what competitors are doing. With this data, you will have three choices: leave the system as is, improve it, or develop a new system. Describe the costs and benefits.
Systems analysis, requirements definition: Defines project goals into defined functions and operation of the intended application. Analyzes enduser information needs. Systems design: Describes desired features and operations in detail, including screen layouts, business rules, process diagrams, pseudocode and other documentation. Development: The real code is written here. Integration and testing: Brings all the pieces together into a special testing environment, then checks for errors, bugs and interoperability. Acceptance, installation, deployment: The final stage of initial development, where the software is put into production and runs actual business. Maintenance: What happens during the rest of the software's life: changes, correction, additions, moves to a different computing platform and more. This is often the longest of the stages.
In the following example these stage of the systems development life cycle are divided in ten steps from definition to creation and modification of IT work products:
The tenth phase occurs when the system is disposed of and the task performed is either eliminated or transferred to other systems. The tasks and work products for each phase are described in subsequent chapters. Not every project will require that the phases be sequentially executed. However, the phases are interdependent. Depending upon the size and complexity of the project, phases may be combined or may overlap.
Software Development Life Cycle

Software development life cycle (SDLC) is a structure imposed on the development of a software product. Similar terms include software life cycle and software process. It is often considered a subset of systems development life cycle. There are several models for such processes, each describing approaches to a variety of tasks or activities that take place during the process. Some people consider a life-cycle model a more general term and a software development process a more specific term. For example, there are many specific software development processes that 'fit' the spiral life-cycle model. ISO/IEC 12207 is an international standard for software life-cycle processes. It aims to be the standard that defines all the tasks required for developing and maintaining software. Software Development Life Cycle consists of the following parts:
Planning
An important task in creating a software program is extracting the requirements or requirements analysis. Customers typically have an abstract idea of what they want as an end result, but not what software should do. Skilled and experienced software engineers recognize incomplete, ambiguous, or even contradictory requirements at this point. Frequently demonstrating live code may help reduce the risk that the requirements are incorrect. Once the general requirements are gathered from the client, an analysis of the scope of the development should be determined and clearly stated. This is often called a scope document. Certain functionality may be out of scope of the project as a function of cost or as a result of unclear requirements at the start of development. If the development is done externally, this document can be considered a legal document so that if there are ever disputes, any ambiguity of what was promised to the client can be clarified.
Implementation, testing and documenting

Implementation is the part of the process where software engineers actually program the code for the project. Software testing is an integral and important phase of the software development process. This part of the process ensures that defects are recognized as soon as possible. The code is tested at various levels in software testing. Unit, system and user-acceptance testing are often performed. This is a grey area as many different opinions exist as to what the stages of testing are and how much, if any iteration occurs. Iteration is not generally part of the waterfall model, but
usually some occur at this stage. In the testing the whole system is test one by one Following are the types of testing:

Defect testing the failed scenarios, including defect tracking Path testing Data set testing Unit testing System testing Integration testing Black-box testing White-box testing Regression testing Automation testing User acceptance testing Software performance testing
Documenting the internal design of software for the purpose of future maintenance and enhancement is done throughout development. This may also include the writing of an API, be it external or internal. The software engineering process chosen by the developing team will determine how much internal documentation (if any) is necessary. Plan-driven models (e.g., Waterfall) generally produce more documentation than Agile models.
Deployment and Maintenance

Deployment starts after the code is appropriately tested, approved for release, and sold or otherwise distributed into a production environment. This may involve installation, customization (such as by setting parameters to the customer's values), testing, and possibly an extended period of evaluation. Software training and support is important, as software is only effective if it is used correctly. Maintaining and enhancing software to cope with newly discovered faults or requirements can take substantial time and effort, as missed requirements may force redesign of the software.
Baselines in the SDLC

Baselines are an important part of the systems development life cycle (SDLC). These baselines are established after four of the five phases of the SDLC and are critical to the iterative nature of the model . Each baseline is considered as a milestone in the SDLC. functional baseline: established after the conceptual design phase. allocated baseline: established after the preliminary design phase. product baseline: established after the detail design and development phase. updated product baseline: established after the production construction phase.

Complementary to SDLC
Complementary software development methods to systems development life cycle (SDLC) are: Software prototyping Joint applications development (JAD) Rapid application development (RAD) Extreme programming (XP); extension of earlier work in Prototyping and RAD. Open-source development End-user development Object-oriented programming

Strengths and weaknesses of SDLC

Few people in the modern computing world would use a strict waterfall model for their systems development life cycle (SDLC) as many modern methodologies have superseded this thinking. Some will argue that the SDLC no longer applies to models like Agile computing, but it is still a term widely in use in technology circles. The SDLC practice has advantages in traditional models of software development, that lends itself more to a structured environment. The disadvantages to using the SDLC methodology is when there is need for iterative development or (i.e. web development or e-commerce) where stakeholders need to review on a regular basis the software being designed. Instead of viewing SDLC from a strength or weakness perspective, it is far more important to take the best practices from the SDLC model and apply it to whatever may be most appropriate for the software being designed.
Strengths
Control. Monitor large projects. Detailed steps. Evaluate targets. costs and completion
Weaknesses
Increased development time. Increased development cost. Systems must be defined up front. Rigidity. Hard to overruns. estimate costs, project
Documentation. Well defined user input. Ease of maintenance. Development and design standards. Tolerates changes in MIS staffing.
User input is sometimes limited.
A table Showing Strength and Weaknesses of SDLC
An alternative to the SDLC is rapid application development, which combines prototyping, joint application development and implementation of CASE tools. The advantages of RAD are speed, reduced development cost, and active user involvement in the development process.
Software Development Models:

Several models exist to streamline the development process. Each one has its pros and cons, and it's up to the development team to adopt the most appropriate one for the project. Sometimes a combination of the models may be more suitable.
Waterfall Model
The waterfall model is a sequential design process, often used in software development processes, in which progress is seen as flowing steadily downwards (like a waterfall) through the phases of Conception, Initiation, Analysis, Design, Construction, Testing, Production/Implementation and Maintenance. The waterfall model shows a process, where developers are to follow these phases in order: 1. 2. 3. 4. 5. 6. Requirements specification (Requirements analysis) Software design Implementation and Integration Testing (or Validation) Deployment (or Installation) Maintenance
A Block diagram of Waterfall model
In a strict Waterfall model, after each phase is finished, it proceeds to the next one. Reviews may occur before moving to the next phase which allows for the possibility of changes (which may involve a formal change control process). Reviews may also be employed to ensure that the phase is indeed complete; the phase completion criteria are often referred to as a "gate" that the project must pass through to move to the next phase. Waterfall discourages revisiting and revising any prior phase once it's complete. This "inflexibility" in a pure Waterfall model has been a source of criticism by supporters of other more "flexible" models. The waterfall development model originates in the manufacturing and construction industries: highly structured physical environments in which afterthe-fact changes are prohibitively costly, if not impossible. Since no formal software development methodologies existed at the time, this hardware-oriented model was simply adapted for software development. The first known presentation describing use of similar phases in software engineering was held by Herbert D. Benington at Symposium on advanced programming methods for digital computers on 29 June 1956. This presentation was about the development of software for SAGE. In 1983 the paper was republished with a foreword by Benington pointing out that the process was not in fact performed in strict top-down, but depended on a prototype. The first formal description of the waterfall model is often cited as a 1970 article by Winston W. Royce, though Royce did not use the term "waterfall" in this article. Royce presented this model as an example of a flawed, non-working model. This, in fact, is how the term is generally used in writing about software developmentto describe a critical view of a commonly used software practice. Time spent early in the software production cycle can lead to greater economy at later stages. McConnell shows that a bug found in the early stages (such as requirements specification or design) is cheaper in money, effort, and time, to fix than the same bug found later on in the process. To take an extreme example, if a program design turns out to be impossible to implement, it is easier to fix the design at the design stage than to realize months later, when program components are being integrated, that all the work done so far has to be scrapped because of a broken design. This is the central idea behind Big Design Up Front and the waterfall model: time spent early on making sure requirements and design are correct saves you much time and effort later. Thus, the thinking of those who follow the waterfall process goes, make sure each phase is 100% complete and absolutely correct before you proceed to the next phase. Program requirements should be set in stone before design begins (otherwise work put into a design based on incorrect requirements is wasted). The program's design should be perfect before people begin to implement the design (otherwise they implement the wrong design and their work is wasted), etc. A further argument for the waterfall model is that it places emphasis on documentation (such as requirements documents and design documents) as well as source code. In less thoroughly designed and documented methodologies,
knowledge is lost if team members leave before the project is completed and it may be difficult for a project to recover from the loss. If a fully working design document is present (as is the intent of Big Design Up Front and the waterfall model) new team members or even entirely new teams should be able to familiarize themselves by reading the documents. Some waterfall proponents prefer the waterfall model for its simple approach and argue that it is more disciplined. The waterfall model provides a structured approach; the model itself progresses linearly through discrete, easily understandable and explainable phases and thus is easy to understand; it also provides easily identifiable milestones in the development process. It is perhaps for this reason that the waterfall model is used as a beginning example of a development model in many software engineering texts and courses. It is argued that the waterfall model and Big Design up Front in general can be suited to software projects that are stable (especially those projects with unchanging requirements, such as with shrink wrap software) and where it is possible and likely that designers will be able to fully predict problem areas of the system and produce a correct design before implementation is started. The waterfall model also requires that implementers follow the well-made, complete design accurately, ensuring that the integration of the system proceeds smoothly.
Spiral Model
The key characteristic of a Spiral model is risk management at regular stages in the development cycle. In 1988, Barry Boehm published a formal software system development "spiral model," which combines some key aspect of the waterfall model and rapid prototyping methodologies, but provided emphasis in a key area many felt had been neglected by other methodologies: deliberate iterative risk analysis, particularly suited to large-scale complex systems. The Spiral is visualized as a process passing through some number of iterations, with the four quadrant diagram representative of the following activities: 1. Formulate plans to: identify software targets, selected to implement the program, clarify the project development restrictions; 2. Risk analysis: an analytical assessment of selected programs, to consider how to identify and eliminate risk; 3. The implementation of the project: the implementation of software development and verification;
Risk-driven spiral model, emphasizing the conditions of options and constraints in order to support software reuse, software quality can help as a special goal of integration into the product development. However, the spiral model has some restrictive conditions, as follows: The spiral model emphasizes risk analysis, and thus requires customers to accept this analysis and act on it. This requires both trust in the developer as well as the willingness to spend more to fix the issues, which is the reason why this model is often used for large-scale internal software development. If the implementation of risk analysis will greatly affect the profits of the project, the spiral model should not be used. Software developers have to actively look for possible risks, and analyze it accurately for the spiral model to work. The first stage is to formulate a plan to achieve the objectives with these constraints, and then strive to find and remove all potential risks through careful analysis and, if necessary, by constructing a prototype. If some risks cant be ruled out, the customer has to decide whether to terminate the project or to ignore the risks and continue anyway. Finally, the results are evaluated and the design of the next phase begins. The spiral model combines the idea of iterative development (prototyping) with the systematic, controlled aspects of the waterfall model. It allows for incremental releases of the product, or incremental refinement through each time around the spiral. The spiral model also explicitly includes risk management within software development. Identifying major risks, both technical and managerial, and determining how to lessen the risk helps keep the software development process under control. The spiral model is based on continuous refinement of key products for requirements definition and analysis, system and software design, and implementation (the code). At each iteration around the cycle, the products are extensions of an earlier product. This model uses many of the same phases as the waterfall model, in essentially the same order, separated by planning, risk assessment, and the building of prototypes and simulations. Documents are produced when they are required, and the content reflects the information necessary at that point in the process. All documents will not be created at the beginning of the process, nor all at the end (hopefully). Like the product they define, the documents are works in progress. The idea is to have a continuous stream of products produced and available for user review. The spiral lifecycle model allows for elements of the product to be added in when they become available or known. This assures that there is no conflict with previous requirements and design. This method is consistent with approaches that have multiple software builds and releases and allows for making an orderly transition to a maintenance activity. Another positive aspect is that the spiral model forces early user involvement in the system development effort. For projects with heavy user interfacing, such as user application programs or instrument interface applications, such involvement is helpful.
Starting at the centre, each turn around the spiral goes through several task regions: Determine the objectives, alternatives, and constraints on the new iteration. 2. Evaluate alternatives and identify and resolve risk issues. 3. Develop and verify the product for this iteration. 4. Plan the next iteration.
1.
A Diagram Showing Spiral Model of Software Development Note that the requirements activity takes place in multiple sections and in multiple iterations, just as planning and risk analysis occur in multiple places. Final design, implementation, integration, and test occur in iteration 4. The spiral can be repeated multiple times for multiple builds. Using this method of development, some functionality can be delivered to the user faster than the waterfall method. The spiral method also helps manage risk and uncertainty by allowing multiple decision points and by explicitly admitting that all of anything cannot be known before the subsequent activity starts.
Iterative and Incremental Development

Iterative and Incremental development is at the heart of a cyclic software development process developed in response to the weaknesses of the waterfall model. It starts with an initial planning and ends with deployment with the cyclic interactions in between. Iterative and incremental development are essential parts of the Rational Unified Process, Extreme Programming and generally the various agile software development frameworks. It follows a similar process to the plan-do-check-act cycle of business process improvement. Incremental development slices the system functionality into increments (portions). In each increment, a slice of functionality is delivered through crossdiscipline work, from the requirements to the deployment. The unified process groups increments/iterations into phases: inception, elaboration, construction, and transition. Inception identifies project scope, requirements (functional and nonfunctional) and risks at a high level but in enough detail that work can be estimated. Elaboration delivers a working architecture that mitigates the top risks and fulfils the non-functional requirements. Construction incrementally fills-in the architecture with productionready code produced from analysis, design, implementation, and testing of the functional requirements. Transition delivers the system into the production operating environment.
Each of the phases may be divided into 1 or more iterations, which are usually time-boxed rather than feature-boxed. Architects and analysts work one iteration ahead of developers and testers to keep their work-product backlog full.
A Diagram Showing Iterative and Incremental Development
V Model
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 (coarsestgrain abstraction uppermost), respectively.
An Abstract Diagram of V Model
Verification Phases
Requirements Analysis
In the Requirements analysis phase, the first step in the verification process, the requirements of the proposed system are collected by analyzing the needs of the user(s). This phase is concerned with establishing what the ideal system has to perform. However it does not determine how the software will be designed or built. Usually, the users are interviewed and a document called the user requirements document is generated. The user requirements document will typically describe the systems functional, interface, performance, data, security, etc requirements as expected by the user. It is used by business analysts to communicate their understanding of the system to the users. The users carefully review this document as this
document would serve as the guideline for the system designers in the system design phase. The user acceptance tests are designed in this phase. There are different methods for gathering requirements of both soft and hard methodologies including; interviews, questionnaires, document analysis, observation, throw-away prototypes, use cases and status and dynamic views with users.
System Design
Systems design is the phase where system engineers analyze and understand the business of the proposed system by studying the user requirements document. They figure out possibilities and techniques by which the user requirements can be implemented. If any of the requirements are not feasible, the user is informed of the issue. A resolution is found and the user requirement document is edited accordingly. The software specification document which serves as a blueprint for the development phase is generated. This document contains the general system organization, menu structures, data structures etc. It may also hold example business scenarios, sample windows, reports for the better understanding. Other technical documentation like entity diagrams, data dictionary will also be produced in this phase. The documents for system testing are prepared in this phase.
Architecture Design
The phase of the design of computer architecture and software architecture can also be referred to as high-level design. The baseline in selecting the architecture is that it should realize all which typically consists of the list of modules, brief functionality of each module, their interface relationships, dependencies, database tables, architecture diagrams, technology details etc. The integration testing design is carried out in the particular phase.
Module Design
The module design phase can also be referred to as low-level design. The designed system is broken up into smaller units or modules and each of them is explained so that the programmer can start coding directly. The low level design document or program specifications will contain a detailed functional logic of the module, in pseudocode:
Database tables, with all elements, including their All interface details with complete API references All dependency issues Error message listings Complete input and outputs for a module.
type and size
The unit test design is developed in this stage.
A Diagram Showing V Model of Software Development in Detail
Validation Phases
Unit Testing
In computer programming, unit testing is a method by which individual units of source code are tested to determine if they are fit for use. A unit is the smallest testable part of an application. In procedural programming a unit may be an individual function or procedure. Unit tests are created by programmers or occasionally by white box testers. The purpose is to verify the internal logic code by testing every possible branch within the function, also known as test coverage. Static analysis tools are used to facilitate in this process, where variations of input data are passed to the function to test every possible case of execution.
Integration Testing
In integration testing the separate modules will be tested together to expose faults in the interfaces and in the interaction between integrated components. Testing is usually black box as the code is not directly checked for errors.
System Testing
System testing will compare the system specifications against the actual system. After the integration test is completed, the next test level is the system test. System testing checks if the integrated product meets the specified requirements. Why is this still necessary after the component and integration tests? The reasons for this are as follows: Reasons for system test: 1. In the lower test levels, the testing was done against technical specifications, i.e., from the technical perspective of the software producer. The system test, though, looks at the system from the perspective of the customer and the future user. The testers validate whether the requirements are completely and appropriately met. o Example: The customer (who has ordered and paid for the system) and the user (who uses the system) can be different groups of people or organizations with their own specific interests and requirements of the system. 2. Many functions and system characteristics result from the interaction of all system components; consequently, they are only visible on the level of the entire system and can only be observed and tested there.
User Acceptance Testing

Acceptance testing is the phase of testing used to determine whether a system satisfies the requirements specified in the requirements analysis phase. The acceptance test design is derived from the requirements document. The acceptance test phase is the phase used by the customer to determine whether to accept the system or not. Acceptance testing helps

to determine whether a system satisfies its acceptance criteria or not. to enable the customer to determine whether to accept the system or not. to test the software in the "real world" by the intended audience. Purpose of acceptance testing:
to verify the system or changes according to the original needs. Procedures: 1. Define the acceptance criteria: o Functionality requirements. o Performance requirements. o Interface quality requirements. o Overall software quality requirements.
2. Develop an acceptance plan: o Project description. o User responsibilities. o Acceptance description.
Release Testing
Release testing is a phase that determines if the software is suitable for the organisation of the end-user. How is compatibility with other systems ensured? Is the performance of the software optimized?
Dual Vee Model

The Dual Vee Model builds on the V-Model to cleanly depict the complexity associated with designing and developing systems. In systems engineering it defines a uniform procedure for product or project development. The model depicts concurrent development of a systems architecture as one Vee with each entity of that architecture as another Vee that intersects the architecture Vee. This clearly shows interactions and sequences in developing a complex system and a system of systems. The Dual Vee Model builds on the Vee Model to manage a system of systems. An architecture Vee manages the system and entity Vees branch off the architecture Vee to manage sub-systems. For example, GPS includes a constellation of satellites, a ground control network, and millions of users worldwide. Each satellite, ground control center, and GPS receiver is a complex system that could be managed by a separate Entity Vee. Development of a satellite can affect the design, manufacturing, or cost of receivers. Similarly, development of a receiver can affect design, manufacturing, or cost of satellites. So everything must be integrated into a system of systems that are developed within a larger Architecture Vee.
Rapid Application Development

Rapid application development (RAD) is a software development methodology that uses minimal planning in favour 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. According to Whitten (2004), it is a merger of various structured techniques, especially data-driven Information Engineering, with prototyping techniques to accelerate software systems development. In rapid application development, structured techniques and prototyping are especially used to define users' requirements and to design the final system. The development process starts with the development of preliminary data models and business process models using structured techniques. In the next stage, requirements are verified using prototyping, eventually to refine the data and process models. These stages are repeated iteratively; further development results in "a combined business requirements and technical design statement to be used for constructing new systems". RAD approaches may entail compromises in functionality and performance in exchange for enabling faster development and facilitating application maintenance. When organizations adopt rapid development methodologies, care must be taken to avoid role and responsibility confusion and communication breakdown within a development team, and between team and client. In addition, especially in cases where the client is absent or not able to participate with authority in the development process, the system analyst should be endowed with this authority on behalf of the client to ensure appropriate prioritisation of non-functional requirements. Four phases of RAD:
A Diagram Showing Rapid Application Development Model

1. Requirements planning phase combines elements of the system planning and systems analysis phases of the System Development Life Cycle (SDLC). Users, managers, and IT staff members discuss and agree on business needs, project scope, constraints, and system requirements. It ends when the team agrees on the key issues and obtains management authorization to continue. 2. User design phase during this phase, users interact with systems analysts and develop models and prototypes that represent all system processes, inputs, and outputs. The RAD groups or subgroups typically use a combination of Joint Application Development (JAD) techniques and CASE tools to translate user needs into working models. User Design is a continuous interactive process that allows users to understand, modify, and eventually approve a working model of the system that meets their needs. 3. Construction phase focuses on program and application development task similar to the SDLC. In RAD, however, users continue to participate and can still suggest changes or improvements as actual screens or reports are developed. Its tasks are programming and application development, coding, unit-integration and system testing. 4. Cutover phase resembles the final tasks in the SDLC implementation phase, including data conversion, testing, changeover to the new system, and user training. Compared with traditional methods, the entire process is compressed. As a result, the new system is built, delivered, and placed in operation much sooner. Its tasks are data conversion, fullscale testing, system changeover, user training.
Extreme Programming
Extreme Programming (XP) is a software development methodology which is intended to improve software quality and responsiveness to changing customer requirements. As a type of agile software development, it advocates frequent "releases" in short development cycles (timeboxing), which is intended to improve productivity and introduce checkpoints where new customer requirements can be adopted. Other elements of Extreme Programming include: programming in pairs or doing extensive code review, unit testing of all code, avoiding programming of features until they are actually needed, a flat management structure, simplicity and clarity in code, expecting changes in the customer's requirements as time passes and the problem is better understood, and frequent communication with the customer and among programmers. The methodology takes its name from the idea that the beneficial elements of traditional software engineering practices are taken to "extreme" levels, on the theory that if a little is good, more is better. Critics have noted several potential drawbacks, including problems with unstable requirements, no documented compromises of user conflicts, and a lack of an overall design specification or document.
A Diagram Showing Planning/ Feedback Loop in Extreme Programming Model
Dynamic Systems Development Method

Dynamic systems development method (DSDM) is an agile project delivery framework, primarily used as a software development method. First released in 1994, DSDM originally sought to provide some discipline to the rapid application development (RAD) method. In 2007 DSDM became a generic approach to project management and solution delivery. DSDM is an iterative and incremental approach that embraces principles of Agile development, including continuous user/customer involvement. DSDM fixes cost, quality and time at the outset and uses the MoSCoW prioritisation of scope into musts, shoulds, coulds and won't haves to adjust the project deliverable to meet the stated time constraint. DSDM is one of a number of agile methods for developing software and non-IT solutions, and it forms a part of the Agile Alliance. The most recent version of DSDM, launched in 2007, is called DSDM Atern. The name Atern is a shortening of Arctic Tern - a collaborative bird that can travel vast distances and epitomises many facets of the method which are natural ways of working e.g. prioritisation and collaboration. The previous version of DSDM (released in May 2003) which is still widely used and is still valid is DSDM 4.2 which is a slightly extended version of DSDM version 4. The extended version contains guidance on how to use DSDM with Extreme Programming.
Phases:
The DSDM framework consists of three sequential phases, namely the pre-project, project life-cycle and post-project phases. The project phase of DSDM is the most elaborate of the three phases. The project life-cycle phase consists of 5 stages that form an iterative step-by-step approach in developing an IS. The three phases and corresponding stages are explained extensively in the subsequent sections. For each stage/phase, the most important activities are addressed and the deliverables are mentioned. Phase 1 - The Pre-project In the pre-project phase candidate projects are identified, project funding is realised and project commitment is ensured. Handling these issues at an early stage avoids problems at later stages of the project. Phase 2 - The Project life-cycle The process overview in the figure below shows the project life-cycle of this phase of DSDM. It depicts the 5 stages a project will have to go through to create an implemented system. The first two stages, the Feasibility Study and Business Study are sequential phases that complement to each other. After these phases have been concluded, the system is developed iteratively and incrementally in the Functional Model Iteration, Design & Build Iteration and Implementation stages. The
iterative and incremental nature of DSDM will be addressed further in a later section. Phase 3 - Post-project The post-project phase ensures the system operates effectively and efficiently. This is realised by maintenance, enhancements and fixes according to DSDM principles. The maintenance can be viewed as continuing development based on the iterative and incremental nature of DSDM. Instead of finishing the project in one cycle usually the project can return to the previous phases or stages so that the previous step and the deliverable products can be refined.
A Diagram Showing DSDM of Software Development
Agile Development
Agile 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 timeboxed 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.There are many variations of agile processes:
In Extreme Programming (XP), the phases are carried out in extremely small (or "continuous") steps compared to the older, "batch" processes. The (intentionally incomplete) first pass through the steps might take a day or a week, rather than the months or years of each complete step in the Waterfall model. First, one writes automated tests, to provide concrete goals for development. Next is coding (by a pair of programmers), which is complete when all the tests pass, and the programmers can't think of any more tests that are needed. Design and architecture emerge out of refactoring, and come after coding. The same people who do the coding do design. (Only the last feature merging design and code is common to all the other agile processes.) The incomplete but functional system is deployed or demonstrated for (some subset of) the users (at least one of which is on the development team). At this point, the practitioners start again on writing tests for the next most important part of the system. Scrum Dynamic systems development method
A Diagram Showing Agile Software Development Model
Management and Control in SDLC
SDLC Control management The SDLC phases serve as a programmatic guide to project activity and provide a flexible but consistent way to conduct projects to a depth matching the scope of the project. Each of the SDLC phase objectives are described in this section with key deliverables, a description of recommended tasks, and a summary of related control objectives for effective management. It is critical for the project manager to establish and monitor control objectives during each SDLC phase while executing projects. Control objectives help to provide a clear statement of the desired result or purpose and should be used throughout the entire SDLC process. Control objectives can be grouped into major categories (domains), and relate to the SDLC phases as shown in the figure. To manage and control any SDLC initiative, each project will be required to establish some degree of a Work Breakdown Structure (WBS) to capture and schedule the work necessary to complete the project. The WBS and all programmatic material should be kept in the project description section of the project notebook. The WBS format is mostly left to the project manager to establish in a way that best describes the project work. There are some key areas that must be defined in the WBS as part of the SDLC policy. The following diagram describes three key areas that will be addressed in the WBS in a manner established by the project manager.
Work Breakdown Structured Organization
The upper section of the work breakdown structure (WBS) should identify the major phases and milestones of the project in a summary fashion. In addition, the upper section should provide an overview of the full scope and timeline of the project and will be part of the initial project description effort leading to project approval. The middle section of the WBS is based on the seven systems development life cycle (SDLC) phases as a guide for WBS task development. The WBS elements should consist of milestones and tasks as opposed to activities and have a definitive period (usually two weeks or more). Each task must have a measurable output (e.x. - document, decision, or analysis). A WBS task may rely on one or more activities (e.g. software engineering, systems engineering) and may require close coordination with other tasks, either internal or external to the project. Any part of the project needing support from contractors should have a statement of work (SOW) written to include the appropriate tasks from the SDLC phases. The development of a SOW does not occur during a specific phase of SDLC but is developed to include the work from the SDLC process that may be conducted by external resources such as contractors and struct.
Matrix Management
Matrix management is a type of organizational management in which people with similar skills are pooled for work assignments. For example, all engineers may be in one engineering department and report to an engineering manager, but these same engineers may be assigned to different projects and report to a different engineering manager or a project manager while working on that project. Therefore, each engineer may have to work under several managers to get their job done.
Some organizations fall somewhere between the fully functional and pure matrix. These organizations are defined in A Guide to the Project Management Body of Knowledge (PMBOK) 4th Edition as composite. For example, even a fundamentally functional or matrix organization may create a special project team to handle a critical project.
A Diagram Representing a Matrix Organization Management Whereas project-centered organizations (like those in engineering, construction or the aerospace industries) have structures built around project teams as their functional units, matrix organizations follow the traditional structures, with some adjustments to their hierarchy to support project units. The advantages of a matrix include: Individuals can be chosen according to the needs of the project. The use of a project team that is dynamic and able to view problems in a different way as specialists have been brought together in a new environment. Project managers are directly responsible for completing the project within a specific deadline and budget.

Whilst the disadvantages include: A conflict of loyalty between line managers and project managers over the allocation of resources. Projects can be difficult to monitor if teams have a lot of independence. Costs can be increased if more managers (i.e. project managers) are created through the use of project teams.
Programming Style & Coding Convention:

Programming style is a set of rules or guidelines used when writing the source code for a computer program. It is often claimed that following a particular programming style will help programmers to read and understand source code conforming to the style, and help to avoid introducing errors. A classic work on the subject was The Elements of Programming Style, written in the 1970s, and illustrated with examples from the Fortran and PL/I languages prevalent at the time. The programming style used in a particular program may be derived from the coding conventions of a company or other computing organization, as well as the preferences of the author of the code. Programming styles are often designed for a specific programming language (or language family): style considered good in C source code may not be appropriate for BASIC source code, and so on. However, some rules are commonly applied to many languages.
Coding conventions are a set of guidelines for a specific programming language that recommend programming style, practices and methods for each aspect of a piece program written in this language. These conventions usually cover file organization, indentation, comments, declarations, statements, white space, naming conventions, programming practices, programming principles, programming rules of thumb, etc. Software programmers are highly recommended to follow these guidelines to help improve the readability of their source code and make software maintenance easier. Coding conventions are only applicable to the human maintainers and peer reviewers of a software project. Conventions may be formalized in a documented set of rules that an entire team or company follows, or may be as informal as the habitual coding practices of an individual. Coding conventions are not enforced by compilers. As a result, not following some or all of the rules has no impact on the executable programs created from the source code.
ISO 9000:
The ISO 9000 family of standards are related to quality management systems and designed to help organizations ensure that they meet the needs of customers and other stakeholders. The standards are published by ISO, the International Organization for Standardization, and available through National standards bodies while meeting statutory and regulatory requirements. ISO 9000 deals with the fundamentals of quality management systems, including the eight management principles on which the family of standards is based. ISO 9001 deals with the requirements that organizations wishing to meet the standard have to fulfil. Third party certification bodies provide independent confirmation that organizations meet the requirements of ISO 9001. Over a million organizations worldwide are independently certified, making ISO 9001 one of the most widely used management tools in the world today. ISO 9000 was first published in 1987. It was based on the BS 5750 series of standards from BSI that were proposed to ISO in 1979. However, its history can be traced back some twenty years before that, to the publication of the Department of Defense MIL-Q-9858 standard in 1959. MIL-Q-9858 was revised into the NATO AQAP series of standards in 1969, which in turn were revised into the BS 5179 series of guidance standards published in 1974, and finally revised into the BS 5750 series of requirements standards in 1979 before being submitted to ISO. BSI has been certifying organizations for their quality management systems since 1978. Its first certification (FM 00001) is still extant and held by Tarmac, a successor to the original company which held this certificate. Today BSI claims to certify organizations at nearly 70,000 sites globally. The development of the ISO 9000 series is shown in the diagram to the right.
Evolution of ISO 9000 standards:

1987 version ISO 9000:1987 had the same structure as the UK Standard BS 5750, with three 'models' for quality management systems, the selection of which was based on the scope of activities of the organization:
ISO 9001:1987 Model for quality assurance in design, development, production, installation, and servicing was for companies and organizations whose activities included the creation of new products. ISO 9002:1987 Model for quality assurance in production, installation, and servicing had basically the same material as ISO 9001 but without covering the creation of new products. ISO 9003:1987 Model for quality assurance in final inspection and test covered only the final inspection of finished product, with no concern for how the product was produced.
ISO 9000:1987 was also influenced by existing U.S. and other Defense Standards ("MIL SPECS"), and so was well-suited to manufacturing. The emphasis tended to be placed on conformance with procedures rather than the overall process of management, which was likely the actual intent. 1994 version ISO 9000:1994 emphasized quality assurance via preventive actions, instead of just checking final product, and continued to require evidence of compliance with documented procedures. As with the first edition, the down-side was that companies tended to implement its requirements by creating shelfloads of procedure manuals, and becoming burdened with an ISO bureaucracy. In some companies, adapting and improving processes could actually be impeded by the quality system. 2000 version ISO 9001:2000 combined the three standards9001, 9002, and 9003into one, called 9001. Design and development procedures were required only if a company does in fact engage in the creation of new products. The 2000 version sought to make a radical change in thinking by actually placing the concept of process management front and center ("Process management" was the monitoring and optimisation of a company's tasks and activities, instead of just inspection of the final product). The 2000 version also demanded involvement by upper executives in order to integrate quality into the business system and avoid delegation of quality functions to junior administrators. Another goal was to improve effectiveness via process performance metrics: numerical measurement of the effectiveness of tasks and activities. Expectations of continual process improvement and tracking customer satisfaction were made explicit. The ISO 9000 standard is continually being revised by standing technical committees and advisory groups, who receive feedback from those professionals who are implementing the standard. 2008 version ISO 9001:2008 basically renarrates ISO 9001:2000. The 2008 version only introduced clarifications to the existing requirements of ISO 9001:2000 and some changes intended to improve consistency with ISO 14001:2004. There were no new requirements. For example, in ISO 9001:2008, a quality management system being upgraded just needs to be checked to see if it is following the clarifications introduced in the amended version.
Advantages of ISO
It is widely acknowledged that proper quality management improves business, often having a positive effect on investment, market share, sales growth, sales margins, competitive advantage, and avoidance of litigation. The quality principles in ISO 9000:2000 are also sound, according to Wade and also to Barnes, who says that "ISO 9000 guidelines provide a comprehensive model for quality management systems that can make any company competitive." Implementing ISO often gives the following advantages: 1. 2. 3. 4. 5. 6. 7. 8. 9. Creates a more efficient, effective operation Increases customer satisfaction and retention Reduces audits Enhances marketing Improves employee motivation, awareness, and morale Promotes international trade Increases profit Reduces waste and increases productivity Common tool for standardization.
GNU Coding Standards:

The GNU Coding Standards are a set of rules and guidelines for writing programs that work consistently within the GNU system. The GNU Coding Standards were written by Richard Stallman and other GNU Project volunteers. The standards document is part of the GNU Project and is available from the GNU website. Though it focuses on writing free software for GNU in C, much of it can be applied more generally. In particular, the GNU Project encourages its contributors to always try to follow the standardswhether or not their programs are implemented in C. The C code formatting style is well-known within the free software community, but of course, anyone can choose to follow it.
The GNU Coding Standards specify exactly how to format most C programming language constructs. Here is a characteristic example:
int main (int argc, char *argv[]) { struct gizmo foo; fetch_gizmo (&foo, argv[1]); check: if (foo.type == MOOMIN) puts ("It's a moomin."); else if (foo.bar < GIZMO_SNUFKIN_THRESHOLD / 2 || (strcmp (foo.class_name, "snufkin") == 0) && foo.bar < GIZMO_SNUFKIN_THRESHOLD) puts ("It's a snufkin."); else { char *barney; /* Pointer to the first character after the last slash in the file name. */ /* Approximate size of the universe. */ int wilma; int fred; /* Max value of the `bar' field. */ do { frobnicate (&foo, GIZMO_SNUFKIN_THRESHOLD, &barney, &wilma, &fred); twiddle (&foo, barney, wilma + fred); } while (foo.bar >= GIZMO_SNUFKIN_THRESHOLD); store_size (wilma); goto check; } return 0; }
Code Formatting
The consistent treatment of blocks as statements (for the purpose of indentation) is a very distinctive feature of the GNU C code formatting style; as is the mandatory space before parentheses. All code formatted in the GNU style
has the property that each closing brace, bracket or parenthesis appears to the right of its corresponding opening delimiter, or in the same column.
Comments
The standards greatly emphasise the importance of English-language comments: Please write the comments in a GNU program in English, because English is the one language that nearly all programmers in all countries can read. If you do not write English well, please write comments in English as well as you can, then ask other people to help rewrite them. If you can't write comments in English, please find someone to work with you and translate your comments into English. Comments should consist of complete, capitalized sentences, each followed by two spaces (so that Emacs can tell where one sentence ends and the next begins). For long or complex preprocessor conditionals, every #else and #endif should have a comment explaining the condition for the code below (for #else) or above (for #endif).
Files
The standards require that all programs be able to operate when /usr and /etc are mounted read-only. Therefore, files that are modified for internal purposes (log files, lock files, temporary files, etc.) should not be stored in either /usr or /etc. An exception is made for programs whose job it is to update system configuration files in /etc. Another exception is made for storing files in a directory when the user has explicitly asked to modify a file in the same directory.
Portability
The GNU Coding Standards define the issue of portability in this way: portability in the UNIX world means 'between Unixes'; in a GNU program this kind of portability is desirable, but not vitally important. According to the standard, portability problems are very limited as GNU programs are designed to be compiled with one compiler, the GNU C Compiler, and only run on one system, which is the GNU system. There is one form of portability problem though, and that is the fact that the standard makes it clear that a program should run on different CPU types. The standard says that GNU doesn't and won't support 16-bit systems, but handling all the different 32- and 64-bit systems is absolutely necessary.
The Mythical Man-Month:

The Mythical Man-Month: Essays on Software Engineering is a book on software engineering and project management by Fred Brooks, whose central theme is that "adding manpower to a late software project makes it later". This idea is known as Brooks' law, and is presented along with the second-system effect and advocacy of prototyping. Brooks' observations are based on his experiences at IBM while managing the development of OS/360. He had added more programmers to a project falling behind schedule, a decision that he would later counter-intuitively conclude to have delayed the project even further. He also made the mistake of asserting that one project writing an Algol compiler would require six months, regardless of the number of workers involved (it required longer). The tendency for managers to repeat such errors in project development led Brooks to quip that his book is called "The Bible of Software Engineering", because "everybody quotes it, some people read it, and a few people go by it." The book is widely regarded as a classic on the human elements of software engineering. The work was first published in 1975 (ISBN 0-201-00650-2), reprinted with corrections in 1982, and republished in an anniversary edition with four extra chapters in 1995 (ISBN 0-201-83595-9), including a reprint of the essay "No Silver Bullet" with commentary by the author.
Ideas Presented:
The Mythical Man-Month
Brooks discusses several causes of scheduling failures. The most enduring is demonstrating Brooks's Law: Adding manpower to a late software project makes it later. Complex programming projects cannot be perfectly partitioned into discrete tasks that can be worked on without communication between the workers and without establishing a set of complex interrelationships between tasks and the workers performing them. Therefore, assigning more programmers to a project running behind schedule will make it even later. This is because the time required for the new programmers to learn about the project and the increased communication overhead will consume an ever increasing quantity of the calendar time available. When n people have to communicate among themselves, as n
increases, their output decreases and when it becomes negative the project gets later with every person added.

Group Intercommunication Formula: n(n 1) / 2 Example: 50 developers give 50 (50 1) / 2 = 1225 channels of communication.
The Second-System Effect

The Second-system effect proposes that, when an architect designs a second system, it is the most dangerous system he will ever design, because he will tend to incorporate all of the additions he originated but did not add (due to inherent time constraints) to the first system. Thus, when embarking upon a second system, an engineer should be mindful that he is susceptible to overengineering it.
The tendency towards irreducible no. of errors

The author makes the observation that in a suitably complex system there is a certain irreducible number of errors. Any attempt to fix observed errors tends to result in the introduction of other errors.
Progress Tracking
Brooks wrote "Question: How does a large software project get to be one year late? Answer: One day at a time!" Incremental slippages on many fronts eventually accumulate to produce a large overall delay. Continued attention to meeting small individual milestones is required at each level of management.
Conceptual Integrity
To make a user-friendly system, the system must have conceptual integrity, which can only be achieved by separating architecture from implementation. A single chief architect (or a small number of architects), acting on the user's behalf, decides what goes in the system and what stays out. The architect or team of architects should develop an idea of what the system should do and make sure this vision is understood by the rest of the team. A novel idea by someone may not be included if it does not fit seamlessly with the overall system design. In fact, to ensure a user-friendly system, a system may deliberately provide fewer features than it is capable of. The point is that if a system is too complicated to use, then many of its features will go unused because no one has the time to learn how to use them.
The Manual
The chief architect produces a manual of system specifications. It should describe the external specifications of the system in detail, i.e., everything that the user sees. The manual should be altered as feedback comes in from the implementation teams and the users.
The Pilot System

When designing a new kind of system, a team will design a throw-away system (whether it intends to or not). This system acts as a "pilot plant" that reveals techniques that will subsequently cause a complete redesign of the system. This second, smarter system should be the one delivered to the customer, since delivery of the pilot system would cause nothing but agony to the customer, and possibly ruin the system's reputation and maybe even the company.
Formal Documents
Every project manager should create a small core set of formal documents defining the project objectives, how they are to be achieved, who is going to achieve them, when they are going to be achieved, and how much they are going to cost. These documents may also reveal inconsistencies that are otherwise hard to see.
Project Estimation
When estimating project times, it should be remembered that programming products (which can be sold to paying customers) and programming systems are both three times as hard to write as in-house programs. It should be kept in mind how much of the work week will actually be spent on technical issues, as opposed to administrative or other non-technical tasks, such as meetings.
Communication
To avoid disaster, all the teams working on a project should remain in contact with each other in as many ways as possible e-mail, phone, meetings, memos etc. Instead of assuming something, the implementer should instead ask the architects to clarify their intent on a feature he is implementing, before proceeding with an assumption that might very well be completely incorrect. The architects are responsible for formulating a group picture of the project and communicating it to the others.
The Surgical Team

Much as a surgical team during surgery is led by one surgeon performing the most critical work himself while directing his team to assist with or overtake less critical parts, it seems reasonable to have a "good" programmer develop critical system components while the rest of a team provides what is needed at the right time. Additionally, Brooks muses that "good" programmers are generally five to ten times as productive as mediocre ones. See also Organization and Team Patterns.
Code Freeze and System Versioning

Software is invisible. Therefore, many things only become apparent once a certain amount of work has been done on a new system, allowing a user to experience it. This experience will yield insights, which will change a user's needs or the perception of the user's needs. The system should, therefore, be changed to fulfill the changed requirements of the user. This can only occur up to a certain point, otherwise the system may never be completed. At a certain date, no more changes should be allowed to the system and the code should be frozen. All requests for changes should be delayed until the next version of the system.
Specialized Tools
Instead of every programmer having his own special set of tools, each team should have a designated tool-maker who may create tools that are highly customized for the job that team is doing, e.g., a code generator tool that creates code based on a specification. In addition, system-wide tools should be built by a common tools team, overseen by the project manager.
Lowering Software Development Costs

There are two techniques for lowering software development costs that Brooks writes about: Implementers may be hired only after the architecture of the system has been completed (a step that may take several months, during which time prematurely-hired implementers may have nothing to do). Another technique Brooks mentions is not to develop software at all, but simply to buy it "off the shelf" when possible.
Biblical References
Abdel-Hamid, Tarek K., and Stuart E.Madnick. Impact of Schedule Estimation on Software Project Behavior. IEEE Software 3, 4 (July 1986), 70-75. Albrecht, Allan J., and John E. Gaffney, Jr. Software Function, Source Lines of Code, and Development Effort Prediction: A Software Science Validation. IEEE Trans. Software Eng. SE-9, 6 (Nov. 1983), 639-648.
Anderson, D. R., D. J. Sweeney, and T. A. Williams. An Introduction to Management Science, 4th Ed. St. Paul: West Publishing Company, 1985.
Behrens, Charles A. Measuring the Productivity of Computer S y s t e m s D e v e l o p m e n t Activities w i t h Function Points. IEEE Trans. Software Eng. SE-9, 6 (Nov. 1983), 648-652. Bernstein, L. Software Project Management Audits. J. Syst. and Software 2, 4 (Dec.1981), 281-287. Bersoff, Edward H. Elements of Software Configuration Management. IEEE Trans. Software Eng. SE-10, 1 (Jan. 1984), 79-87.
Boehm, Barry W. Software Engineering Economics. IEEE Trans. Software Eng. SE-10, 1 (Jan. 1984), 4-21. Chisum, Donald S. The P a t e n t a b i l i t y o f A l g o r i t h m s . U. of Pittsburgh Law Review 47, 4 (Sum- mer 1986), 959-1022.
Cooper, John D. Corporate Level Software Management. IEEE Trans. Software Eng. SE-4, 4 (July 1978), 319. Collofello, James S., and Jeffrey J. Buck. Software Quality Assurance for Maintenance. IEEE Software 4, 9 (Sept. 1987), 46-51.
Fagan, M. Design and Code Inspections to Reduce Errors i n P r o g r a m D e v e l o p m e n t . IBM S y s t e m s J. 15, 3 (1976), 182-211.
Brooks, Frederick P. The Mythical Man-Month: Essays on Software Engineering. ADDISON-WESLEY, ISBN 0-201-83595-9
Fairley, Richard E. A Guide to Preparing Software Project Management Plans. In Tutorial: Software Engineering Press, 1988, 257-264. Project Management, Richard H. Thayer, ed. Washington, D.C.: IEEE Computer Society
Howes, Norman R. Managing Software Development Projects for Maximum Productivity. IEEE Trans. Software Eng. SE-10, 1 (Jan. 1984), 27-35.
Kotler, P. Marketing Planning: Analysis, Planning, Implementation, and Control, 6th Ed. Englewood Cliffs, N.J.: Prentice-Hall, 1988. McGill, James P. The Software Engineering Shortage: A Third Choice. IEEE Trans. Software Eng. SE-10, 1 (Jan. 1984), 42-48.
***

Term Paper On Software Project Management

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Term Paper On Software Project Management

Uploaded by

Copyright:

Available Formats

Software is one of the core fields of Computer Science.

Project Management and Development Process of Software | Page No. 1

K. The Mythical Man-Month

Project Management and Development Process of Software | Page No. 2

Project Management and Development Process of Software | Page No. 3

Project Management and Development Process of Software | Page No. 5

A Block Diagram of Software Schematics

Project Management and Development Process of Software | Page No. 7

Quality and Reliability

Project Management and Development Process of Software | Page No. 9

Project Management and Development Process of Software | Page No. 10

Software Project Management:

Project Management and Development Process of Software | Page No. 11

Approaches of Project Management:

The Traditional Approach

Critical Chain Project Management

Project Management and Development Process of Software | Page No. 13

Event Chain Methodology

Project Management and Development Process of Software | Page No. 14

Agile Project Management

Project Management and Development Process of Software | Page No. 15

Traditional Approaches of Software Project Management

Initiation Planning or development Production or execution Monitoring and controlling Closing

A Block Diagram of Traditional Approaches of Software Project Management

Planning and Design

Project Management and Development Process of Software | Page No. 17

Project Management and Development Process of Software | Page No. 18

Monitoring and Controlling

A Block Diagram Showing Monitoring and Controlling Processes

Project Management and Development Process of Software | Page No. 19

A Block diagram Showing Monitoring and Controlling Cycle

Project Management and Development Process of Software | Page No. 20

Project Management and Development Process of Software | Page No. 21

Software Project Controlling System:

Project Manager and his/her Role:

Project Management and Development Process of Software | Page No. 23

Software Project Management Triangle

Project Management and Development Process of Software | Page No. 24

System Development Life Cycle

Software Development Process

History of System Development Life Cycle

Systems Development Phases

Project Management and Development Process of Software | Page No. 27

Project Management and Development Process of Software | Page No. 28

Project Management and Development Process of Software | Page No. 29

Software Development Life Cycle

Implementation, testing and documenting

Deployment and Maintenance

Project Management and Development Process of Software | Page No. 31

Baselines in the SDLC

Strengths and weaknesses of SDLC

User input is sometimes limited.

A table Showing Strength and Weaknesses of SDLC

Project Management and Development Process of Software | Page No. 33

Software Development Models:

A Block diagram of Waterfall model

Project Management and Development Process of Software | Page No. 34

Project Management and Development Process of Software | Page No. 36

Project Management and Development Process of Software | Page No. 38

Iterative and Incremental Development

A Diagram Showing Iterative and Incremental Development

Project Management and Development Process of Software | Page No. 39

An Abstract Diagram of V Model