SAD 2 Assignment 1

---

Assuming you were tapped by the university president to evaluate the new enrollment system implemented this semester, enumerate your observations/comments and suggest possible areas and ways where improvements can be made. Your observations/suggestions should be properly validated with facts and literatures...(you may start with the diagrams posted in the strategic locations of the university)...



I have been here in this university for five long years in which every start of the semester has to undergo of enrollment procedure. Never did I enroll myself that accomplish in one day time. It really a battle for every student the enrollment process of the university. Students always experience long queue in advising, cashier, registrar, book keeper, and even in encoding. We also had to experience long hours of standing because of lack availability of the facilities for chairs. Students and parents suffered a lot in his kind of process.

Yes, every year enrollment procedure changes so as to improve the system in enrollment. And yet improvements are not that visible. I know the administrator has planned for better system on enrollment to improve the current system. Also, they aim to make the enrolment process fast.

The following are the enumeration of 0my observation during the enrollment process.

• Local Council Payment Centers
During enrolment, first you have to do is to pay all the students accounts such as the local council account, Head Light, CCO and others. But as I observed sometimes our local council collectors were nowhere to be found. And with this it caused delays to every student since they were not able to undergo advising if all local payment is still unpaid.

• Incomplete Grade for Advising
This is other burden to the old student since they have to complete the grades before they have to go on advising. During enrolment, some professors are not around to comply and get the grades. Students need to complete their grade for them to be advised by the faculty in charge.

• Encoding of Subjects enroll
Encoding process is also a headache to us students. With the number of student versus one or two encoder, it takes time for us to have our COR so as to proceed to the book keeper. Sometime, there is an error on the codes and conflict with the time of some subjects.

• Paying Tuition Fees at the Cashier
The number of cahier windows available I guess is not enough to cater the number of the students enrolling. Hence, it is a wasted time for student to fall in line in a long queue.

• Registrar
This is the final destination of the student enrollee and same with the cashier’s situation it is a long line. Students reach the second floor in falling in line.

Suggestions
Enrollment is a long process to undertake of every students and I guess we need find ways that might lessen the burdens of everyone. These are my suggestion that might improve the enrollment process.
• Assigned students collector for Local Council fees. Also, they should permanent place where student can pay their fees.
• Allow students have their evaluation grade so as to complete their grades and use it for advising.
• I guess we need to add encoders during enrollment to lessen the queue.
• We also need additional cahier during enrolment for fast service.

Improvements
Yes, they have some improvements implemented during the enrollment procedure.
• Assisting the student in falling in line to the cashier and the registrar. With this, students are more disciplined and fair in service.
• They provide facilities like the tables and bleacher for the students to seat on while waiting their turns.
• As you observe the enrolment procedures posted in the wall are illustrated in a diagram. Before instructions in enrolment are written in words. Compare it today, it is easy to understand

Yes i believe the administration finds its way to better improve the enrollment procedure. THey even migarted from outsourcing to in-house in which i guess one of the best moves for improvements..

SAD- Assignment 2

Relative to your answer in Assignment 1 .... what's your take on the design of the enrollment system?

The enrollment system of our university has always been a concern of every student. Every semester it has always been a burden to students and parents most especially to the new student applicants. There are numerous steps and procedures to be under go to be enrolled. Yes, the university has changed or improved the process of the enrollment system. As you can observe during enrollment, steps of enrollment process are posted in the wall of every college. In the previous year, step or instructions for the enrollment were written in words in which sometimes misunderstood by most of the students and they even get confused. Now, just this enrollment we have observed they use the diagrams to illustrate the instruction of the enrollment.

Using and implementing diagram to illustrate the flow of the enrollment system, it adds clarity on the procedure undergo by the students during enrollment. With this it is more easier to understand and follow the procedures. But if you have to observe the diagram in enrollment procedures there some flaws and ambiguity on the process in which some might misunderstood it.

One part of the diagram that I get baffle to interpret is in the step number 5. Although I have already know the process of the enrollment but we have to consider the new student applicant. In this part of the procedure, scholar students do not need to go to cashier and must directly present their encoded subject to the student account or the book keeper but it was not presented in the diagram.

I suggest in every process or step, it must be studied and know the persons involved. With that the administration would create a better design on the enrollment process.

SAD2- Assignment 1

Assuming you were tapped by the university president to evaluate the new enrollment system implemented this semester, enumerate your observations/comments and suggest possible areas and ways where improvements can be made. Your observations/suggestions should be properly validated with facts and literatures...(you may start with the diagrams posted in the strategic locations of the university)...

I have been here in this university for five long years in which every start of the semester has to undergo of enrollment procedure. Never did I enroll myself that accomplish in one day time. It really a battle for every student the enrollment process of the university. Students always experience long queue in advising, cashier, registrar, book keeper, and even in encoding. We also had to experience long hours of standing because of lack availability of the facilities for chairs. Students and parents suffered a lot in his kind of process.

Yes, every year enrollment procedure changes so as to improve the system in enrollment. And yet improvements are not that visible. I know the administrator has planned for better system on enrollment to improve the current system. Also, they aim to make the enrolment process fast.

