Japan in Turmoil

Lots of people are wondering why such disasters are happening to Japan within a short period of time. Imagine a magnitude 8.9 earthquake followed by 30 feet tsunami and volcanic eruption occurring within 7 days. Imagine how those survivors felt when they saw their loved ones being washed away by the huge wave of water coupled with wooden debris and sometimes cars or houses. It was very horrifying how thousand of lives easily got lost in hours without any warning. They could be doing their laundry, playing with kids, attending school, or waiting for their flight. In these darkest hours of Japan how are they going to recover? How will the world sympathize with Japan?

At the very moment when the tsunami hit Japanese coasts, some people are complaining about their daily jobs and problems. Some people are thinking that they are very bored and wishing they could die. Some people aren’t very thankful of what they have. Others are even trying to compete with others and tend not to share what they have. Several are fighting over some properties. What they didn’t know is that while they are complaining about what was happening to them and think that God is punishing them, someone out there is crying out for help. Someone out there is very terrified to lose someone he loved. Someone out there is running for his life.

At the very least, almost all people are too greedy to think for others’ welfare. They do not care about what happened to others as long as they already got what they wanted. They do not care how many people died in every calamity as long as they are safe and their businesses are. It’s very sad but this is the ugly truth. Admit it or not you might feel like you’re one of those people being talked about. Human as we are, this is just normal.

When you look into your own problems, it is true that you might feel sorry for yourself, not contented, or depressed. But try to look around you and you will notice that all people have problems whether financially, emotionally, physically, or psychologically. You are not the only one living in this world so be sensitive enough because others might just need your help.

10,000,000 people in Japan are said to be starving according to N.Y. times. You could offer a piece of bread so that one of those people will be relieved of hunger. Others can also offer and thus if more others can offer, all those 10,000,000 can be relieved of hunger. Earthquake can be very devastating itself. Tsunami is a lot worse leaving few signs of life after devouring every kilometer of the coast. Volcanic eruption is the worst leaving only magma in land and ashes in the air.

People are dying everywhere. Please be human enough to sympathize with them and offer them help if you can. Believe it or not, it is by helping others that you can attain such fidelity or bliss that you’ve never felt before. Japan is in turmoil. Let’s try to help each other and offer our prayers.

Characteristics that an analyst must have in order to properly evaluate a DFD

Before going through the characteristics that an analyst must have in order to properly evaluate a DFD, let us first define what Data Flow Diagram is and how to create it. After showing the basics of a DFD, I will enumerate and briefly explain the characteristics as based on the previous assignments.

What is DFD?

A data-flow diagram (DFD) is a graphical representation of the "flow" of data through an information system. DFDs can also be used for the visualization of data processing (structured design).

On a DFD, data items flow from an external data source or an internal data store to an internal data store or an external data sink, via an internal process.
A DFD provides no information about the timing or ordering of processes, or about whether processes will operate in sequence or in parallel. It is therefore quite different from a flowchart, which shows the flow of control through an algorithm, allowing a reader to determine what operations will be performed, in what order, and under what circumstances, but not what kinds of data will be input to and output from the system, nor where the data will come from and go to, nor where the data will be stored (all of which are shown on a DFD).

Data Flow Diagramming is a means of representing a system at any level of detail with a graphic network of symbols showing data flows, data stores, data processes, and data sources/destinations.

Purpose/Objective:

The purpose of data flow diagrams is to provide a semantic bridge between users and systems developers. The diagrams are:
• graphical, eliminating thousands of words;
• logical representations, modeling WHAT a system does, rather than physical models showing HOW it does it;
• hierarchical, showing systems at any level of detail; and
• Jargon less, allowing user understanding and reviewing.

The goal of data flow diagramming is to have a commonly understood model of a system. The diagrams are the basis of structured systems analysis. Data flow diagrams are supported by other techniques of structured systems analysis such as data structure d diagrams, data dictionaries, and procedure-representing techniques such as decision tables, decision trees, and structured English.

Data flow diagrams have the objective of avoiding the cost of:
• User/developer misunderstanding of a system, resulting in a need to redo systems or in not using the system.
• Having to start documentation from scratch when the physical system changes since the logical system, WHAT gets done, often remains the same when technology changes.
• Systems inefficiencies because a system gets "computerized" before it gets "systematized".
• Being unable to evaluate system project boundaries or degree of automation, resulting in a project of inappropriate scope.

Description:
Data Flow Diagrams are composed of the four basic symbols shown below



The External Entity symbol represents sources of data to the system or destinations of data from the system.
The Data Flow symbol represents movement of data.
The Data Store symbol represents data that is not moving (delayed data at rest).
The Process symbol represents an activity that transforms or manipulates the data (combines, reorders, converts, etc.).
Any system can be represented at any level of detail by these four symbols.

