SAD 1 - (Assignment 4)

SYSTEMS DEVELOPMENT MODELS

We all have done on knowing how the System Analyst works in developing a certain task or project. This time, we are going to explore what are the aids or tools in developing a system. In developing a system, there are common system development process models that are used to guide the analysis, design, development, and maintenance of information systems. There are many different methods and techniques used to direct the life cycle of a software development project. Most techniques and methods have similarity in goals and share common task while each is designed for a specific purpose or reason. This topic will explore the similarities and differences among these various models and will also discuss how different approaches are chosen and combined to address practical situations.

The Waterfall Model

This model is said to be the earliest method of structured system development in a traditional approach. The simplest possible process model and therefore, the least likely to be correct. The waterfall model is widely used despite of being too inflexible and linear when it comes to meeting its customer’s needs. It models the software development process as a stately and chronological through the previously mentioned phases. As we can see in this model, Waterfall development has distinctive goals for each phase of development where each phase is completed for the next one is started and there is no turning back. Though it is orderly, simple to understand, and represents a process that is easy to manage and measure, the problem is that not even the simplest systems actually get built that way. But of course, in such methods and techniques, there’s always an advantage on it despite of the negative. And the seeming advantage of the waterfall process is that it allows for departmentalization and managerial control. It is because there is a schedule that is typically set with deadlines for each stage of development and a product can proceed through the development process. In theory, this process leads to the project being delivered on time because each phase has been planned in detail.

Each phases…

Requirements Gathering and Analysis – this is the phase where all possible system requirements to be developed are identified. System requirements are those set of functional and non-functional that the end-user expects from the system. There are tools in gathering requirements, either consultation, interviews, surveys, etc. The goal of this phase is to determine how these requirements will be accommodated in the system. There should be broad communication between the customer and the developer. Finally, a Requirement Specification document is created which serves the purpose of guideline for the next phase of the model.

Software & System Design – once all the requirements have been collected and analyzed, this time is to identify on how the system will be constructed to carry out their task. It is very important to understand what we are creating and what it should look like. The system has to be properly designed before any implementation is started. This phase is focused on the data requirements, software construction and the system interfacing. This phase also will defined the hardware and software needed. The aim of this phase is to generate a System Architecture document that serves as an input for the software design phase of the development, but also as an input for hardware design or selection activities.

Implementation – the software and system design is now translated into machine readable computer codes. Once the system design documents are done, the work is said to be divided in modules/units and coding is started. Different high level programming languages like C, C++, Pascal, Java are used for coding. Each modules/units will be integrated after the coding phase will be done. There is now a unit testing to test the system functionality and verify if the modules/units meet the specifications.

Testing – In this phase the system is tested. More often than not programs are written separately by modules/units. The separate modules are brought together and tested as a complete system to check if all modules/units coordinate between each other. There is a test to ensure that interfaces between modules work, the system works on the intended platform, and that the system does what the user requires. After successfully testing the software, it is delivered to the customer.

Maintenance – this phase is said to be never ending because it is believed that problems of the system developed will arise after its practical use starts, therefore, the problems in the system will be solved after its deployment. Software will definitely undergo change once it is delivered to the customer. And since not all the time, these problems will come directly at a time; it needs to be solved whenever it will arise. And this process is so-called maintenance.

The Spiral Model

The Spiral Model is inspired by the Waterfall Model and Prototyping Models. This model is simply designed to include best features that the two models has, and of course to enhance and introduce new features that can be used to design a good system. The term spiral is used to describe the process that is followed as the development of the system takes place. Like the Prototyping Model, primary version of the system is developed, and then repeatedly customized based on input received from customer evaluations. However, unlike the Prototyping Model, the development of each version of the system is carefully designed using the steps involved in the Waterfall Model. That is why this model is said to be a combination of both Prototyping and Waterfall.

Like a spiral, the process begins at the center position in this model. It moves clockwise. And each movement of the spiral usually results in a deliverable. Though it is not clearly defined what this deliverable is, there is changes as it traverse along the development of the system. Like for example, the first traversals may result in a requirement specification. The second will result in a prototype, and the next one will result in another prototype or sample of a product, until the last traversal leads to a product which is now ready to be sold. Thus the related activities and their documentation will also establish towards the outer traversals. And since there is iteration around the spiral, increasingly more complete versions of the system are built.

Similar to the waterfall model, the spiral model has chronological cycles/stages, with each stage having to be completed before moving on to next. Primary, the difference between the waterfall model and the spiral model is that the project system development cycle moves towards eventual completion in both the models but in the spiral model the cycles go back several times over to earlier stages in a repetitive sequence.

The Rapid Application Development

Above models are helpful and successful, in response to rigid, cascading, one-way steps of Waterfall Models of development, Spiral Model is introduced. Through this model, there is a way of reducing risk. But in order to ensure high responsiveness, projects are designed with fixed timescales. Sometimes leads to sacrificing functionality if necessary. This allows the development team to focus on the pieces of functionality that have the highest business value, and deliver that functionality rapidly. That is where the Rapid Application Development or RAD takes part. The RAD methodology was developed to respond to the need to deliver systems very fast. This method has a task list and a work breakdown structure that is designed for speed. However the major difference in RAD is a set of management techniques that are optimized for speed.

