Juan or Pedro?

This was the scenario:

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?

The question was about the two workers having different views on how the systems analysis phase should be conducted. And then comment on whose position you sympathize with the most. So to start, for me I will go on to Mr. Juan’s point of view in the analysis phase because if the management really wanted a new system, the workflow and all of the processes of the organization will also change. So they will start from the scratch. But still they will base their new system to the goals and objective of the organization. What I like about Mr. Juan’s point of view in the analysis phase is that their business has already been running and had already set the goals and objective of what their business will be. Shall we say we will propose a new system, a really new system and not a modified one, all of the workflow and processes of the business of the organization will be affected and will definitely not the same as before. So that is also a risk that will be taken to account. Before proposing a new system, this is what you need to do in order to have an effective proposal. First is, you must plan and analyze all the necessary information or data that is needed for the new system but you are inclined to the business goals and objective of an organization. I’m not against the idea of Mr. Pedro to propose a new system that is not modified old system, a really new system. He just needs to be sure and work out well all the needed information and data for the new system. Changing an old system to a new system is very risky and hard to do but if it is successful the benefits of the system will be definitely come to use. Planning out a new system but still turning into a modified one is not really bad it is just making things easier, for example the old system is already coming to its full capacity, meaning the memory is coming to its limits then maybe they can modify it to be more efficient in the next 10 years, if not 5 years. When you talk about having a new system you are also taking it to account its life span of service in order for it to be more efficient. Talking about proposing a new system there are risks that is involve so proper planning is needed. But maybe also in addition, if you want to propose a new system you could do these things, it my own idea, first is gather all the needed information, then list all the requirements needed for the new system, then plan it very well and evaluate. Maybe this will help. If things are settled apply those things that are still useful and those things that can be eliminated. But that is only an idea. But generally, with very well planned system is also a good alternative. As relation to God what had said that there is no perfect thing or creature in this world as same as to those systems, just proper development and maintenance in order to have an efficient and well generating system.

b. What method would you propose they take? Why?
So the method that I would propose to them that they will take is the method of a system development process? For me the method depends on what really the management wants in order to make the system. So what are the steps? There are steps in creating a system, so in order for them to develop a system they should follow some protocols in developing a system. So there are steps in developing a system, which is the planning, implementation, testing, documenting, deployment, and maintenance. So these are the steps in system development process. So first things first is what is its definition 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 reason why I added the definition is that they can understand what my point is, or shall we say it is an overview in creating or developing a system. So to start, the first step you need to do is to plan; 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. So planning is short for SPMP (Software Project Management Plan). SPMP is a technique in which making the planning phase feasible. As you acquired the SPMP that is the time you can proceed to the analysis phase. So part of this is step are the analysis phase in a system development. So the requirements on analysis phase are the SRS or (Software Requirements Specification). Here you are going to identify all the information that is going to be included in your system. An example would be the system features of your system, the functional and non-functional requirements of your system. So if you are done in doing the SRS the next thing you should do is design. So these are some of the things you need to do in order to attain what are the goals that are needed to be accomplished. So if you already finished planning on what are the things you need to do, then you can proceed to the next step which is 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. Then, 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. The other technique that is crucial in developing a system is that you need to identify your model. There are many examples of models such as waterfall, agile, and extreme programming. But also there are other model that is also needs to be considered. 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. 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. 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.

Other models

Capability Maturity Model Integration

The Capability Maturity Model Integration (CMMI) is one of the leading models and based on best practice. Independent assessments grade organizations on how well they follow their defined processes, not on the quality of those processes or the software produced. CMMI has replaced CMM.

ISO 9000

ISO 9000 describes standards for a formally organized process to manufacture a product and the methods of managing and monitoring progress. Although the standard was originally created for the manufacturing sector, ISO 9000 standards has been applied to software development as well. Like CMMI, certification with ISO 9000 does not guarantee the quality of the end result, only that formalized business processes have been followed.

ISO 15504

ISO 15504, also known as Software Process Improvement Capability Determination (SPICE), is a "framework for the assessment of software processes". This standard is aimed at setting out a clear model for process comparison. SPICE is used much like CMMI. It models processes to manage, control, guide and monitor software development. This model is then used to measure what a development organization or project team actually does during software development. This information is analyzed to identify weaknesses and drive improvement. It also identifies strengths that can be continued or integrated into common practice for that organization or team.

Formal methods

Formal methods are mathematical approaches to solving software (and hardware) problems at the requirements, specification and design levels. Examples of formal methods include the B-Method, Petri nets, Automated theorem proving, RAISE and VDM. Various formal specification notations are available, such as the Z notation. More generally, automata theory can be used to build up and validate application behavior by designing a system of finite state machines. Finite state machine (FSM) based methodologies allow executable software specification and by-passing of conventional coding (see virtual finite state machine or event driven finite state machine). Formal methods are most likely to be applied in avionics software, particularly where the software is safety critical. Software safety assurance standards, such as DO178B demand formal methods at the highest level of categorization (Level A). Formalization of software development is creeping in, in other places, with the application of Object Constraint Language (and specializations such as Java Modeling Language) and especially with Model-driven architecture allowing execution of designs, if not specifications. Another emerging trend in software development is to write a specification in some form of logic (usually a variation of FOL), and then to directly execute the logic as though it were a program. The OWL language, based on Description Logic, is an example. There is also work on mapping some version of English (or another natural language) automatically to and from logic, and executing the logic directly. Examples are Attempto Controlled English, and Internet Business Logic, which does not seek to control the vocabulary or syntax. A feature of systems that support bidirectional English-logic mapping and direct execution of the logic is that they can be made to explain their results, in English, at the business or scientific level.

The Government Accountability Office, in a 2003 report on one of the Federal Aviation Administration’s air traffic control modernization programs,[2] recommends following the agency’s guidance for managing major acquisition systems by

· Establishing, maintaining, and controlling an accurate, valid, and current performance measurement baseline, which would include negotiating all authorized, unpriced work within 3 months;
· Conducting an integrated baseline review of any major contract modifications within 6 months; and
· Preparing a rigorous life-cycle cost estimate, including a risk assessment, in accordance with the Acquisition System Toolset’s guidance and identifying the level of uncertainty inherent in the estimate.

So these are the methods that I would suggest or propose to them.

References:
Google.com
http://en.wikipedia.org/wiki/Software_development_process