External Entities:
1. Are named with appropriate name.
2. Can be duplicated, one or more times, on the diagram to avoid line crossing.
3. Determine the system boundary. They are external to the system being studied. They are often beyond the area of influence of the developer.
4. Can represent another system or subsystem.
5. Go on margins/edges of data flow diagram.
________________________________________
Data Flows:
1. Are represented with a line with an arrowhead on one end. A fork in a data flow means that the same data goes to two separate destinations. The same data coming from several locations can also be joined.
2. Should only represent data, not control.
3. Are ALWAYS named. Name is not to include the word "data".
4. Are referenced by a combination of the identifiers of the constructs that the data flow connects. (14-A references a data flow from process 14 to external entity A)
________________________________________
Data Stores:
1. Are generic for physical files (index cards, desk drawers, magnetic disk, magnetic tape, shirt pocket, human memory, etc.)
2. Are named with an appropriate name, not to include the word "file", and numbered with a number preceded with a capital letter D
3. Can be duplicated, one or more times, to avoid line crossing.
4. Can show two or more systems that share a data store. This is done by adding a solid stripe on the left boundary. (Figure 5.34) This can occur in the case of one system updating the data store, while the other system only accesses the data. For ex ample, the data store could be a freight rate book that one system builds and maintains, but is used by the represented system.
5. Are detailed in the data dictionary or with data description diagrams.
________________________________________
Processes:
1. Show data transformation or change. Data coming into a process must be "worked on" or transformed in some way. Thus, all processes must have inputs and outputs. In some (rare) cases, data inputs or outputs will only be shown at more detailed levels of the diagrams. Each process in always "running" and ready to accept data.
2. Are represented by a rounded corner rectangle
3. Are named with one carefully chosen verb and an object of the verb. There is no subject. Name is not to include the word "process". Each process should represent one function or action. If there is an "and" in the name, you likely have more than o ne function (and process).
4. Have physical location shown only for existing physical systems or a physical design is being represented.
5. Are numbered within the diagram as convenient. Levels of detail are shown by decimal notation. For example, top level process would be Process 14, next level of detail Processes 14.1-14.4, and next level with Processes 14.3.1-14.3.6.
6. Should generally move from top to bottom and left to right.
Procedure:
The procedure for producing a data flow diagram is to:
1. Identify and list external entities providing inputs/receiving outputs from system;
2. Identify and list inputs from/outputs to external entities;
3. Create a context diagram with system at center and external entities sending and receiving data flows;
4. Identify the business functions included within the system boundary;
5. Identify the data connections between business functions;
6. Confirm through personal contact sent data is received and vice-versa;
7. Trace and record what happens to each of the data flows entering the system (data movement, data storage, data transformation/processing)
8. Attempt to connect any diagram segments into a rough draft;
9. Verify all data flows have a source and destination;
10. Verify data coming out of a data store goes in;
11. Redraw to simplify--ponder and question result;
12. Review with "informed";
13. Explode and repeat above steps as needed.


http://spot.colorado.edu/~kozar/DFDtechnique.html
http://en.wikipedia.org/wiki/Data_flow_diagram


After having a clear view on what is DFD and how to create it, here are the characteristics that a system analyst must have in order to evaluate DFDs properly.
CHARACTERISTICS

First, system analysts must have a wide background or knowledge of what a system must accomplish and how to realize these goals. If an analyst lacks sufficient information, he/she might miss some points in evaluating the DFD of the said system. Good DFD evaluation requires enough background on the process of the system, as well as the business process since the system is also based on the business processes that the company wants to automate.

Second, system analysts must have critical thinking. This means that he or she should analyze the DFD in order to fill missing parts, or omit unnecessary entities. The analyst must be able to restructure the DFD if necessary and provide a clear distinction on the levels of DFDs as to what correct amount of detail it must contain.

He or she must also know how to write DFDs properly. As stated above, there are symbols that DFDs use in order to represent the entities, data stores, processes or data flows. Symbols are critical since a small mistake could lead to vague DFDs. They should be able to see small or trivial things like wrong direction of arrows in data flows.

Systems analysts must also keep in mind that systems today are very dynamic and could change anytime. He or she should be open to these changes and adapt to them in order to evaluate properly those DFDs that were very complicated.

As far as I know, these are the characteristics that a good system analyst must have in order to evaluate DFDs properly.
If there are more characteristics that I miss, feel free to comment so I could include them.

Dialogue between a systems professional, John Juan, and a manager of a department targeted for a new information system, Peter Pedro

Consider the following dialogue between a systems professional, John Juan, and a manager of a department targeted for a new information system, Peter Pedro:

Juan: The way to go about the analysis is to first examine the old system, such as reviewing key documents and observing the workers perform their tasks. Then we can determine which aspects are working well and which should be preserved.

Pedro: We have been through these types of projects before and what always ends up happening is that we do not get the new system we are promised; we get a modified version of the old system.

Juan: Well, I can assure you that will not happen this time. We just want a thorough understanding of what is working well and what isn’t.

Pedro: I would feel much more comfortable if we first started with a list of our requirements. We should spend some time up-front determining exactly what we want the system to do for my department. Then you systems people can come in and determine what portions to salvage if you wish. Just don’t constrain us to the old system.

Required:

a.Obviously these two workers have different views on how the systems analysis phase should be conducted. Comment on whose position you sympathize with the most.
b.What method would you propose they take? Why?
(3000 words)