The following are the enumeration of 0my observation during the enrollment process.

• Local Council Payment Centers
During enrolment, first you have to do is to pay all the students accounts such as the local council account, Head Light, CCO and others. But as I observed sometimes our local council collectors were nowhere to be found. And with this it caused delays to every student since they were not able to undergo advising if all local payment is still unpaid.

• Incomplete Grade for Advising
This is other burden to the old student since they have to complete the grades before they have to go on advising. During enrolment, some professors are not around to comply and get the grades. Students need to complete their grade for them to be advised by the faculty in charge.

• Encoding of Subjects enroll
Encoding process is also a headache to us students. With the number of student versus one or two encoder, it takes time for us to have our COR so as to proceed to the book keeper. Sometime, there is an error on the codes and conflict with the time of some subjects.

• Paying Tuition Fees at the Cashier
The number of cahier windows available I guess is not enough to cater the number of the students enrolling. Hence, it is a wasted time for student to fall in line in a long queue.

• Registrar
This is the final destination of the student enrollee and same with the cashier’s situation it is a long line. Students reach the second floor in falling in line.

Suggestions
Enrollment is a long process to undertake of every students and I guess we need find ways that might lessen the burdens of everyone. These are my suggestion that might improve the enrollment process.
• Assigned students collector for Local Council fees. Also, they should permanent place where student can pay their fees.
• Allow students have their evaluation grade so as to complete their grades and use it for advising.
• I guess we need to add encoders during enrollment to lessen the queue.
• We also need additional cahier during enrolment for fast service.

Improvements
Yes, they have some improvements implemented during the enrollment procedure.
• Assisting the student in falling in line to the cashier and the registrar. With this, students are more disciplined and fair in service.
• They provide facilities like the tables and bleacher for the students to seat on while waiting their turns.
• As you observe the enrolment procedures posted in the wall are illustrated in a diagram. Before instructions in enrolment are written in words. Compare it today, it is easy to understand

Yes i believe the administration finds its way to better improve the enrollment procedure. THey even migarted from outsourcing to in-house in which i guess one of the best moves for improvements..

Assignment 12-SAD

ERP
Enterprise Resource Planning

(Enterprise Resource Planning) An integrated information system that serves all departments within an enterprise. Evolving out of the manufacturing industry, ERP implies the use of packaged software rather than proprietary software written by or for one customer. ERP modules may be able to interface with an organization's own software with varying degrees of effort, and, depending on the software, ERP modules may be alterable via the vendor's proprietary tools as well as proprietary or standard programming languages. An ERP system can include software for manufacturing, order entry, accounts receivable and payable, general ledger, purchasing, warehousing, transportation and human resources. The major ERP vendors are SAP, Oracle (PeopleSoft and J.D. Edwards), SSA Global (Baan) and Microsoft. Lawson Software specializes in back-end processing that integrates with another vendor's manufacturing system.

Rebecca Gill, vice president of Technology Group International says:

"For almost twenty years we have had people ask for demonstration copies of our ERP software, so they may play with it at their leisure. For years we have said no and we've done so with good reason. An ERP package is an advanced system. It isn't Microsoft Office and it isn't an iPhone. You can't simply turn it on and expect it to run without training."

Why ERP is Vital to Productivity and Profitability

In today’s business environment, installing an enterprise resource planning (ERP) software package and the systems needed to support it are requirements for a well-functioning enterprise. Although some organizations attempt to design and maintain a business model based on “Best Practices,” they rarely have the discipline to execute business process improvement (BPI) without an ERP software in place. Sometimes, companies attempt to create best-of-breed systems, selecting and integrating pieces of functionality to mirror the results of a single ERP package. Yet, unless you have in-house staff with the technological expertise to logically knit together disparate business systems, it’s better not to go down that path. While it’s generally understood that most manufacturing and distribution companies will eventually need an ERP system to function optimally, when evaluating solutions and their potential return-on-investment (ROI), it helps to truly understand how an ERP system contributes to both productivity and profitability.

S A P

For successful SAP ERP implementations past go-live, involve business side
By Courtney Bjorlin, News Editor 19 Jan 2009 | SearchSAP.com