Change is often the reason for delays in application development. In long development processes, changes in functionality requirements or project scope after a lot of time has cause many months to be lost and significant expense to be incurred for redesigning and redevelopment. RAD minimizes scope and requirements creep by limiting the project's exposure to change and shortening the development cycle and limiting the cost of change by incorporating it up-front before large investments are made in development and testing.

However, the RAD approach is not appropriate to all projects. Say large real-time projects on RAD would not instill much confidence. The success of a RAD approach is determined on its project scope, size and circumstances.

The structure of the RAD lifecycle as we noticed is designed to ensure that developers build the systems that the users really need. This lifecycle includes all of the activities and tasks required to scope and define business requirements and design, develop, and implement the application system that supports those requirements. Below are the four stages that RAD has:

Requirements Planning – this stage is also known as the Concept Definition Stage where defines the business functions and data subject areas that the system will support and determines the system’s scope. Like the other models, it has to list all the requirements needed for the system in order to design appropriate concepts. It consists of a review of the areas associated with the proposed system. This review produces a broad definition of the system requirements in terms of the functions the system will support.

User Design – this stage is also known as the Functional Design Stage where uses workshops to model the system’s data and processes and to build a working prototype of critical system components. It consists of a detailed analysis of the business activities related to the proposed system. Following the analysis, the design of the system is outlined. System procedures are designed, and preliminary layouts of screens are developed. The requirements being gather is now being used for designing user’s views and designing the system itself.

Construction – this stage is also known as the Development Stage where completes the construction of the physical application system, builds the conversion system, and develops user aids and implementation work plans. There is now a small team of developers, working directly with users, finalizes the design and builds the system. The construction process consists of a series of design-and-build steps in which the users have the opportunity to modify the requirements and review the resulting software implementation. Construction includes documentation and instructions necessary to operate the new application, and routines and procedures needed to put the system into operation.

Implementation – this is the last stage of the system development and is also known as the Deployment Stage, this stage includes final user testing and training, converting data, and the implementation of the application system. It also involves managing the change from the old system environment to the new one. This may include implementing bridges between existing and new systems. User acceptance is the end point of the implementation stage.

Images Sources:

For waterfall model: Image @ http://www.buzzle.com/showImage.asp?image=1449
For Spiral Model: Image @http://www.instructionaldesign.org/models/spiral_model.html
For RAD: Image @ http://www.casemaker.com/download/products/totem/rad_wp.pdf

SAD 1 - (Assignment 3)

We are done to explore the world of the information system analyst. We already know what their key roles, their traits, characteristics are and we know how these characteristics/traits are very important to be a good System Analyst. We also touched our personal traits/characteristics to justify if we can be good system analysts. We identify some of our strengths so that we can examine ourselves if we are qualified to be a good System Analyst. Having the idea on how we can see our strengths to call ourselves as System Analyst, we easily pin-point different characteristics/traits that can be used in the near future as we, our very own selves will have to join the world of the information system analyst. And to validate those characters/traits that we are able to identify for ourselves, we are tasked to look for a System Analyst on practice and do an interview on what would be the skills and characteristics must a system analyst develop in order to be more effective in any design modeling process. This time, what we have learned during the sharing and presentation was validated as we throw some follow-up questions that will help us to understand more on what a System Analysts really does, I mean his skills to possess and you know characteristics.

Aside from asking his skills and characteristics, we also tackle the role of a system analyst as a project manager since this time, we’ll going to identify the role of system analyst as a project manager.

The interviewee stressed out that the role of a System Analyst is really different from a Project Manager. But there’s an exemption, because sometimes or most of the time a System Analyst is at the same time the Project Manager in doing a project.
While we are done to identify the roles/traits/characteristics/skills of a System Analyst, below are the roles of the Project Manager based on our conducted interview.
The Project Manager is the one who do the talking. According to the interviewee, the Project Manager is the one who will talk to the client at the start of doing the project. He is the one to explain it to the client on what are the team agreements in doing the project. In short, at the start of getting a project, Project Manager will be the representative of the team in doing oral or written agreements.

The Project Manager is the one who get the overall specifications/scope of the project. According to the interviewee, Project Manager is responsible for gathering information on the scope and specks of the project. As a Project Manager he is responsible to gather information and specifications from the client and of course from the users.

The Project Manager is the one to identify the people who will be involved in the project. It means that as a Project Manager, he/she is the one to create his own team for the development of the entire project. He/she will be the one to choose the people that he wanted to get involved in doing the project.

The Project Manager is the one to “always give the updates”. According to the interviewee, it is the Project Manager’s responsibility to always give updates on what are the progresses of the projects and it’s not the client who will get updates and follow-ups on what is happening on the current project development. The interviewee also states his opinion on the difference of Pinoy clients and US clients. He said that Pinoy clients doesn’t bring too much pressure it is because our nature is not too on getting updates with regards to the progress of the project and usually any delays are welcome for some extension dates. Say we are given a deadline on April 30, 2010, most Pinoy clients will meet the team on the deadline, and we can never hear those getting updates prior to the deadline while US clients are very strict on the time and deadlines. The interviewee shared his experiences on his US clients where he has to give updates on the project thrice a day. And it should be what you accomplished yesterday, what you are doing today and what you will be doing tomorrow.