Both John Juan and Peter Pedro have good points. Juan follows the basic steps in a software development life cycle. To give you a quick overview of the SDLC here is a diagram.



Brief explanations of the above diagram are as follows:


Initiation/planning

To generate a high-level view of the intended project and determine the goals of the project. The feasibility study is sometimes used to present the project to upper management in an attempt to gain funding. Projects are typically evaluated in three areas of feasibility: economical, operational or organizational, and technical. Furthermore, it is also used as a reference to keep the project on track and to evaluate the progress of the MIS team.[8] The MIS is also a complement of those phases. This phase is also called the analysis phase.
Requirements gathering and analysis

The goal of systems analysis is to determine where the problem is in an attempt to fix the system. This step involves breaking down the system in different pieces and drawing diagrams to analyze the situation, analyzing project goals, breaking need to be created and attempting to engage users so that definite requirements can be defined. Requirement Gathering sometimes require individual/team from client as well as service provider side to get a detailed and accurate requirements.


Design

In systems design functions and operations are described in detail, including screen layouts, business rules, process diagrams and other documentation. The output of this stage will describe the new system as a collection of modules or subsystems.
The design stage takes as its initial input the requirements identified in the approved requirements document. For each requirement, a set of one or more design elements will be produced as a result of interviews, workshops, and/or prototype efforts. Design elements describe the desired software features in detail, and generally include functional hierarchy diagrams, screen layout diagrams, tables of business rules, business process diagrams, pseudocode, and a complete entity-relationship diagram with a full data dictionary. These design elements are intended to describe the software in sufficient detail that skilled programmers may develop the software with minimal additional input.


Build or coding

Modular and subsystem programming code will be accomplished during this stage. Unit testing and module testing are done in this stage by the developers. This stage is intermingled with the next in that individual modules will need testing before integration to the main project.code will be test in every sections.


Testing

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 occurs at this stage.

Types of testing:
• Data set testing.
• Unit testing
• System testing
• Integration testing
• Black box testing
• White box testing
• Regression testing
• Automation testing
• User acceptance testing
• Performance testing


Operations and maintenance

The deployment of the system includes changes and enhancements before the decommissioning or sunset of the system. Maintaining the system is an important aspect of SDLC. As key personnel change positions in the organization, new changes will be implemented, which will require system updates.



It is clearly stated that after in initiation phase, System Concept Development would follow. This defines the boundary of the concepts. In Pedro and Juan’s case, this is the phase where Juan examines the old system that Pedro’s company is using.

Next step is to plan. This is where Juan develops a plan for Pedro’s system based on the old system that Juan examines.

Then here comes Requirement Analysis Phase. This is where Juan listens to Pedro’s requirements on their new system. Juan will analyze user needs and develop user requirements. Juan will also create detailed functional requirements where Pedro can check if there are missing requirements.


a. Obviously these two workers have different views on how the systems analysis phase should be conducted. Comment on whose position you sympathize with the most.

For me, I sympathized with both parties since they both wanted to do their job in a way that they know is right. Since Juan is the analyst, who knows better on the systems analysis phase than Pedro, he must present to Pedro what are the steps involve during that phase and what are the consequences if ever Juan does not follow the steps. On the side of Pedro, he must also understand that there are required steps to be done before starting a list of requirements for the new systems.
But of course, since they both want to develop the new system properly, one of them should give way for the welfare of the system. Since Juan knows how to make the system correctly, Pedro should let Juan do his job. In return, Juan should fulfill the requirements set by Pedro later on in the requirements analysis phase. On how they will assure that, will be discussed in the succeeding paragraphs.


b. What method would you propose they take? Why?

I have encountered five (5) commonly used methods in developing a system. Each of them will be discussed briefly in order to compare and later on I will propose what methods they should take.

Every software development methodology has more or less its own approach to software development. There is a set of more general approaches, which are developed into several specific methodologies. These approaches are:

• Waterfall: linear framework type.
• Prototyping: iterative framework type
• Incremental: combination of linear and iterative framework type
• Spiral: combination linear and iterative framework type
• Rapid Application Development (RAD): Iterative Framework Type


Waterfall model

The waterfall model is a sequential development process, in which development is seen as flowing steadily downwards (like a waterfall) through the phases of requirements analysis, design, implementation, testing (validation), integration, and maintenance. The first formal description of the waterfall model is often cited to be an article published by Winston W. Royce in 1970 although Royce did not use the term "waterfall" in this article.

Basic principles of the waterfall model are:
• Project is divided into sequential phases, with some overlap and splashback acceptable between phases.
• Emphasis is on planning, time schedules, target dates, budgets and implementation of an entire system at one time.
• Tight control is maintained over the life of the project through the use of extensive written documentation, as well as through formal reviews and approval/signoff by the user and information technology management occurring at the end of most phases before beginning the next phase.


Incremental

Various methods are acceptable for combining linear and iterative systems development methodologies, with the primary objective of each being to reduce inherent project risk by breaking a project into smaller segments and providing more ease-of-change during the development process.