Successful SAP ERP implementations hinge on getting the business side involved not only during the project but long after go-live, according to SAP customers. Making sure business ownership is within business units, not the technology teams, and including the business side in training and ERP-related business process improvements will help ensure success, according to David Edwards, divisional vice president of business transformation at Coldwater Creek. The women's clothing and accessories retailer is currently completing an SAP ERP implementation that includes financials, human resources, merchandise management, sales order management and sales audit functionality. Ignoring the business side during the implementation would have been a fatal flaw, Edwards said.
"[It's] the biggest mistake I've seen in 24 years. This is not a tech project, it's not an IT thing. It is a business, moving-needle thing," said Edwards, who was one of four SAP retail customers who spoke about their SAP projects at the National Retail Federation expo in New York last week. "The lesson I would pass on to people is treat it that way."
Stick to governance model Other retailers agree. Sticking to a strict governance model will help ensure that the project aligns with, and meets, its initial ERP business drivers, according to John Baldino, senior director of business transformation at Wawa Inc. The primary business drivers for the Pennsylvania-based grocery store chain were increasing its revenue, improving category management and getting a centralized view of what's in hundreds of its stores. To make sure Wawa met its goal during its ERP implementation, there was a role on the project organization chart called "benefit realization." This was a finance person who worked with the project team to validate that decisions were consistent with the business case benefits that Wawa expected, Baldino said. During the project, Baldino and the ERP implementation team were in front of the board of directors every six months to talk about project status and how it was tracking to its timeline. They also met monthly with executives. And even though they finished the implementation project at the end of last year, they're still in front of the board twice a year to discuss where to make ERP-related business process changes, he said. One of the benefits Wawa realized right off the bat resulted from developing a direct product profitability model for the food service area. Now, Baldino said, Wawa can figure out whether the products it's putting in its delis are making any money. Business team involvement critical But when the project was complete, Baldino thought they made a mistake by not making the business team part of post go-live monitoring. Now, they're working with the business side every day to figure out ways to leverage the system to get more value out of it, not only with individual functions but across all functions. In the last 12 months, they've been focusing on building up a lot of data inside the SAP system in order to do store clustering and efficient item assortment. Business involvement has been a critical success factor. "[It's] business ownership while it's a program and you're implementing it, but post the go-live ... the business can't walk away," he said. "Those 100 people that worked on this SAP project had to go back into their business areas and now become the change agents for how to use and leverage SAP to get more out of it. We kind of patted them on the back … and we left them alone, which I think was a mistake for us. Now we're … getting back more into staying in touch." Other retailers reiterate that collaboration is key, which means drawing on IT's implementation experience to scope and deliver a project that meets business requirements in a timely, cost-effective way. For Hastens and Reliance Retail, a successful SAP implementation meant getting the systems up and running quickly, and that involved avoiding the temptation to customize the SAP software too much. "We just want to run best practices," said Dominic Luzi, CIO of Hastens, a Swedish luxury bed company. "So our implementation was all best-practices based, very quick. We changed the business rather than the software." No hard line between business, IT Reliance Retail, a retailer that serves India, relied on management to keep it on track, CIO Timothy Kasbe said. "It's been the leadership saying, 'Not too many customizations,' and sticking to it," he said. "For the sake of speed, there wasn't a hard line between business and IT. Some of the business things, my guys just did -- commercial-oriented work, we just went and did it." With its SAP ERP implementation, Reliance Retail has been able to derive a very different kind of ROI as it enables more farmers to sell goods. Reliance's goal is to build up the distribution and the supply chain of India -- enabling communities to take part in rapidly evolving markets. "What we have seen is that suicide rates have gone down in the farming communities when these rollouts have happened, and they have been able to sell to us and also buy some of our products," Kasbe said. "It's really a different scale and different way we look at this whole business issue."

Top manufacturing ERP best practices for project planning
11 Dec 2009 | Catherine LaCroix, Contributor

When it comes to manufacturing ERP, there are a number of best practices that are key to a successful implementation. These include picking the right project team, an open mind, time to migrate data, training, data management know-how and a process for continuous improvement. 1. Pick the right project team. Be sure to include members from relevant business operations as well as Information Technology. This cross-functional team will greatly improve decision-making as you design, implement and manage ERP system across multiple sites, said Simon Jacobson, research director at AMR Research. 2. Be open to new processes. During ERP planning for a roll out, companies often believe that how they set up accounts receivable or schedule their factory floor is absolutely critical to the way they do business. They think that they must have the same setup in ERP as they had before. No so, according to Bob Parker, group vice president for research at IDC Manufacturing Insights. "Don't fall in love with your own processes," he warned. 3. Schedule enough time to migrate your data to the new system. Where projects get behind most often is in the process of mapping the existing system to the new system, said Parker. You also need to build in time to scrub the data to make sure it's accurate before migration. This is an area that almost always takes longer than people think. 4. Budget generously for training over the long term. What typically happens in ERP planning is that there is a lot of training at the implementation stage. But when personnel changes, new employees don't get nearly the same level of attention and support. Make sure you've got plans that cover training not just at the front end, but throughout the lifecycle of the new system. 5. Understand that the value of ERP is in the aggregation of the information. At the end of the day your executives and knowledge workers are going to get value out of using the information not how it's produced. When you think about rolling out ERP, think about what sorts of decisions are going to be made and give that more of a priority than the production of the information itself. 6. Create center of excellence. What tends to happen in most ERP planning is that business and IT work hard at the outset but neglect to ask how the ERP will meet goals for the long term. That question needs be considered, according to Parker. One solution to this common oversight is putting a support organization in place -- sometimes called a center of excellence -- to track how a system is actually used after implementation and then make recommendations for continuous improvement.



How to avoid manufacturing ERP implementation failures
17 Dec 2009 | Catherine LaCroix, Contributor

