---SAD1 Assignment # 11---
---SAD2 Assignment # 10---
With reference to assignments 8 and 9, what characteristics does an analyst(you) examine when evaluating DFD quality?
---SAD2 Assignment # 9---
---SAD2 Assignment # 8---
---SAD2 Assignment # 7---
---SAD2 Assignment # 6---
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?
For me, both sides state their opinion about on how to improve and develop the old system. It is essential and commendable that both parties have their own methods in implementing and creating new information system. But in the story above, they have their own notion which results to a conflict. Both ideas would convince you to choose one, at some point to the other. Anyways, for me to decide on which idea is better, let me first state my understanding on both parties.
John’s Points of View (P.O.V)
As what I understand of John’s point is that he tried to point out that in analyzing the problem it is more effective if they would first scrutinize the old system and this is through reviewing important documents and workers performance. By this, they could now determine the strength and weaknesses of the old system, by gathering all this information’s they could provide solutions for the weaknesses and improvements and add some strength features to the existing system.
Since John is consider as a system professional it is expected that he has more knowledge on how to develop and modify improvements to a certain system. He gains more experience since he encountered giving vices to his clients, and as a system professional he has wide understanding on how a certain project must be processed as to what method should be used and what stage to improve.
Peter’s Points of View (P.O.V)
Now this time let me discuss my understanding of Peter’s point, he stress out that since the project proposed to him is not unusual, thus assessing the strengths and weaknesses of the existing system is not a solution or not as successful method in creating new one. Since he encountered scenario like this, he conclude that in making and using the same method like this, they end up not getting their expectation to the system which they compromised.
He wanted that they have to define the need of requirements since it is the first phase of creating a new system rather than specifying the old one. In addition to his point, he wanted that they have to appraise the true needs of their departments to create a system that meet their requirements.
My Points of View (P.O.V)
---SAD2 Assignment # 5---
Consider our school, how do we know that the life cycle was developed in our university and how do we know it meets our needs?
As a part of the university and as an IT student it is my privilege to know the development of the university, how it goes and how it works. System development is indeed contributing a big impact to any institution; but does the university apply this process to improve every form of transactions in the school? Does it meet the needs of every student, faculty and staff of the university? These are some of the questions that need an answer to be able to define a proper “development”. Let me first define what this life cycle means.
When I searched in the internet about the “life cycle”, I found different meanings in varied fields. Some in business meaning, from enterprise form to biological approach and there’s also from software life cycle to System Development Life Cycle also known as SDLC. With these various terms, I consider SDLC as a life cycle.
The system development life cycle is the process of developing information systems through investigation, analysis, design, implementation and maintenance. System development life cycle is a systems approach to problem solving and is made up of several phases, each comprised of multiple steps.
The major steps system development life cycle include the following steps.
Planning
It is the most important task in creating software products in making the planning steps they have to identify the scope and boundary of the problem, and plan the development strategy and goals.
Analysis
Study and analyze the problems, causes, and effects. Then, identify and analyze the requirements that must be fulfilled by any successful solutions.
Design
During the design phase the System Analyst will document the inputs, processing and outputs of each program within the application.
Implementation
Throughout the implementation phase programmers would be assigned to write the specific programs using a programming language decided by the system analyst. Once the system of programs is tested the new application is installed for people to use. As time goes by, things change and a specific part or program might need repair
Maintenance
In this phase, it goes through a mini planning, analysis, design and implementation. The programs that need modification are identified and programmers change or repair those programs. After several years of use, the system usually becomes obsolete. At this point a major revision of the application is done.
Now, how do we know if the cycle meets the needs of the university?
We would know that the chosen SDLC will meet the needs of the university if the understanding of its processes and the process itself gave way to easier and less time consuming software development with regards to the situation of the university. For example, we all know that the university is run by the government so we can assume that the budget will always be limited. Considering this fact, if our chosen SDLC will truly meet our needs then it must give processes that will less likely to rely on outsourcing.
---SAD1 Assignment #4---
We are to identify and discuss at least three system development models and discuss each phase.
Before the caterpillar will turn into a golden and beautiful butterfly it is gone through many phases, the same with software there are various processes to make it work. It passes through planning, developing, coding and many more to make it more feasible to any form of deployment. And one of these process or development is what we called system development process. Through reading different definition of system development modes I can say that system development life cycle is the process of developing information systems through investigation, analysis, design, implementation and maintenance. System development life cycle is a systems approach to problem solving and is made up of several phases, each comprised of multiple steps.
What are the different system development models?
Based on my understanding waterfall model describe as an extremely valuable tool to use in the implementation or revamping of any company. The waterfall model provides a strategic foundation in which a company can either update its existing system, or a company can create an entirely new system from scratch. There are seven phases to the systems development life cycle, and each phase must be completed in order, before the next phase begins, the phase before it must be complete. If a mistake is made, it may be necessary to start from scratch all over again, or go back several phases. If the phases are completed in order you should have a great foundation and you will be on your way to building a successful information system.
It is supposed to go down through a series of steps, reminding one of the routes a natural waterfall takes over a series of rocks at different levels.
In the traditional waterfall model, the first step in the software life-cycle is requirements analysis, this is the stage where the customers are queried for their needs, and a formal description of the software requirements is created. The next step is design, where the software that is to meet the requirements is planned. The third stage is implementation, where teams of developers create the software. The fourth step is testing, at which time developers, as well as representatives of the user community, is allowed to use the software and are asked to report any bugs they find. Upon completion of this step, the software is declared operational and only maintenance tasks are required thereafter.
The traditional waterfall model is much too simplistic, however, because each of the distinct steps it asks for is really itself a broad phase consisting of many sub-steps. In the detailed waterfall model, the requirements analysis step is extremely important. It is necessary to understand the customer's needs and to translate them into appropriate desired system behaviors. Any miscommunication with the customer could be fatal to the project as a whole, as it could result in a product that does not meet the customer's expectations, thus giving the company a bad reputation, a real disaster in the competitive software vendor's marketplace. Yet, communicating with the customer is not always easy either, because the customer may have only imprecisely-formulated objectives; or may have objectives that aren't vocalized very well and remain in the background for too long; or may have unrealizable or conflicting objectives. In some cases, it is necessary for the software development team to tell the customer exactly what he wants based on his vague utterances, and also whether he can get it needless to say, this involves a fair amount of skill at diplomacy and personal communication, in addition to knowledge of software engineering. Once the customer's requirements are understood, it is then necessary to document those requirements in a formal manner and reach an agreement with the customer about them.
Rapid Application Development (RAD) refers to a type of software development methodology that uses minimal planning in favor of rapid prototyping. The "planning" of software developed using RAD is interleaved with writing the software itself. The lack of extensive pre-planning generally allows software to be written much faster, and makes it easier to change requirements.
Below is a brief overview of the RAD process, including its advantages and disadvantages.
Advantages and Disadvantages:
The primary advantages of Rapid Application Development are speed and quality, while potentially reduced scalability and feature sets are the disadvantages.
As the name suggests, Rapid Application Development's primary advantage lies in an application's increased development speed and decreased time to delivery. The goal of delivering applications quickly is addressed through the use of computer aided software engineering or CASE tools, which focus on converting requirements to code as quickly as possible, as well as Time Boxing, in which features are pushed out to future releases in order to complete a feature light version quickly.
Requirements Planning Phase
The requirements planning phase requires that high level or knowledgeable end-users determine what the fuctions of the system should be. It should be a structured discussion of the business problems that need to be solved. It can often be done quickly when the right users and executives are involved. Requirements planning occurs in a Joint Requirements Planning workshop (JRP).
User Design Phase
The user design phase requires the users to participate strongly in the nontechnical design of the system, under the guidence of I.S. professionals. User design is done in a Joint Application Design (JAD) workshop similar to the JRP workshop. In the first two phases the users and executives should play a larger part than the I.S. professionals. Prototyping is used to aid in requirements specification and design. The user does not sign off a paper design, they sign off a CASE representation.
Construction Phase
The design created during the User Design Phase is added to using I-CASE tools. As each transaction is built it may be demonstrated to the end-users for revision. The CASE environment allows for the continuous changes in design. End-users are closely involved in the construction phase. Testing occurs throughout the process. The I-CASE toolset should generate the code as well as the database descriptions for the final product. Code optimizers may be used to improve the performance of the generated code.
Cutover Phase
When the cutover phase occurs, a variety of actions are needed, comprehensive testing, training of the end-users, organizational changes and operation in parallel with the previous system until the new system settle in.
Rapid Application Development is not appropriate for all projects. The methodology works best for projects where the scope is small or work can be broken down into manageable chunks. Along these lines project teams must also be small, preferably two to six people, and the team must have experience with all technologies that are to be used.
It is a practice-based methodology for modeling and documentation of software-based systems. It is intended to be a collection of values, principles, and practices for modeling software that can be applied on a software development project in a more flexible manner than traditional modeling methods. The system development process is complicated and complex. Therefore maximum flexibility and appropriate control is required. Evolution favors those that operate with maximum exposure to environmental change and have optimized for flexible adaptation to change. Evolution deselects those who have insulated themselves from environmental change and have minimized chaos and complexity in their environment. An approach is needed that enables development teams to operate adaptively within a complex environment using imprecise processes. Complex system development occurs under rapidly changing circumstances. Producing orderly systems under chaotic circumstances requires maximum flexibility.
Phase Steps
Each of the phases has the following steps:
Planning
• Development of a comprehensive backlog list.
• Definition of the delivery date and functionality of one or more releases.
• Selection of the release most appropriate for immediate development.
• Mapping of product packets (objects) for backlog items in the selected release.
• Definition of project team(s) for the building of the new release.
• Assessment of risk and appropriate risk controls.
• Review and possible adjustment of backlog items and packets.
• Validation or reselection of development tools and infrastructure.
• Estimation of release cost, including development, collateral material, marketing,
training, and rollout.
• Verification of management approval and funding.
Architecture/High Level Design
• Review assigned backlog items.
• Identify changes necessary to implement backlog items.
• Perform domain analysis to the extent required to build, enhance, or update the
domain models to reflect the new system context and requirements.
• Refine the system architecture to support the new context and requirements.
• Identify any problems or issues in developing or implementing the changes
• Design review meeting, each team presenting approach and changes to implement
each backlog item. Reassign changes as required.
Closure
When the management team feels that the variables of time, competition, requirements, cost, and quality concur for a new release to occur, they declare the release “closed” and enter this phase. This phase prepares the developed product for general release. Integration, system test, user documentation, training material preparation, and marketing material preparation are among closure tasks.
Sources:
http://en.wikipedia.org/wiki/Waterfall_model
http://hebb.cis.uoguelph.ca/~dave/27320/new/rad.html
http://en.wikipedia.org/wiki/Agile_software_development
---SAD1 Assignment # 3---
We are to interview a system analyst and discuss the role of a systems analyst as a project manager.
It was 29th of April 2010, thursday in the afternoon when my classmates and I visited Sta. Ana Multipurpose Cooperative (SAMULCO) to interview a system analyst. Sir James Bautista who is a system analyst of the cooperative gave her answers and entertained us for about 2 hours conversation. It was exiting and full of values, for we learned various things about system analyst. It’s not just a hi and hello front act but an educational experience interviewing this person. He simply answers the questions which we asked to him.
In the organization you are now, what is your role of a system analyst as a project manager?
Sir James Bautista first distinguished the difference between system analyst and project manager, he said that as a system analyst is the one who identified the need and the system opportunity by matching need and technical feasibility or as simple as a system analyst provides solution to the problem of a project, thus he look to the overall specifications of the project including its range and cost, the system analyst also make the design modeling including the different diagrams while a project manager is the head or leader of the project, as a project manager he has the ultimate responsibility for the planning and control of everything related to the project. Sir James added that as a project manager you are the one who communicate to your client set the entire responsibility of the members and set the time and also a project manager is the one who speak a front man in behalf of the group. But mostly today, a system analyst can be a project manager or as one for the reason that system analyst can have all the abilities of a project manager and knows all
the system requirements of the project.
Can you tell us some of your experienced as a project manager in your organization?
He tells us some of his project as a project manager managing it department in SAMULCO. Every year the corporation conducted a general assembly presented by all members of the corporation and Sir James and the rest of the team was given the task to assembly and operates for about 50 computers and brought to the venue. At around 6pm all the computers were in the mood and ready to set up, before the sun will rise the team should finish all the installation process to the computers and fortunately before the break of the dawn they all made it, tiring and sleepy. But he provides solution in the next year of assembly; he listed all the employees who will work for the setting of computers including the transportation and list all the people who will install the software to the computers. And luckily with the help of trainings and seminars for the personnel added to the team of Sir James, he successfully made a plan that would minimize his time working for the installation. From 3pm in the afternoon the all finished it around 7pm which less than 5 hours which has a big impact and improvement compare form the recent year plan. This is only one of his works as a project manager, who think for the possible solutions to minimize the work of the team, segregate well the responsibility of each member and create a plan that would possibly make the team effortless.
As a project manager what are your strengths and weaknesses?
Sir James Bautista shares to us his own strength and weakness and I quote “I know what I want, I get what I want.” And his weakness is “most of the time I think like a programmer” these could be also the weakness and strength of the entire system analyst and project manager of every organization. Lucky for us because we are given a chance to interview a project manager/ system analyst that is worth to be called a “professional and good system analyst”.
Giving an analogy unto it I believe that a project manager is like a DRIVER and take all the responsibility for many diverse tasks including, leading the project team through the process of creating and executing the project plan, mold every members into the project team, obtain all the approvals for the project plan, issue status report on the progress of the project compared to the plan and of course the project manager respond to the reques ts for changes to the plan. Also as a driver of the group one should remove obstacles for the team so they can do the job they are asked to do, call and run regular project meetings.
As a whole I think over to the interview we made and it knocks my mind to come up this summary about system analyst and project manager, that a successful project has the technical leadership of a system analyst and the management guidance of the project manager.