Basic principles of incremental development are:
• A series of mini-Waterfalls are performed, where all phases of the Waterfall development model are completed for a small part of the systems, before proceeding to the next incremental, or
• Overall requirements are defined before proceeding to evolutionary, mini-Waterfall development of individual increments of the system, or
• The initial software concept, requirements analysis, and design of architecture and system core are defined using the Waterfall approach, followed by iterative Prototyping, which culminates in installation of the final prototype (i.e., working system).


Spiral

The spiral model is a software development process combining elements of both design and prototyping-in-stages, in an effort to combine advantages of top-down and bottom-up concepts.

Basic principles:
• Focus is on risk assessment and on minimizing project risk by breaking a project into smaller segments and providing more ease-of-change during the development process, as well as providing the opportunity to evaluate risks and weigh consideration of project continuation throughout the life cycle.
• "Each cycle involves a progression through the same sequence of steps, for each portion of the product and for each of its levels of elaboration, from an overall concept-of-operation document down to the coding of each individual program."
• Each trip around the spiral traverses four basic quadarants: (1) determine objectives, alternatives, and constrainst of the iteration; (2) Evaluate alternatives; Identify and resolve risks; (3) develop and verify deliverables from the iteration; and (4) plan the next iteration.
• Begin each cycle with an identification of stakeholders and their win conditions, and end each cycle with review and commitment.


Rapid Application Development (RAD)

Rapid Application Development (RAD) is a software development methodology, which involves iterative development and the construction of prototypes. Rapid application development is a term originally used to describe a software development process introduced by James Martin in 1991.

Basic principles:
• Key objective is for fast development and delivery of a high quality system at a relatively low investment cost.
• Attempts to reduce inherent project risk by breaking a project into smaller segments and providing more ease-of-change during the development process.
• Aims to produce high quality systems quickly, primarily through the use of iterative Prototyping (at any stage of development), active user involvement, and computerized development tools. These tools may include Graphical User Interface (GUI) builders, Computer Aided Software Engineering (CASE) tools, Database Management Systems (DBMS), fourth-generation programming languages, code generators, and object-oriented techniques.
• Key emphasis is on fulfilling the business need, while technological or engineering excellence is of lesser importance.
• Project control involves prioritizing development and defining delivery deadlines or “timeboxes”. If the project starts to slip, emphasis is on reducing requirements to fit the timebox, not in increasing the deadline.
• Generally includes Joint Application Development (JAD), where users are intensely involved in system design, either through consensus building in structured workshops, or through electronically facilitated interaction.
• Active user involvement is imperative.
• Iteratively produces production software, as opposed to a throwaway prototype.
• Produces documentation necessary to facilitate future development and maintenance.
• Standard systems analysis and design techniques can be fitted into this framework.


Prototyping

Software prototyping, is the framework of activities during software development of creating prototypes, i.e., incomplete versions of the software program being developed.

Basic principles of prototyping are:
• Not a standalone, complete development methodology, but rather an approach to handling selected portions of a larger, more traditional development methodology (i.e. Incremental, Spiral, or Rapid Application Development (RAD)).
• Attempts to reduce inherent project risk by breaking a project into smaller segments and providing more ease-of-change during the development process.
• User is involved throughout the process, which increases the likelihood of user acceptance of the final implementation.
• Small-scale mock-ups of the system are developed following an iterative modification process until the prototype evolves to meet the users’ requirements.
• While most prototypes are developed with the expectation that they will be discarded, it is possible in some cases to evolve from prototype to working system.
• A basic understanding of the fundamental business problem is necessary to avoid solving the wrong problem.


Based on the five given definitions and basic principles of each method above, I would suggest using prototyping.
Since Pedro have traumas receiving a modified version of the old system, it means that the previous developers of the system does not focus more on user requirements or they lack user involvement during development. It is obvious that system developments need to involve user during design or any other phases in the development. Small-scale mock-ups of the system are developed following an iterative modification process until the prototype evolves to meet the users’ requirements only means that the system is continuously being assessed just to meet users requirements.
Furthermore, both parties should sign a contract to guarantee that both will confirm to the agreement. It should be very detailed since Pedro wants a system that really meets their requirements and slight changes may breach the contract if they are not careful enough.


References:
http://law.jrank.org/pages/5688/Contracts-Types-Contracts.html
http://en.wikipedia.org/wiki/Contract
http://en.wikipedia.org/wiki/Systems_Development_Life_Cycle
http://www.answers.com/topic/systems-analysis
http://www.answers.com/topic/systems-engineering
http://en.wikipedia.org/wiki/Dynamic_Systems_Development_Method
http://en.wikipedia.org/wiki/Software_development_methodology

Consider your school, how do you know that the life cycle was developed specifically for the university? How do we know it meets our needs?

First let us define what is a system development life cycle.

The Systems Development Life Cycle (SDLC), or Software Development Life Cycle in systems engineering and software engineering, is the process of creating or altering systems, and the models and methodologies that people use to develop these systems. The concept generally refers to computer or information 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.