To avoid costly manufacturing ERP implementation failures, companies need to plan for five critical areas lacking in most stand-alone ERP manufacturing systems: data modeling, specialized functionality, the user interface, data integration and customization, said Scott Jacobson, research director at AMR Research. "The challenge that companies face is that when they try to extend ERP into manufacturing they realize that one single data model from ERP can't support all those individual lines," Jacobson said. That's because manufacturing applications are designed for specific manufacturing styles, scenarios and environments. ERP implementation failures often occur when manufacturers are running a mixed environment and the ERP application can't handle multiple diverse lines -- such as metal stamping, high-speed data capture and a more manual job shop are some examples Here are five issues manufacturers need to watch in order to steer clear of ERP failures:
1. Data modeling. The data model of an ERP application is very materials and cost focused. It's very difficult to model more of the complex processes like exception handling or corrective action. 2. Functionality. ERP applications are focused on the mass market. That means ERP vendors can't afford to add specialized manufacturing functionality unless it's for a really large company. 3. User interface. The typical ERP user interface is complex and forms-heavy while "the actual factory operator is not the most computer savvy," Jacobson said. It is better for manufacturers to develop a simpler UI so users will spend less time entering information. 4. Data integration. There's really no automated data collection integration in ERP systems so manufacturers will need complex scripting and an interface to perform simple data collection tasks. These need to synchronize with other processes in the plant. 5. Implementation and customization. Companies that want to extend ERP into the shop floor must realize that their current deployment could be flawed in terms of how it's blueprinted to handle manufacturing. Solving this problem could lead to a costly customization or a re-implementation.


resources:
http://www.gordiantransformationpartners.com/upload/pdf/ERP%20is%20a%20Tool,%20Not%20a%20Solution.pdf
http://www.ctsguides.com/why-buy-erp.asp
http://www.pcmag.com/encyclopedia_term/0,2542,t=ERP&i=42727,00.asp
SAP
http://searchsap.techtarget.com/news/a
http://searchmanufacturingerp.techtarget.com/generic/0,295582,sid193_gci1376706_mem1,00.htmlrticle

systems development models

Identify and discuss at least 3 systems development models .. discuss each phases ... (at least 3000 words)


System Development Models or System Process Models

What is a software process model?
A software process model is an abstract representation of a software process. Each process model represents a process from a particular perspective so only to provide partial information about the process. Models, by their very nature, are simplifications, so a software process model is an abstraction of the actual process which is being described. Process models may include activities which are part of the software process, software products and the roles of the people involved in software engineering.

Software development activities

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.

Traditional Process Model Software

Waterfall Model

The Waterfall model is one of the most used model of 70’s. It was proposed by Royce in 1970 as an alternative to Build and Fix software development method in which code was written and debugged. System was not formally designed and there was no way to check the quality criteria.

This takes the fundamental process activities of specification, development, validation and evolution and represents them as separate process such as requirements specification, software design, implementation, testing and so on.
This model, known as the waterfall, is an approach to development that emphasizes completing a phase of the development before proceeding to the next phase. In conjunction with certain phase completions, a baseline is established that "freezes" the products of the development at that point. If a need is identified to change these products, a formal change process is followed to make the change. The graphic representation of these phases in software development resembles the downward flow of a waterfall.

The principal stages of the model map onto fundamental developmental activities:

Requirements analysis and definition

The system’s services, constraints and goals are established by consultation with system users. They are then defined in detail and serve as system specification.

Requirements analysis phase focuses on understanding the problem domain and representing the requirements in a form which are understandable by all the stakeholders of the project i.e. analyst, user, programmer, tester etc. The output of this stage is a document called Requirements Specification Document (RSD) or Software Requirements Specification (SRS). All the successive stages of software life cycle are dependent on this stage as SRS produced here is used in all the other stages of the software lifecycle.

System and Software Design

The system design process partitions the requirements to either hardware or software systems. It establishes overall system architecture. Software design involves identifying and describing the fundamental software system abstractions and their relationship.
System design phase translates the SRS into the design document which depicts the overall modular structure of the program and the interaction between these modules. This phase focuses on the high level design and low level design of the software. High level design describes the main components of software and their externals and internals. Low level design focuses on transforming the high level design into a more detailed level in terms of a algorithms used, data structures used etc.

Implementation and Unit Testing

During this stage, the software design is realized as a set of programs or program units. Unit testing involves verifying that each unit meets its specification.

Implementation phase transforms the low level design part of software design description into a working software product by writing the code.

Testing phase is responsible for testing the code written during implementation phase. This phase can be broadly divided into unit testing (tests individual modules), integration testing (tests groups of interrelated modules) and system testing (testing of system as a whole). Unit testing verifies the code against the component’s high level and low level design. It also ensures that all the statements in the code are executed at least once and branches are executed in all directions.

Additionally it also checks the correctness of the logic. Integration testing tests the inter modular interfaces and ensures that the module drivers are functionally complete and are of acceptable quality. System testing validates the product and verifies that the final product is ready to be delivered to the customers. Additionally several tests like volume tests, stress tests, performance tests etc., are also done at the system testing level.

Integration and System Testing