The point here is that the Project Manager is the one to impose that a deadline is a deadline and tell the client before the deadline if the project will be extended so that the other party will not expect anything on the date of supposed completion.

The Project Manager is the one to delegate task to the team members. He is the one to set timeline to clients and to his team.

How do you describe yourself as a project manager in your information system department or organization (in general)? The interviewee answered that “once we set a certain goal, there should be completion “.

Can you site related experiences of being a project manager of a team in a certain project? How do you go along with it? The interviewee cites his experience during every general assembly of SAMULCO where he is responsible for the registration process. He did his job on it successfully in three years now. He is the in-charge of the secretariat (hardware, people, etc.). He is the one who oversee the entire event. And he said that in every project “you can learn, And I’m happy this year”.

What do you think are your strengths and weaknesses as a project manager? Strength: “I know what I want and I get what I want”. Weakness: “I do most of a time to think as a programmer”.

Evidence (photo):

SAD 1 - (Assignment 2)

Chapter 1 explores the world of the information System Analysts. And as we go deeper on the discussions, we are able to know what are the roles that a System Analyst does, what are their expected skills, characteristics, traits and qualifications. And thus, we are able to identify important traits and characteristics that we will be having considering ourselves as a System Analyst. Assignment 1 is all about what we have learned based on the discussions that we had on Chapter 1 and identifying some characteristics that we might have to possess as a good System Analyst.

Now in this Assignment 2, we are tasked to interview a System Analyst. It only means that we are going to venture on the outside experiences. After assessing our own selves as a System Analyst, we are going to get outside and look for another System Analyst. Luckily, we find Mr. James of SAMULCO.

Below is based on the two-hour interview with the SAMULCO’s MIS Department Head.

Question: What are the skills and characteristics must a System Analyst develop in order to be more effective in any design modeling process?

The interviewee answers the following skills:

1. Observant/keen to details. The interviewee believes that it is very important for an Analyst that he/she is a keen observer to avoid risk such a waste of time, resources and money. He site an example where there are system requirements that was left unnoticed at the start of the development and later found out that the missed requirements are needed in the system. There is now a need for repetition and therefore a waste of time, resources and of course money. So see how important to be a keen observer specially in identifying details on the system requirements needed.

2. Develop basic programming skills. The interviewee believes that a System Analysts must have basic programming skills. Well a System Analyst is not really expected to be an expert in programming but at least knowledgeable. It is because he/she is working with the developer and of course they should understand each other. Basically, System Analyst should get along with the developer that is why he/she needs to understand what do the developer means if they were talking about programming terms. There is also a technical knowledge so that it would be easy for both of the client and the analyst to assemble information requirements and to communicate when it comes to what the programmers is needed.

The interviewee also stressed out that the System Analyst must see the problem instead of solutions. Because in most cases, analysts see the solution first and forget what is really the problem. It is not good in a way that the analyst will sometimes imagine more being a programmer rather than being an analyst. He/she sees how the project will be look like and how it will going to functions and overlook on what do really the system needs to do. He said that a good analyst must see the problem alone to come up into a good solution.

3. System Analyst must be a global thinker. According to the interviewee, a good analyst is a global thinker. It is because he/she looks at the over-all system of the project. He’s making an example of the two men working on the empty lot, digging soil…while another man happens to stop by and asked what they were doing. The first man answered that they were digging the soil and the second man answered that they were going to build a house. See? The first man is the developer; he only sees the current situation, on what he’s currently working, very literal. While the second man is the system analyst, he sees the entire system and not only what is currently going on. The developer is very systematic while the analyst is a global thinker.

4. Communicate well both with the Project Manager and developer. Communication is very critical for a System Analyst because it is the only way to get along with the Project Manager, developer as well as the clients and users. It is important in dealing with your clients while you are going to review the necessary information that the desired system needs. The analyst must be a good communicator in both oral and written and one thing not to forget must be a good listener. He/she can listen and may able to react what might people have to say, in a careful and nice way. The interviewee believes that communication among the Project Manager and developer is very important because it is the only way to discuss what will be the project and how will it being develop. He said that good communication is very useful since in doing a project where the analyst will going to identify the requirements, it is the responsibility of the System Analyst to discuss the requirements needed for the project instead that the client will be the one to discuss what is needed. At first, I find it confusing since what I have understand is that it is the client who knows what they want the system would do but the interviewee adds that it is because the analyst is the one who knows more on what will be the project is going to be like and how it functions. Some add-ons might be given by the client after examining the list of functionalities that the analyst identified.

Question: Which specific skill/character do you need to develop most? The interviewee said that he has to develop more on being a global thinker.

Question: When and how can you apply these skills/traits/characters in relation to your job specification (in the organization/company)? Everyday, No not really everyday but when the opportunity calls he said. He also said that he will be talking to the HR, they will identify problems that need to be addressed and that’s the time that he will be talking to his buddy.

Evidence (photo):