A Systems Development Life Cycle (SDLC) is any logical process used by a systems analyst to develop an information system, including requirements, validation, 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 have become more complex and often (especially with the advent of Service-Oriented Architecture) link multiple traditional systems potentially supplied by different software vendors. To manage this level of complexity, a number of systems development life cycle (SDLC) models have been created: "waterfall"; "fountain"; "spiral"; "build and fix"; "rapid prototyping"; "incremental"; and "synchronize and stabilize".

SDLC models can be described along a spectrum of agile to iterative to sequential. Agile methodologies, such as XP and Scrum, focus on light-weight 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 scopes and expanding or improving products by multiple iterations. Sequential or big-design-upfront (BDUF) models, such as Waterfall, focus on complete and correct planning to guide large projects and risks to successful and predictable results.

Some agile and iterative proponents confuse the term SDLC with sequential or "more traditional" processes; however, SDLC is an umbrella term for all methodologies for the design, implementation, and release of software.
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".

The systems development lifecycle (SDLC) is a type of 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 1960s 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. Eversince, 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
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. There are several Systems Development Life Cycle Models in existence. The oldest model, that was originally regarded as "the Systems Development Life Cycle" is the waterfall model: a sequence of stages in which the output of each stage becomes the input for the next. These stages generally follow the same basic steps but many different waterfall methodologies give the steps different names and the number of steps seem to vary between 4 and 7. There is no definitively correct Systems Development Life Cycle model, but the steps can be characterized and divided in several steps.

Initiation/planning
To generate a high-level view of the intended project and determine the goals of the project. The feasibility study is sometimes used to present the project to upper management in an attempt to gain funding. Projects are typically evaluated in three areas of feasibility: economical, operational or organizational, and technical. Furthermore, it is also used as a reference to keep the project on track and to evaluate the progress of the MIS team.[8] The MIS is also a complement of those phases. This phase is also called the analysis phase.

Requirements gathering and analysis
The goal of systems analysis is to determine where the problem is in an attempt to fix the system. This step involves breaking down the system in different pieces and drawing diagrams to analyze the situation, analyzing project goals, breaking need to be created and attempting to engage users so that definite requirements can be defined. Requirement Gathering sometimes require individual/team from client as well as service provider side to get a detailed and accurate requirements.

Design
Strengths and weaknesses
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.
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.
It should not be assumed that just because the waterfall model is the oldest original SDLC model that it is the most efficient system. At one time the model was beneficial mostly to the world of automating activities that were assigned to clerks and accountants. However, the world of technological evolution is demanding that systems have a greater functionality that would assist help desk technicians/administrators or information technology specialists/analysts.
A software development process is a structure imposed on the development of a software product. Synonyms include software life cycle and software process. There are several models for such processes, each describing approaches to a variety of tasks or activities that take place during the process.

The largely growing body of software development organizations implement process methodologies. Many of them are in the defense industry, which in the U.S. requires a rating based on 'process models' to obtain contracts.
The international standard for describing the method of selecting, implementing and monitoring the life cycle for software is ISO 12207.

A decades-long goal has been to find repeatable, predictable processes that improve productivity and quality. Some try to systematize or formalize the seemingly unruly task of writing software. Others apply project management techniques to writing software. Without project management, software projects can easily be delivered late or over budget. With large numbers of software projects not meeting their expectations in terms of functionality, cost, or delivery schedule, effective project management appears to be lacking.

Organizations may create a Software Engineering Process Group (SEPG), which is the focal point for process improvement. Composed of line practitioners who have varied skills, the group is at the center of the collaborative effort of everyone in the organization who is involved with software engineering process improvement.

Planning
The important task in creating a software product 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. Incomplete, ambiguous, or even contradictory requirements are recognized by skilled and experienced software engineers at this point. Frequently demonstrating live code may help reduce the risk that the requirements are incorrect.
Once the general requirements are gleaned 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 part of the software development process. This part of the process ensures that bugs are recognized as early as possible.

Documenting the internal design of software for the purpose of future maintenance and enhancement is done throughout development. This may also include the authoring of an API, be it external or internal.

Deployment and maintenance
Deployment starts after the code is appropriately tested, is approved for release and sold or otherwise distributed into a production environment.

Software Training and Support is important because a large percentage of software projects fail because the developers fail to realize that it doesn't matter how much time and planning a development team puts into creating software if nobody in an organization ends up using it. People are often resistant to change and avoid venturing into an unfamiliar area, so as a part of the deployment phase, it is very important to have training classes for new clients of your software.

Maintenance and enhancing software to cope with newly discovered problems or new requirements can take far more time than the initial development of the software. It may be necessary to add code that does not fit the original design to correct an unforeseen problem or it may be that a customer is requesting more functionality and code can be added to accommodate their requests. It is during this phase that customer calls come in and you see whether your testing was extensive enough to uncover the problems before customers do. If the labor cost of the maintenance phase exceeds 25% of the prior-phases' labor cost, then it is likely that the overall quality, of at least one prior phase, is poor. In that case, management should consider the option of rebuilding the system (or portions) before maintenance cost is out of control.