The individual program units or programs are integrated and tested as a complete system to ensure that the software requirements have been meet. After testing, the system software is delivered to the customer.
Operational and Maintenance
Normally (although not necessarily) this is the longest life-cycle phase. The system is installed and put into practical use. Maintenance involves correcting errors which were not discovered in earlier stages of the life cycle, improving the implementation of the system units and enhancing the system’s services as new requirements are discovered.

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.

Waterfall model problems

Inflexible partitioning of the project into distinct stages makes it difficult to respond to changing customer requirements.

Few business systems have stable requirements.

Appropriate only when the requirements are well-understood and changes will be fairly limited during the design process.

Applicability:
For large systems engineering projects where a system is developed at several sites.
Advantages and disadvantages of the Waterfall model are listed below:
Advantages
Easy to understand even by non-technical persons i.e., customers

Each phase has well defined inputs and outputs e.g., input to system design stage is Requirement Specification Document (RSD) and output is the design document.

Easy to use as software development proceeds

Each stage has well defined deliverables or milestones.

Helps the project manager in proper planning of the project

Disadvantages

The biggest drawback of Waterfall model is that it does not support iteration. Software development on the other hand is iterative i.e., while designing activities are being carried out, new requirements can come up. Similarly while product is being coded, new design and requirement problems can come up.

Another disadvantage of Waterfall model is that it is sequential in nature. One cannot start with a stage till preceding stage is completed e.g., one cannot start with the system design till all the requirements are understood and represented.

Users have little interaction with the project team. Their feedback is not taken during development.

Customer gets opportunity to review the product very late in life cycle because the working version of product is available very late in software development life cycle.

Model is very rigid because output of each phase is prerequisite for successive stage.

The Waterfall model also has difficulty in accommodating changes in the product after the development process starts.

Amount of documentation produced is very high.

The model in no way supports delivery of system in pieces.

The model is not suitable for new projects because of uncertainty in the specifications.

Incremental Model

The incremental model divides the product into builds, where sections of the project are created and tested separately. This approach will likely find errors in user requirements quickly, since user feedback is solicited for each stage and because code is tested sooner after it's written.
The incremental model performs the waterfall in overlapping sections attempting to compensate for the length of waterfall model projects by producing usable functionality earlier. This may involve a complete upfront set of requirements that are implemented in a series of small projects. As an alternative, a project using the incremental model may start with general objectives. Then some portion of these objectives is defined as requirements and is implemented, followed by the next portion of the objectives until all objectives are implemented. But, use of general objectives rather than complete requirements can be uncomfortable for management. Because some modules will be completed long before others, well-defined interfaces are required. Also, formal reviews and audits are more difficult to implement on increments than on a complete system. Finally, there can be a tendency to push difficult problems to the future to demonstrate early success to management.

Incremental development advantages
1.Customer value can be delivered with each increment so system functionality is available earlier.
2.Early increments act as a prototype to help elicit requirements for later increments.
3.Lower risk of overall project failure.
4.The highest priority system services tend to receive the most testing.

Advantages

As product is to be delivered in parts, total cost of project is distributed.

Limited number of persons can be put on project because work is to be delivered in parts.

As development activities for next release and use of early version of product is done simultaneously, if found errors can be corrected.

Customers or end users get the chance to see the useful functionality early in the software development life cycle.

As a result of end user’s feedback requirements for successive releases become clearer.

As functionality is incremented in steps, testing also becomes easy.

Risk of failure of a product is decreased as users start using the product early.

Disadvantages

As product is delivered in parts, total development cost is higher.

Well defined interfaces are required to connect modules developed with each phase.

The model requires well defined project planning schedule to distribute the work properly.

Testing of modules also results into overhead and increased cost.


Spiral Model

The spiral model emphasizes the need to go back and reiterate earlier stages a number of times as the project progresses. It's actually a series of short waterfall cycles, each producing an early prototype representing a part of the entire project. This approach helps demonstrate a proof of concept early in the cycle, and it more accurately reflects the disorderly, even chaotic evolution of technology.
The incremental model can be viewed as a spiral model. The spiral view illustrates one strength of the incremental model: resources can be held constant but the system size grows. The spiral size corresponds to system size, while the distance between the coils of the spiral indicates resources. In Figure 3, the distance between the coils does not change, which indicates that the amount of the resources being used is not changing.

Each loop in the spiral represents a phase of the software process. Thus, the innermost loop might be concerned with system feasibility, the next loop with system requirements definition, the next loop with system design and so on.


Each loop in the spiral is split into four sectors:

Objective Setting

Specific objectives for that phase of the project are defined. Constraints on the process and the product are identified and a detailed management plan is drawn up. Project risks are identified. Alternative strategies, depending on these risks, may be planned.

Risk Assessment and Reduction

For each of the identified projects risks, a detailed analysis is carried out. Steps are taken to reduce the risks. For example, if there is a risk that the requirements are inappropriate, a prototype system may be developed.

Development and Validation

After risks evaluation, a development model for the system is then chosen. For example, if the user interface risks are dominant, an appropriate development model might be evolutionary prototyping. If safety risks are the main consideration, development based on formal transformations may be the most appropriate and so on. The waterfall model may be the most appropriate development if the main identified risk is sub-system integration.

Planning

The project is reviewed and a decision made whether to continue with a further loop of the spiral. If it is decided to continue, plans are drawn up for the next phase of the project.
The important distinction between the spiral model and the other software process models is the explicit consideration of risk on the spiral model. Informally, risk is simply something which can go wrong.
A cycle of the spiral begins by elaborating objectives such as performance, functionality, etc. Alternative ways of achieving these objectives and the constraints imposed on each of these alternatives are then enumerated. Each alternative is assessed against each objective. This is usually results in the identification of the sources of projects risk.
The next step is to evaluate these risks by activities such as more detailed analysis, prototyping, simulation, etc. Once risks have been assessed, some development is carried out and this is followed by a planning activity for the next phase of the process.
There are no fixed phases such as specification or design in the spiral model. The spiral model encompasses other process models. Prototyping may be used in one spiral to resolve requirements uncertainties and hence reduce risks. This may be followed by a conventional waterfall development. Formal transformation may be used to develop those parts of the system with security requirements.

Advantages

The model tries to resolve all possible risks involved in the project starting with the highest risk.

End users get a chance to see the product early in life cycle.

With each phase as product is refined after customer feedback, the model ensures a good quality product.

The model makes use of techniques like reuse, prototyping and component based design.

Disadvantages

The model requires expertise in risk management and excellent management skills.

The model is not suitable for small projects as cost of risk analysis may exceed the actual cost of the project.

Different persons involved in the project may find it complex to use.


Spiral model is generally used for large projects with medium to high risk because in small projects it is possible that cost of risk analysis may exceed the actual cost of project. In other words, Spiral model is a practical approach for solving large scale software development related problems.

This can also be used if requirements of the project are very complex or if the company is planning to introduce new technologies. Some areas where Spiral model is successfully used are decision support system, defense, aerospace and large business projects.

role of system analyst as project manager

Discuss the role of a systems analyst as a project manager. (at least one thousand words) .... you need to interview an analyst/project manager ..


Discuss the role of system analyst as project manager.

Role of System Analyst

The system analyst is the person (or persons) who guides through the development of an information system. In performing these tasks the analyst must always match the information system objectives with the goals of the organization.

Role of System Analyst differs from organization to organization. Most common responsibilities of System Analyst are following:

1) System analysis

It includes system's study in order to get facts about business activity. It is about getting information and determining requirements. Here the responsibility includes only requirement determination, not the design of the system.

2) System analysis and design:

Here apart from the analysis work, Analyst is also responsible for the designing of the new system/application.

3) Systems analysis, design, and programming:

Here Analyst is also required to perform as a programmer, where he actually writes the code to implement the design of the proposed application.


Due to the various responsibilities that a system analyst requires to handle, he has to be multifaceted person with varied skills required at various stages of the life cycle. In addition to the technical know-how of the information system development a system analyst should also have the following knowledge.

Business knowledge:
As the analyst might have to develop any kind of a business system, he should be familiar with the general functioning of all kind of businesses.

Interpersonal skills:
Such skills are required at various stages of development process for interacting with the users and extracting the requirements out of them

Problem solving skills:
A system analyst should have enough problem solving skills for defining the alternate solutions to the system and also for the problems occurring at the various stages of the development process.

I have here added information about software project manager and I think it can be relate to this topic.

Software Project Manager
A Software Project Manager has many of the same skills as their counterparts in other industries. Beyond the skills normally associated with traditional project management in industries such as construction and manufacturing, a software project manager will typically have an extensive background in software development. Many software project managers hold a degree in Computer Science, Information Technology or another related field and will typically have worked in the industry as a software engineer.
In traditional project management a heavyweight, predictive methodology such as the waterfall model is often employed, but software project managers must also be skilled in more lightweight, adaptive methodologies such as DSDM, SCRUM and XP. These project management methodologies are based on the uncertainty of developing a new software system and advocate smaller, incremental development cycles. These incremental or iterative cycles are time boxed (constrained to a known period of time, typically from one to four weeks) and produce a working subset of the entire system deliverable at the end of each iteration. The increasing adoption of lightweight approaches is due largely to the fact that software requirements are very susceptible to change, and it is extremely difficult to illuminate all the potential requirements in a single project phase before the software development commences.
The software project manager is also expected to be familiar with the Software Development Life Cycle (SDLC). This may require in depth knowledge of requirements solicitation, application development, logical and physical database design and networking. This knowledge is typically the result of the aforementioned education and experience. There is not a widely accepted certification for software project managers, but many will hold the PMP designation offered by the Project Management Institute or an advanced degree in project management, such as a MSPM or other graduate degree in technology management.


What does the project manager do?

A project manager is a professional in the field of project management. Project managers can have the responsibility of the planning, execution, and closing of any project, typically relating to construction industry, architecture, computer networking, telecommunications or software development.

A project manager is the person accountable for accomplishing the stated project objectives. Key project management responsibilities include creating clear and attainable project objectives, building the project requirements, and managing the triple constraint for projects, which are; cost, time, and quality (also known as scope).