Bug Tracking System tools are often deployed at this stage of the process to allow development teams to interface with customer/field teams testing the software to identify any real or perceived issues. These software tools, both open source and commercially licensed, provide a customizable process to acquire, review, acknowledge, and respond to reported issues.

Models
Iterative processes
Iterative development prescribes the construction of initially small but ever larger portions of a software project to help all those involved to uncover important issues early before problems or faulty assumptions can lead to disaster. Iterative processes are preferred by commercial developers because it allows a potential of reaching the design goals of a customer who does not know how to define what they want.
Agile software development processes are built on the foundation of iterative development. To that foundation they add a lighter, more people-centric viewpoint than traditional approaches. Agile processes use feedback, rather than planning, as their primary control mechanism. The feedback is driven by regular tests and releases of the evolving software.

XP: Extreme Programming
Extreme Programming (XP) is the best-known iterative process. In 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. Design is done by the same people who do the coding. (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.

Waterfall processes
The waterfall model shows a process, where developers are to follow these steps in order:
1. Requirements specification (AKA Verification or Analysis)
2. Design
3. Construction (AKA implementation or coding)
4. Integration
5. Testing and debugging (AKA validation)
6. Installation (AKA deployment)
7. Maintenance

After each step is finished, the process proceeds to the next step, just as builders don't revise the foundation of a house after the framing has been erected.

There is a misconception that the process has no provision for correcting errors in early steps (for example, in the requirements). In fact, this is where the domain of requirements management comes in, which includes change control. The counter argument, by critics to the process, is the significantly increased cost in correcting problems through introduction of iterations. This is also the factor that extends delivery time and makes this process increasingly unpopular even in high risk projects.

This approach is used in high risk projects, particularly large defense contracts. The problems in waterfall do not arise from "immature engineering practices, particularly in requirements analysis and requirements management."
Often the supposed stages are part of review between customer and supplier, the supplier can, in fact, develop at risk and evolve the design but must sell off the design at a key milestone called Critical Design Review (CDR). This shifts engineering burdens from engineers to customers who may have other skills.

For many types of systems it is as important that the usability is as good as the functionality. There have been various attempts during the last fifteen years or more to encourage developers to focus on usability during the life cycle. These have had only limited success in that they have affected certain companies without fundamentally changing the overall software development process.

In our case (University of Southeastern Philippines), we will only know if the life cycle is developed specifically to meet our needs when the data used during requirement analysis phase were really the problems encountered by our school. Planning phase should be based on the school’s situation and deployment and implementation should be in accordance to the school’s welfare. In short, everything should be done to realize the goals set by the administration. Each phase in the life cycle development should be done carefully. We will know if it meets our needs if the problems stated were answered or given solutions.


references:

http://en.wikipedia.org/wiki/Systems_Development_Life_Cycle
http://en.wikipedia.org/wiki/Waterfall_model
http://en.wikipedia.org/wiki/Spiral_model
http://en.wikipedia.org/wiki/Iterative_and_incremental_development

Identify and discuss at least 3 systems development models

A Systems Development Life Cycle (SDLC) is any logical process used by a systems analyst to develop an information system, including requirements, validation, 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 have become more complex and often (especially with the advent of Service-Oriented Architecture) link multiple traditional systems potentially supplied by different software vendors. To manage this level of complexity, a number of systems development life cycle (SDLC) models have been created: "waterfall"; "fountain"; "spiral"; "build and fix"; "rapid prototyping"; "incremental"; and "synchronize and stabilize".

SDLC models can be described along a spectrum of agile to iterative to sequential. Agile methodologies, such as XP and Scrum, focus on light-weight 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 scopes and expanding or improving products by multiple iterations. Sequential or big-design-upfront (BDUF) models, such as Waterfall, focus on complete and correct planning to guide large projects and risks to successful and predictable results.

History
The systems development lifecycle (SDLC) is a type of 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 1960s 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. Eversince, 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
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. There are several Systems Development Life Cycle Models in existence. The oldest model, that was originally regarded as "the Systems Development Life Cycle" is the waterfall model: a sequence of stages in which the output of each stage becomes the input for the next. These stages generally follow the same basic steps but many different waterfall methodologies give the steps different names and the number of steps seem to vary between 4 and 7. There is no definitively correct Systems Development Life Cycle model, but the steps can be characterized and divided in several steps.

Waterfall model
The waterfall model is a sequential software development process, in which progress is seen as flowing steadily downwards (like a waterfall) through the phases of Conception, Initiation, Analysis, Design (validation), Construction, Testing and maintenance.

The waterfall development model has its origins in the manufacturing and construction industries; highly structured physical environments in which after-the-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 formal description of the waterfall model is often cited to be an article published in 1970 by Winston W. Royce (1929–1995). although Royce did not use the term "waterfall" in this article. Royce was presenting this model as an example of a flawed, non-working model (Royce 1970). This is in fact the way the term has generally been used in writing about software development—as a way to criticize a commonly used software practice.

Model
In Royce's original Waterfall model, the following phases are followed in order:
1. Requirements specification
2. Design
3. Construction (AKA implementation or coding)
4. Integration
5. Testing and debugging (AKA Validation)
6. Installation
7. Maintenance

To follow the waterfall model, one proceeds from one phase to the next in a purely sequential manner. For example, one first completes requirements specification, which are set in stone. When the requirements are fully completed, one proceeds to design. The software in question is designed and a blueprint is drawn for implementers (coders) to follow — this design should be a plan for implementing the requirements given. When the design is fully completed, an implementation of that design is made by coders. Towards the later stages of this implementation phase, separate software components produced are combined to introduce new functionality and reduced risk through the removal of errors.
Thus the waterfall model maintains that one should move to a phase only when its preceding phase is completed and perfected. However, there are various modified waterfall models (including Royce's final model) that may include slight or major variations upon this process.

Time spent early in the software production cycle can lead to greater economy at later stages. It has been shown that a bug found in the early stages (such as requirements specification or design) is cheaper in terms of money, effort and time, to fix than the same bug found later on in the process. ([McConnell 1996], p. 72, estimates that "a requirements defect that is left undetected until construction or maintenance will cost 50 to 200 times as much to fix as it would have cost to fix at requirements time.") 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 (BDUF) and the waterfall model - time spent early on making sure that requirements and design are absolutely correct will save you much time and effort later. Thus, the thinking of those who follow the waterfall process goes, one should make sure that each phase is 100% complete and absolutely correct before proceeding to the next phase of program creation. Program requirements should be set in stone before design is started (otherwise work put into a design based on incorrect requirements is wasted); the program's design should be perfect before people begin work on implementing the design (otherwise they are implementing 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 designed and documented methodologies, should team members leave, much knowledge is lost and may be difficult for a project to recover from. Should a fully working design document be 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.

As well as the above, some prefer the waterfall model for its simple approach and argue that it is more disciplined. Rather than what the waterfall adherent sees as chaos, 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 markable 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 which 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 spiral model is a software development process combining elements of both design and prototyping-in-stages, in an effort to combine advantages of top-down and bottom-up concepts. Also known as the spiral lifecycle model (or spiral development), it is a systems development method (SDM) used in information technology (IT). This model of development combines the features of the prototyping model and the waterfall model. The spiral model is intended for large, expensive and complicated projects.

History
The spiral model was defined by Barry Boehm in his 1988 article "A Spiral Model of Software Development and Enhancement". This model was not the first model to discuss iterative development, but it was the first model to explain why the iteration matters.
As originally envisioned, the iterations were typically 6 months to 2 years long. Each phase starts with a design goal and ends with the client (who may be internal) reviewing the progress thus far. Analysis and engineering efforts are applied at each phase of the project, with an eye toward the end goal of the project.

Steps
The steps in the spiral model iteration can be generalized as follows:
1. The new system requirements are defined in as much detail as possible. This usually involves interviewing a number of users representing all the external or internal users and other aspects of the existing system.
2. A preliminary design is created for the new system.This phase is the most important part of "Spiral Model". In this phase all possible (and available) alternatives, which can help in developing a cost effective project are analyzed and strategies are decided to use them. This phase has been added specially in order to identify and resolve all the possible risks in the project development. If risks indicate any kind of uncertainty in requirements, prototyping may be used to proceed with the available data and find out possible solution in order to deal with the potential changes in the requirements.
3. A first prototype of the new system is constructed from the preliminary design. This is usually a scaled-down system, and represents an approximation of the characteristics of the final product.
4. A second prototype is evolved by a fourfold procedure:
1. evaluating the first prototype in terms of its strengths, weaknesses, and risks;
2. defining the requirements of the second prototype;
3. planning and designing the second prototype;
4. constructing and testing the second prototype.
Iterative and incremental development
Iterative and Incremental development is 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 interaction in between.


An iterative development model

The iterative and incremental development is an essential part of the Rational Unified Process, the Dynamic Systems Development Method, Extreme Programming and generally the agile software development frameworks.

The Basic idea
The basic idea behind iterative enhancement is to develop a software system incrementally, allowing the developer to take advantage of what was being learned during the development of earlier, incremental, deliverable versions of the system. Learning comes from both the development and use of the system, where possible key steps in the process are to start with a simple implementation of a subset of the software requirements and iteratively enhance the evolving sequence of versions until the full system is implemented. At each iteration, design modifications are made and new functional capabilities are added.

The Procedure itself consists of the Initialization step, the Iteration step, and the Project Control List. The initialization step creates a base version of the system. The goal for this initial implementation is to create a product to which the user can react. It should offer a sampling of the key aspects of the problem and provide a solution that is simple enough to understand and implement easily. To guide the iteration process, a project control list is created that contains a record of all tasks that need to be performed. It includes such items as new features to be implemented and areas of redesign of the existing solution. The control list is constantly being revised as a result of the analysis phase.

The iteration involves the redesign and implementation of a task from the project control list, and the analysis of the current version of the system. The goal for the design and implementation of any iteration is to be simple, straightforward, and modular, supporting redesign at that stage or as a task added to the project control list. The level of design detail is not dictated by the interactive approach. In a light-weight iterative project the code may represent the major source of documentation of the system; however, in a mission-critical iterative project a formal Software Design Document may be used. The analysis of an iteration is based upon user feedback, and the program analysis facilities available. It involves analysis of the structure, modularity, usability, reliability, efficiency, & achievement of goals. The project control list is modified in light of the analysis results.

Iterative development
Iterative development slices the deliverable business value (system functionality) into iterations. In each iteration a slice of functionality is delivered through cross-discipline work, starting from the model/requirements through to the testing/deployment. The unified process groups iterations into phases: inception, elaboration, construction, and transition.
• Inception identifies project scope, risks, and requirements (functional and non-functional) at a high level but in enough detail that work can be estimated.
• Elaboration delivers a working architecture that mitigates the top risks and fulfills the non-functional requirements.
• Construction incrementally fills-in the architecture with production-ready 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.

Waterfall vs. Iterative Development
Waterfall development completes the project-wide work-products of each discipline in a single step before moving on to the next discipline in the next step. Business value is delivered all at once, and only at the very end of the project. Backtracking is possible in an iterative approach..
Implementation guidelines
Guidelines that drive the implementation and analysis include:
• Any difficulty in design, coding and testing a modification should signal the need for redesign or re-coding.
• Modifications should fit easily into isolated and easy-to-find modules. If they do not, some redesign is needed.
• Modifications to tables should be especially easy to make. If any table modification is not quickly and easily done, redesign is indicated.
• Modifications should become easier to make as the iterations progress. If they are not, there is a basic problem such as a design flaw or a proliferation of patches.
• Patches should normally be allowed to exist for only one or two iterations. Patches may be necessary to avoid redesigning during an implementation phase.
• The existing implementation should be analysed frequently to determine how well it measures up to project goals.
• Program analysis facilities should be used whenever available to aid in the analysis of partial implementations.
• User reaction should be solicited and analysed for indications of deficiencies in the current implementation.


Dynamic Systems Development Method

Dynamic Systems Development Method (DSDM) is a software development methodology originally based upon the Rapid Application Development methodology. DSDM is an iterative and incremental approach that emphasises continuous user involvement.
Its goal is to deliver software systems on time and on budget while adjusting for changing requirements along the development process. DSDM is one of a number of Agile methods for developing software, and it forms a part of the Agile Alliance.

As an extension of rapid application development, DSDM focuses on Information Systems projects that are characterised by tight schedules and budgets. DSDM addresses the most common failures of information systems projects, including exceeding budgets, missing deadlines, and lack of user involvement and top-management commitment. By encouraging the use of RAD, however, careless adoption of DSDM may increase the risk of cutting too many corners. DSDM consists of

• Three phases: pre-project phase, project life-cycle phase, and post-project phase.
• A project life-cycle phase subdivided into 5 stages: feasibility study, business study, functional model iteration, design and build iteration, and implementation.

In some circumstances, there are possibilities to integrate practices from other methodologies, such as Rational Unified Process (RUP), Extreme Programming (XP), and PRINCE2, as complements to DSDM. Another agile method that has some similarity in process and concept to DSDM is Scrum.
DSDM was developed in the United Kingdom in the 1990s by the DSDM Consortium, an association of vendors and experts in the field of software engineering created with the objective of "jointly developing and promoting an independent RAD framework" by combining their best practice experiences. The DSDM Consortium is a not-for-profit, vendor-independent organisation which owns and administers the DSDM framework. The first version was completed in January 1995 and was published in February 1995. The current version in use (as of April 2006) is Version 4.2: Framework for Business Centered Development, and was released in May 2003. In July 2006, DSDM Public Version 4.2 was made available for individuals to view and use; however, anyone reselling DSDM must still be a member of the not-for-profit consortium.

Principles
There are 9 underlying principles consisting of four foundations and five starting-points.
• User involvement is the main key in running an efficient and effective project, where both users and developers share a workplace, so that the decisions can be made accurately.
•
• The project team must be empowered to make decisions that are important to the progress of the project without waiting for higher-level approval.
•
• A focus on frequent delivery of products, with assumption that to deliver something "good enough" earlier is always better than to deliver everything "perfectly" in the end. By delivering product frequently from an early stage of the project, the product can be tested and reviewed where the test record and review document can be taken into account at the next iteration or phase.
•
• The main criteria for acceptance of a "deliverable" is delivering a system that addresses the current business needs. Delivering a perfect system which addresses all possible business needs is less important than focusing on critical functionalities.
•
• Development is iterative and incremental and driven by users’ feedback to converge on an effective business solution.
•
• All changes during the development are reversible.
•
• The high level scope and requirements should be base-lined before the project starts.
•
• Testing is carried out throughout the project life-cycle. (See Test-driven development for comparison).
•
• Communication and cooperation among all project stakeholders is required to be efficient and effective.


the following are my references on the models i have chosen:

http://en.wikipedia.org/wiki/Systems_Development_Life_Cycle
http://en.wikipedia.org/wiki/Waterfall_model
http://en.wikipedia.org/wiki/Spiral_model
http://en.wikipedia.org/wiki/Iterative_and_incremental_development