A project manager is often a client representative and has to determine and implement the exact needs of the client, based on knowledge of the firm they are representing. The ability to adapt to the various internal procedures of the contracting party, and to form close links with the nominated representatives, is essential in ensuring that the key issues of cost, time, quality and above all, client satisfaction, can be realized.

Below are the common responsibilities of a project manager:
• Developing the project plan
• Managing the project stakeholders
• Managing the project team
• Managing the project risk
• Managing the project schedule
• Managing the project budget
• Managing the project conflicts

Characteristics of a Project Manager

First and foremost they like managing projects. Managing projects is not something people are neutral about. They either like it or they don't. Why would anyone want to do a job in which you can all too obviously fail spectacularly and if you succeed people will shrug their shoulders and say you just did your job? Others relish the challenge and like the feeling of accomplishment, of getting something done that may not have happened without them.

Good project managers:

• manage rather than co-ordinate, preside or spectate
• are natural planners
• don't like surprises, so they plan thoroughly to try to prevent them
• are effective fire-fighters - when the inevitable surprises do occur they sort them out quickly and decisively
• reward and punish - not dealing with someone who isn't pulling their weight can destroy team morale
• are good motivators, good team builders
• address conflict rather than leaving things to fester
• do not hide in an office, they walk around and ideally sit physically in the middle of the team so they are approachable
• get consensus whenever possible but dictate when necessary


Most of all, good project managers MANAGE. They do not just get swept along by the current. They grab the project by the scruff of the neck and manage it.
However, it is sometimes the case that project managers do not feel sufficiently empowered to manage and control the things/people they need to manage and control in order to be successful. This problem has a solution.

--interview—
For this topic I still adopt our last interview with the two of system analyst of EMCOR Bajada. In which, they were able to discuss about their role in the company. They were able to share to us some of their responsibilities. And it really not easy to an analyst in whom sometimes they do multitasking, one person does all duties. According to the them, the project manager has to be careful in every decision he does. Every project that he manages must be supervised. He needs to have constant communication with the team involves of the project. Leadership skill is important to a project manager that should possess, because working with a project especially in huge project is created by a team who has its own task.



references:
http://www.statefarm.com/about/careers/it/it_careers/proj_manager.htm
http://misallabouts.blogspot.com/2009/12/systems-analyst-as-project-manager.html
http://www.processimpact.com/articles/be_analyst.pdf

skills and characteristics of a systems analyst

nterview a Systems Analyst and ask what skills and characteristics must a systems analyst develop in order to be more effective in any design modeling process [include in your answer evidences (pix, ltrs, etc)]? at least 2000 words excluding your evidences.


Interview
I had interviewed a system analyst twice. It was way back last semester that I had met the system analyst of EMCOR.

EMCOR is one of the fast-growing companies here in the Philippines. In the world of business, they have to be in the competitive edge, with this they employ technologies in their operation so not to be left behind. I have always chosen EMCOR as a subject to my assignments and reports. They have opened their company to us student who would like to know more in our field in the real scenario. It is nice to know that they are happy to share their knowledge and some information about their company. I never felt to be an interruption to them every time I asked for an interview. Never did they reject us, but instead they have so accommodating.

So much for that, fortunately for the second time around, I had our interview again by their system analyst. With that I have able to gather information about his filed of work and also I have the idea to answer this assignment. (joke)

As what had he impart to us they just like liaison, he is the link of the end-users and the developers/programmers. Because analyst is the one who write user request into technical specification. He is the link between the users and the IT professionals. He needs to know the business operation and activities.

He has different tasks portrays in the company. He is the one who interacts with the users to know their requirements and also to the designers of the project for them to be able to convey the possible interface of the software. The company’s coders and developers are guided and interacted by him during the development of the software. He performs the testing of the system and it is with a live data. He also prepares documentation of the system.

According to the analyst that I had interviewed, he needs lots of patience with the end users who do the request in which sometimes changes occur. During the design modeling, the analyst needs to inline it with the end-users needs and requirement. He has to insure that the interface design of the software is a user friendly environment and looks. He must be creative in a way he will able to create an interface that fits the functionality of the software.


System Analyst

A systems analyst is a business professional that uses analysis and design techniques to solve business problems using information technology and is responsible for researching, planning, coordinating and recommending software and system choices to meet an organization's business requirements. The systems analyst plays a vital role in the systems development process. A successful systems analyst must acquire four skills: analytical, technical, managerial, and interpersonal. Analytical skills enable systems analysts to understand the organization and its functions, which helps him/her to identify opportunities and to analyze and solve problems. Technical skills help systems analysts understand the potential and the limitations of information technology. The systems analyst must be able to work with various programming languages, operating systems, and computer hardware platforms. Management skills help systems analysts manage projects, resources, risk, and change. Interpersonal skills help systems analysts work with end users as well as with analysts, programmers, and other systems professionals.

What skills analyst should acquire?
Analytical skills
Analytical skill is the ability to visualize, articulate, and solve complex problems and concepts, and make decisions that make sense based on available information. Such skills include demonstration of the ability to apply logical thinking to gathering and analyzing information, designing and testing solutions to problems, and formulating plans.
To test for analytical skills one might be asked to look for inconsistencies in an advertisement, put a series of events in the proper order, or critically read an essay. Usually standardized tests and interviews include an analytical section that requires the examine to use their logic to pick apart a problem and come up with a solution.
Although there is no question that analytical skills are essential, other skills are equally required as well. For instance in systems analysis the systems analyst should focus on four sets of analytical skills: systems thinking, organizational knowledge, problem identification, and problem analyzing and solving.
It also includes the way we describe a problem and subsequently finding out the solutions.

Management Skills

Management in all business and human organization activity is simply the act of getting people together to accomplish desired goals and objectives. Management comprises planning, organizing, staffing, leading or directing, and controlling an organization (a group of one or more people or entities) or effort for the purpose of accomplishing a goal. Resourcing encompasses the deployment and manipulation of human resources, financial resources, technological resources, and natural resources.
Management can also refer to the person or people who perform the act(s) of management

Interpersonal Skills

"Interpersonal skills" refers to mental and communicative algorithms applied during social communications and interaction to reach certain effects or results. The term "interpersonal skills" is used often in business contexts to refer to the measure of a person's ability to operate within business organizations through social communication and interactions. Interpersonal skills are how people relate to one another.
As an illustration, it is generally understood that communicating respect for other people or professionals within will enable one to reduce conflict and increase participation or assistance in obtaining information or completing tasks. For instance, to interrupt someone who is currently preoccupied with the task of obtaining information needed immediately, it is recommended that a professional use a deferential approach with language such as, "Excuse me, are you busy? I have an urgent matter to discuss with you if you have the time at the moment." This allows the receiving professional to make their own judgment regarding the importance of their current task versus entering into a discussion with their colleague. While it is generally understood that interrupting someone with an "urgent" request will often take priority, allowing the receiver of the message to judge independently the request and agree to further interaction will likely result in a higher quality interaction. Following these kinds of heuristics to achieve better professional results generally results in a professional being ranked as one with 'good interpersonal skills.' Often these evaluations occur in formal and informal settings.
Having positive interpersonal skills increases the productivity in the organization since the number of conflicts is reduced. In informal situations, it allows communication to be easy and comfortable. People with good interpersonal skills can generally control the feelings that emerge in difficult situations and respond appropriately, instead of being overwhelmed by emotion.

What does a computer systems analyst do?

Computer systems analyst is a blanket term for a computer professional that solves computer issues and uses technology to meet the needs of the company. These professionals might be employed under different titles: IT consultant, IT specialist, programmer analyst, business systems analyst, system architect and computer specialist, to name a few. These highly-trained professionals plan, design and expand new computer systems as well as configure software and hardware. They update/upgrade current computer systems and modify them for new or expanded functions. They are frequently charged with preparing cost reports for management.
Computer systems analysts usually collaborate with other professionals in the information technology field, such as programmers, network security specialists, and software engineers, and will sometimes specialize in specific systems such as accounting, business, engineering, financial, or scientific systems. Click here to find out how to become a computer systems analyst.

What kind of training does a computer systems analyst need?

Computer systems analysts are typically required to have a degree of at least bachelor level. Many employers may require a higher graduate level degree, as well as experience in the field for more complicated jobs and senior-level positions. Computer systems analysts have many different degrees, but typically, they have degrees in computer science, information technology, and management information systems. Click here to get a list of programs to get your management information systems degree online.
Qualifications vary by employer, but general qualifications include: broad computer systems knowledge, experience in employer’s field, specific computer system knowledge, logical thinking skills, great communication and interpersonal skills, and sound problem-solving and analytical skills. Internships are appropriate for students ready to graduate, as they do not usually require any experience.

What does a system analyst really do?

I had also read an article about a system analyst, she narrate her life during her two years of career. With that she gave me an idea of what does analyst do on his job. She received a job offer from a large petroleum company during her senior year in college. Her first assignment was on a development team to replace the entire accounting and operating system for the company. There were 70 people on the project, divided into various sub-groups based on business functions, such as accounts receivable, inventory control, accounts payable, general ledger, chart-of-accounts, etc. In this team, she worked on the inventory control subsystem. But she does other duties; she was the data dictionary coordinator. That meant that as project teams started identifying new data items, she had to give them a valid name and enter it into the dictionary. She also provided reports for the database design team who had to logically order all these data fields.

She is also the security request coordinator. Every time someone wanted access to a data set, she had to verify that they have a legitimate need to either read or read/write to a dataset. Fortunately, she passed the paperwork to the Security Administrator.
Her two years as a systems analyst for her were very exciting. In which she spent most of my time talking with users to understand the business and to other analysts to ensure compatibility between subsystems. She did a lot of design work, and created documentation for these designs, including reports, input forms, and programming specifications. She coded some of the programs myself (in COBOL and PL/1). For her 2 year of a system analyst was full of challenges in which she face it with chin high. She is able to adjust herself to people she interacts with.

--evidence--