♥GREEN♥

_SAD 1: Assignment # 12_

2010-06-10T17:48:00.000-07:00

What is ERP?

Enterprise resource planning software, or ERP, doesn’t live up to its acronym. Forget about planning—it doesn’t do much of that—and forget about resource, a throwaway term. But remember the enterprise part. This is ERP’s true ambition. It attempts to integrate all departments and functions across a company onto a single computer system that can serve all those different departments’ particular needs.

That is a tall order, building a single software program that serves the needs of people in finance as well as it does the people in human resources and in the warehouse. Each of those departments typically has its own computer system optimized for the particular ways that the department does its work. But ERP combines them all together into a single, integrated software program that runs off a single database so that the various departments can more easily share information and communicate with each other.

That integrated approach can have a tremendous payback if companies install the software correctly.

Take a customer order, for example. Typically, when a customer places an order, that order begins a mostly paper-based journey from in-basket to in-basket around the company, often being keyed and rekeyed into different departments’ computer systems along the way. All that lounging around in in-baskets causes delays and lost orders, and all the keying into different computer systems invites errors. Meanwhile, no one in the company truly knows what the status of the order is at any given point because there is no way for the finance department, for example, to get into the warehouse’s computer system to see whether the item has been shipped. "You’ll have to call the warehouse" is the familiar refrain heard by frustrated customers.

ERP vanquishes the old standalone computer systems in finance, HR, manufacturing and the warehouse, and replaces them with a single unified software program divided into software modules that roughly approximate the old standalone systems. Finance, manufacturing and the warehouse all still get their own software, except now the software is linked together so that someone in finance can look into the warehouse software to see if an order has been shipped. Most vendors’ ERP software is flexible enough that you can install some modules without buying the whole package. Many companies, for example, will just install an ERP finance or HR module and leave the rest of the functions for another day.

How can ERP improve a company’s business performance?

ERP’s best hope for demonstrating value is as a sort of battering ram for improving the way your company takes a customer order and processes it into an invoice and revenue—otherwise known as the order fulfillment process. That is why ERP is often referred to as back-office software. It doesn’t handle the up-front selling process (although most ERP vendors have developed CRM software or acquired pure-play CRM providers that can do this); rather, ERP takes a customer order and provides a software road map for automating the different steps along the path to fulfilling it. When a customer service representative enters a customer order into an ERP system, he has all the information necessary to complete the order (the customer’s credit rating and order history from the finance module, the company’s inventory levels from the warehouse module and the shipping dock’s trucking schedule from the logistics module, for example).

People in these different departments all see the same information and can update it. When one department finishes with the order it is automatically routed via the ERP system to the next department. To find out where the order is at any point, you need only log in to the ERP system and track it down. With luck, the order process moves like a bolt of lightning through the organization, and customers get their orders faster and with fewer errors than before. ERP can apply that same magic to the other major business processes, such as employee benefits or financial reporting.

That process may not have been efficient, but it was simple. Finance did its job, the warehouse did its job, and if anything went wrong outside of the department’s walls, it was somebody else’s problem. Not anymore. With ERP, the customer service representatives are no longer just typists entering someone’s name into a computer and hitting the return key. The ERP screen makes them businesspeople. It flickers with the customer’s credit rating from the finance department and the product inventory levels from the warehouse. Will the customer pay on time? Will we be able to ship the order on time? These are decisions that customer service representatives have never had to make before, and the answers affect the customer and every other department in the company. But it’s not just the customer service representatives who have to wake up. People in the warehouse who used to keep inventory in their heads or on scraps of paper now need to put that information online. If they don’t, customer service reps will see low inventory levels on their screens and tell customers that their requested item is not in stock. Accountability, responsibility and communication have never been tested like this before.

There are five major reasons why companies undertake ERP.

Integrate financial information—As the CEO tries to understand the company’s overall performance, he may find many different versions of the truth. Finance has its own set of revenue numbers, sales has another version, and the different business units may each have their own version of how much they contributed to revenues. ERP creates a single version of the truth that cannot be questioned because everyone is using the same system.
Integrate customer order information—ERP systems can become the place where the customer order lives from the time a customer service representative receives it until the loading dock ships the merchandise and finance sends an invoice. By having this information in one software system, rather than scattered among many different systems that can’t communicate with one another, companies can keep track of orders more easily, and coordinate manufacturing, inventory and shipping among many different locations at the same time.
Standardize and speed up manufacturing processes—Manufacturing companies—especially those with an appetite for mergers and acquisitions—often find that multiple business units across the company make the same widget using different methods and computer systems. ERP systems come with standard methods for automating some of the steps of a manufacturing process. Standardizing those processes and using a single, integrated computer system can save time, increase productivity and reduce head count.
Reduce inventory—ERP helps the manufacturing process flow more smoothly, and it improves visibility of the order fulfillment process inside the company. That can lead to reduced inventories of the stuff used to make products (work-in-progress inventory), and it can help users better plan deliveries to customers, reducing the finished good inventory at the warehouses and shipping docks. To really improve the flow of your supply chain, you need supply chain software, but ERP helps too.
Standardize HR information—Especially in companies with multiple business units, HR may not have a unified, simple method for tracking employees’ time and communicating with them about benefits and services. ERP can fix that.

Carlisle FoodService Products, in Oklahoma, USA, is a leading manufacturer of professional grade tools and tableware for the foodservice industry. Carlisle sells over 50,000 products via a network of over 10,000 distributors to restaurants, hotels and hospitals worldwide. Since 1995, Carlisle has used LANSA to streamline procedures and increase ROI in virtually every area of its business. Manufacturing plants and distribution centers use LANSA ERP Frameworks and Carlisle's distributors have Web access using a LANSA site

Ken Zaleski, MIS director at Carlisle FoodService, says, "We were the first in our industry to offer our customers a functional and user friendly Web site. Being the first certainly provided us with a competitive advantage. The efficiency the site brings remains a major selling point today. With a small team, we can maintain a system used by internal users, remote sales representative offices and distributors worldwide."

Carlisle FoodService Products is part of Carlisle Companies Incorporated, a diversified global manufacturing company headquartered in Charlotte, North Carolina, USA, that serves the construction material, commercial roofing, specialty tire and wheel, power transmission, heavy-duty brake and friction, foodservice, data transmission and process systems industries. Carlisle FoodService Products has U.S. distribution centers at Oklahoma City in Oklahoma, Charlotte in North Carolina, Reno in Nevada and a distribution center in the Netherlands to serve Europe. It has manufacturing plants at Oklahoma City in Oklahoma, Atlanta in Georgia and Sparta in Wisconsin, as well as Chihuahua in Mexico. The LANSA-based systems integrate with LogPRO warehouse management system software. Carlisle FoodService Products uses a single iSeries model 810 for all its operational system, the Web site and for development. Carlisle's ERP system has 250 internal users, while 50 sales representative companies and 5,000 distributors use the Web site regularly.

The Challenge

The Carlisle FoodService Products story started in 1955, when Continental Plastics, a small custom molding shop in Oklahoma, created the world's first plastic Bains Marie. This was followed a few years later by the world's first commercial plastic beverage pitcher. Both innovations dramatically changed food storage and beverage transport.

In 1978, Continental Plastics joined the Carlisle Group of companies. In 1991, Continental Carlisle merged with SiLite Incorporated – a manufacturer of plastic foodservice products, giftware and decorative accessories.

Several other acquisitions and one more name change followed, but Carlisle's IT history took shape with the SiLite merger. Zaleski, who originally worked at SiLite, explains that after the merger in 1991, the AS/400, with a hybrid of MAPICS and a custom order entry system, became the corporate standard.

"However, MAPICS didn't fit the way we wanted to run our business," says Zaleski. "MAPICS was strong enough on the process side, but it didn't meet our requirements on the distribution side. We were modifying MAPICS so much that it made no sense to continue. Moreover, neither system was Year 2000 compliant, so we were looking for another solution."

Carlisle used LANSA since 1995. Initially for MAPICS modifications and extensions. They bought LANSA because for them it was far more productive than RPG and a lot easier to use than Synon.

They didn't want to go back to RPG or COBOL ever. And so they started to look around for a ERP solution that was written in LANSA.

In 1997, they saw a LANSA-based ERP solution, at the time called Garnet, which is now the LANSA ERP Frameworks. They said it was a very good match and it met their main requirements right out of the box. Because the framework was LANSA-based, it was very easy to modify and extend," says Zaleski.

Implementation started in 1998 and the ERP Frameworks is now used company wide at Carlisle's manufacturing and distribution centers in the USA and Mexico, where it integrates with LogPRO warehouse management software.

Why do ERP projects fail so often?

At its simplest level, ERP is a set of best practices for performing different duties in your company, including finance, HR, manufacturing and the warehouse. To get the most from the software, you have to get people inside your company to adopt the work methods outlined in the software. If the people in the different departments that will use ERP don’t agree that the work methods embedded in the software are better than the ones they currently use, they will resist using the software or will want IT to change the software to match the ways they currently do things. This is where ERP projects break down. Political fights break out over how—or even whether—the software will be installed. IT gets bogged down in long, expensive customization efforts to modify the ERP software to fit with powerful business barons’ wishes. Customizations make the software more unstable and harder to maintain when it finally does come to life. The horror stories you hear in the press about ERP can usually be traced to the changes the company made in the core ERP software to fit its own work methods. Because ERP covers so much of what a business does, a failure in the software can bring a company to a halt, literally.

But IT can fix the bugs pretty quickly in most cases, and besides, few big companies can avoid customizing ERP in some fashion—every business is different and is bound to have unique work methods that a vendor cannot account for when developing its software. The mistake companies make is assuming that changing people’s habits will be easier than customizing the software. It’s not. Getting people inside your company to use the software to improve the ways they do their jobs is by far the harder challenge. If your company is resistant to change, then your ERP project is more likely to fail.

One cautionary tale that came to light in 2008 illustrates that sometimes there is a big difference between what an ERP vendor promises to deliver in its software and what actually is ready for prime-time enterprise use. Trash-disposal company Waste Management announced in March 2008 that it was suing SAP, seeking the recovery of $100 million in project expenses that related to a failed ERP implementation that had started in 2005. In the complaint, Waste Management alleges that SAP executives participated in a fraudulent sales scheme and that SAP's Waste and Recycling ERP product was actually "fake software" that was still not ready for Waste Management's use by spring 2008.

The Solution

Carlisle sells almost exclusively to foodservice distributors, but also deals directly with very large restaurant chains such as Yum Brands, Pizza Hut and Wendy's.

In 2000, less than a year after implementing the LANSA ERP Frameworks, Carlisle gave its distributors and sales representatives real-time Web access to its ERP system. "The driving force was the vision of our president, Dave Shannon, who wanted us to have a Web presence that went beyond the static Web sites our competitors offered," explains Zaleski.

The initial version of the Web site of Carlisle took less than four months for the developer to develop and implement. Since then they have extensively enhanced the Web site with their own IT team.

Distributors and sales representatives worldwide can place orders, view inventory, switch from default to an alternate warehouse and trace shipping details, with a direct link to UPS and other carriers for package tracking.

Distributors can set up a cross-reference file that lets them link their own internal product numbers to Carlisle's product numbers, then work with either product number throughout the Web site. The solution also offers customer specific pricing, up to two years order history and a feature called 'My Favorites', where distributors can monitor inventory to maintain a minimum volume of inventory.

Distributors can search orders by their purchase order number, Carlisle's order number, date range, product number (either Carlisle's or their own), invoice number and order status.

Distributors are given one high-level user-id, which allows them to set up additional users with varying authorities. For example, some user types may view order and shipping information, but without the pricing.

The Benefits

Carlisle is the first industry to offer customers a functional and user-friendly Web site. Being the first certainly provided them with a competitive advantage. And the efficiency the site brings remains a major selling point today.

Carlisle don't expect distributors to key in their large orders on site. What they are offering is an efficient way to trace orders, look at inventory and view account details. However, distributors do use their site to place small emergency orders that they drop-ship directly to their customers, that way boosting their customer service. Small Web orders that are drop-shipped can also save their distributors a few days on cash flow. They can check in real time which orders have shipped and invoice their customers the same day. They can also get advance shipping notices by email, so their costumers don't even have to go online to check.

LANSA ERP keeps track of all their order, shipment and invoice history, and some of their smaller distributors even use their Web site as their purchase system. They also have several distributors who provide links on their Web site to their catalog. Their customers can see the products but don't see prices or inventory, because the ordering goes via the distributor.

The Web site also allows their representatives to better and more easily prepare for a business call to a customer. For example, if it has taken more than a week to fulfill a specific order, the representative now has the opportunity to find out before the meeting why there was a delay. And if needed he can make a call to the responsible manufacturing plant or supplier to speed things up. It is all about customer service," says Zaleski.

Conclusion

Their plan with the LANSA ERP Frameworks has always been to buy it and then take ownership of it, because they knew that they were going to modify it themselves, so there is no need for vendor maintenance.

Zaleski added that LANSA doesn't lock them into any specific platform, even though they love the iSeries. They never had to reboot the system because of problems. The box is very robust and so is LANSA. They have a planned reboot of the system once or twice a year, just to check their procedures and to restart some files.

They get about 600 orders per day, but a lot of their costumers are still coming in by fax. Next year they will have a look at offering their customers XML transacting with LANSA Integrator. They already offer EDI and several formats of file transfers, said Zaleski.

They have also offered their customers that if they enter orders on the Web site, they will send them a flat file back with the order information, so the costumer can import that information into their purchase system, without a need for additional data entry.

The LANSA ERP Frameworks and the Web extension are completely integrated. They run the same programs and use the same database. Any changes they make to the ERP system are instantly available in the Web extension as what Zaleski said.

Dennis Wallis, iSeries development manager at Carlisle FoodService Products, adds, "We now use LANSA for our PC applications that access a Microsoft SQL Server database, as well as for iSeries and Web development. We find LANSA easier to use than any other tool for the Windows, Web and iSeries development."

The company have only four developers, including Zaleski himself.. With that small team they maintain and enhance a system that is used by 250 internal users in their offices, plants and distribution centers, 50 remote sales representatives and 5,000 distributors worldwide. It testifies how LANSA's productivity and scalability.

Ref: http://www.cio.com/article/40323/ERP_Definition_and_Solutions#erp

_SAD 1: Assignment # 11_

2010-06-10T17:42:00.000-07:00

You were tasked by the IC-dean to evaluate the enrollment system of the university, list and briefly describe the characteristics that an anlayst(you) examines when choosing or defining deployment environment.

What is system deployment?
System deployment is a complex endeavor which is a critical aspect of the software development lifecycle (SDLC), an endeavor that is all but ignored by writers in favor of sexier topics such as distributed object development, components, or the latest version of an SDK. If you can't get software into the hands of your users then what is its value? Absolutely nothing.
Deployment environments
A deployment environment is a collection of configured clusters, servers, and middleware that collaborates to provide an environment to host Service Component Architecture (SCA) interactions. For example, a deployment environment might include a host for message destinations, a processor of business events, and administrative programs.
Planning deployment environments requires that you design the physical layout (topology) of the deployment environment so you can meet your business needs for capacity, availability, scalability and failover support. Some key aspects of the design involve the number and relative placement of the servers on the hardware that makes up your deployment environment.
Planning for Deployment
It isn't enough to build software—you must also deploy it, so you can operate and support it effectively once it's in production. When you're developing complex software (the kind of systems typically tackled with component-based technologies such as J2EE or .NET), your deployment efforts can be similarly complex. Therefore, whether you're building a replacement system or plowing a fresh "greenfield" development, adequate planning is essential for successful deployment.

Step by Step
First, you must identify your system's customers. The business side includes direct users of the system, along with indirect users such as managers who receive reports based on data generated by your system. With respect to deployment, your primary technical customers are the operations and support staff, two groups who clearly need to be involved with deployment planning efforts. Once you know who your customers are, you can identify what they need from the system and related artifacts, discover their potential roles in the overall deployment effort, and negotiate their actual involvement.

The next major issue is developing your deployment strategy: Will you run the new system in parallel with the existing one or perform a cutover? Running the systems alongside each other lets you easily back out to the original system if the new one runs into problems. However, parallel operations require significant effort on the part of everyone involved: Your users will need to do double entry, the operations staff must run both systems, the support staff will have two systems to support, and the development staff may need to create integration code that temporarily works behind the scenes to synchronize data. For many systems, particularly those supporting online customers via the Internet, a cutover is the only option—few customers would be willing to place their book order with both Amazon version N and Amazon version N+1. With a straight cutover, you'll need to plan for the downtime when the cutover occurs—a period that could last from a few seconds to a few hours or even a few days, depending on the system being deployed. The ability to back out becomes critical with this approach, requiring additional resources to develop and test "de-installation scripts." In fact, many system deployment efforts fail miserably because the development team didn't consider how to back out of their new system, only to discover that they had to do so because of an unforeseen problem during installation. An effective installation routine will include go and no-go checkpoints at which you determine whether deployment efforts are on time and working smoothly. If you don't have these crucial checkpoints, you need to consider stopping and de-installing to a known and safe state from which to attempt deployment at a later date. Never assume that your deployment efforts will go smoothly.

From Back to Front
Working backward is an effective technique for deployment planning. Envision the system in production—users working with it, operations professionals keeping it going, support staff helping users to work with it, and developers modifying it to address defects and implement new requirements—and ask what has to happen to get the system to that point. Then compare that vision with the current environment to determine what you must do to successfully install your system. In my experience, forward planning generally isn't sufficient for system deployment, because the requirements often don't reflect issues pertinent to your system's production phase—that is, the need to operate and support your software is often assumed and therefore not explicitly reflected in your requirements. This problem can be exacerbated when your project life cycle doesn't explicitly include a production phase or even an operations and support workflow. What is out of sight is often out of mind.

General steps for implementing a deployment environment:
After designing a deployment environment, you will perform specific tasks to make that design a reality. Regardless which method you use to implement the deployment environment, you will perform the same general steps.

Before you begin
• Plan your topology and record the decisions you make about:
o The servers and clusters involved.
o The number of databases required.
o Which database tables belong in which databases
o Any required userids and authentication roles
o What function each cluster involved in the deployment environment provides
o Which method you are using to implement the deployment environment
• Make sure the systems on which you are installing the product meet the hardware and software requirements.
Deployment Environment Characteristics to Consider

*Compatibility with system requirements
*Compatibility among hardware and system software
*Required interfaces to external systems
*Conformity with IT strategic plan and architecture plans
*Cost and schedule

Here are some tips and technique to make it successful:
Identify and understand deployment audience. There are at least three distinct groups that need to consider: end users, the operations staff responsible for running the software once it is in production, and the support staff who is responsible for aiding your users with the software once it is in production. You need to identify the level of control that each group has over your actual deployment. Can one group stop your deployment if you don't meet their specific requirements? For example, it is quite common to discover that operations departments have defined criteria for the release of new software, criteria that your deployment approach must meet. I once worked for an organization where the users were unionized and any software that was deployed to them had to be first accepted by their union representatives, otherwise you couldn't ship. Early in your project you need to identify the deployment hoops that you need to jump through to be successful.

Identify your deployment strategy early. Will you run the new system in parallel with the existing system or will you perform a cutover? Running the system in parallel offers the advantage that you can easily back out to the original system if the new one runs into problems. However, parallel operations requires significant effort on the part of everyone involved: Your users need to do double entry, operations staff need to run both systems, support staff need to support both systems, and development staff may need to create integration code that temporarily works behind the scenes to synchronize data. For many systems, particularly ones supporting online customers via the Internet, a cutover is your only option – few customers would be willing to place their book order with both Amazon version N and with Amazon version N+1. With a straight cutover you will need to plan for a downtime period in which the cutover occurs, anywhere from a few seconds to a few hours, or even a few days depending on the nature of the system being deployed.

Installation testing. Just like you test your application, you should also test your installation scripts. A good way to do this is to develop your installation scripts as you develop your system, and use them to promote your software between your team integration sandbox into your pre-production testing environments.

Release regularly. Agile software developers typically deliver development releases at the end of each iteration into pre-production staging area(s) (see Figure 1). A development release of an application is something that could potentially be released into production if it were to be put through your pre-production quality assurance (QA), testing, and deployment processes. Granted, this won’t be true earliest development releases because you won’t have delivered sufficient functionality to make deployment worth your while. Furthermore at the beginning of a project you often stub out interfaces to shared services – such as security, persistence, or even reusable legacy functionality – so technically you still have some clean up to do before you’re ready to release to production. This is why in Figure 2 you see that the first production release often takes longer to deliver than subsequent releases; in the first release of a system you likely need to get a lot of the “plumbing” in place and your team likely hasn’t “gelled” yet enabling them to become efficient at collaboration. The first production release may take you twelve months to deliver, the second release nine months, and then other releases are delivered every six months. An early focus on deployment issues not only enables you to avoid problems it also allows you to take advantage of your experiences during development. For example, when you are deploying software into your staging area you should take notes of what works and what doesn’t, notes that can serve as the backbone of your installation scripts.

Start planning early. Deployment can be quite complex, especially when your user base is physically dispersed or there is a wide range of system configurations, you often find that you need to start planning early in your project lifecycle to be successful. There is nothing worse than rushing to finish software on time only to have it put on the shelf to await installation due to lack of deployment planning.

Recognize that deployment is harder than it looks. Regardless of whether your organization has adopted the AUP or not, the fact is that as you can see there are several activities which you need to consider when deploying a system into production.
Take an agile approach to planning. Keep your plans high-level at first, focusing on the major dependencies. The people doing the work should plan the details, and you don't need to worry about the details until you're about to do the work.
Reduce your pre-production testing efforts safely over time. It’s of little value to deliver working software on a weekly basis if there is a three-month pre-production testing process which it must go through each time. With agility you’ll find that you can reduce the amount of time invested in your pre-production testing efforts, and thereby speed up deployment. Why is this? Agilists produce high quality artifacts and have the regression test suite to prove that their system actually works. This higher level of quality implies that you’ll be able to do less testing during system deployment. Once you get really good you may find that you can in fact deploy working software into production on a weekly basis – I’ve seen this at a very large financial institution and a dot-com so it is possible, regardless of what the traditionalists may tell you.
Well-tested software is easier to deploy. Object-oriented testing is a complex and difficult endeavor, but one that you must undertake. I have several fundamental philosophies regarding testing. First, test early and test often. Two, if you can build it you can test it. Three, if it isn't worth testing it likely isn't worth building.

Your plan must reflect your organizational culture. You need to understand whom you are deploying software to, their current work practices and policies, the amount of change they are willing to tolerate, and how your software will affect them once deployed. I've found that the larger the organization the more difficult it is to deploy new software due to cultural inertia. Most people have a tendency to sit back and wait to see who else is using a product, which is often contrary to the nature of most software developers who will jump at the chance to work with new software.

Update your deployment plan regularly. This helps to set realistic expectations by both your project team and your deployment audience.
Work backwards when deployment planning. Envision the system in production – users are working with it, operations professionals are keeping it going, support staff are helping users to work with the system, and developers are potentially evolving the system to address defects and to implement new requirements – and ask what needs to occur to get me to that point. Then compare that vision with where the current environment is today, something called deployment gap analysis, to determine what needs to occur to successfully install your system. My experience is that forward planning generally isn’t sufficient when it comes to system deployment because your requirements often do not reflect issues pertinent to the production phase of your system, the need to operate and support your software is often assumed and therefore not explicitly reflected in your requirements.

Have go/no-go decision points during the installation process. A good deployment plan includes go/no-go decisions points during the installation process. If at defined times during the installation you have not reached a certain point in the overall installation process you will rollback your efforts and try to install again at a future date. This is a critical concept for projects that have very stringent deployment requirements, typically software that is replacing existing mission-critical systems that currently run your business.

Develop "de-installation" scripts. The ability to back out becomes critical with this approach, requiring investment of additional resources to develop and test de-installation scripts. In fact, many deployment efforts fail miserably because the development team didn’t bother to consider how to back out their new system, and then discovered that they had to do so because of an unforeseen problem during installation. Never assume that your deployment efforts will go smoothly.
Remember the data. Data conversion is often a key task for the deployment of a new software system, a complex effort that should be started early in your project. Analysis of your legacy data needs to be performed: the legacy data sources need to be identified, the legacy schemas should be modeled, and official sources of each attribute need to be chosen for data stored in several places. You need to understand your existing legacy data so that you can convert it to your new schema

Negotiate with legacy system owners early. During development you will discover dependencies between your system and other systems, dependencies that should appear on your deployment model. These dependencies affect your deployment plan because they imply the order in which updates to the various systems (if any) must be installed. You will need to negotiate deployment efforts with the other project teams that own the systems you have dependencies on, effectively a cross-project effort. If the interface to your system changes, or if you require new ways to access their systems, then they may also need to release all or part of their systems before yours.
Announce the deployment. You should announce the anticipated deployment schedule, including both the expected training and installation dates. Your announcement could be an email to your customers, a press release, or even advertisements on television, in magazines, or on the Internet. Release announcements are important because people want to know how the new system will affect them, if at all, and when it will affect them. Respect the fact that your deployment efforts are disrupting the lives of your stakeholders.

Hold regular release meetings. The closer you get to deployment, the greater the need to hold regular release meetings with key players involved in the actual deployment. This includes quality assurance staff to advise everyone of the testing status of your software, developers to advise you of the current rework status, operations staff to inform you of current production issues of the existing environment, and support and user management to inform you of their training statuses.

Understand the associated risks of deploying systems. Because software projects have a tendency to be delivered late and over budget, there is often spectacular pressure exerted by senior management on the project manager to forgo training. Without training, your users won't be able to effectively use your software, your operations staff won't understand how to operate your software, and your support staff will have difficulty properly supporting your system. Documentation is typically at risk on most projects, once again due to being late and over budget as well as a general lack of knowledge among developers as to how to write effective documentation. Poor documentation results in significantly higher maintenance and support costs for your system. The greatest risk is often data conversion, a very complex and critical task that is often ignored until it is too late.

Don't underestimate the opportunities for reuse. Other projects may have already developed deployment models that reflect your target platform, models that you can evolve as needed for your own use (ideally your enterprise architects should be able to provide these models). Furthermore, templates for deployment plans, installation procedures, and templates for operations, user, and support documentation can also be reused from other projects. Remember, you can reuse more than just code.

You may need to upgrade your user's existing environments. These upgrades could include changes to existing hardware, operating systems, databases, or middleware. If you don’t know the current status of your technical environment you will also need to plan for activities to perform the required legacy analysis. If you are upgrading your database, you may be upgrading the database software itself or the schema of your database, you will need to include data conversion activities in your deployment plan. Physical considerations should also be considered when performing environment upgrades. Is sufficient power available? Are working areas such as desks and cubicles in place? Does sufficient room exist in the building(s) that you are deploying to? Do sufficient network drops exist for new workstations?

Training is an important part of deployment. Remember that your stakeholders may need training beyond that of learning how to work with your application. For example, this may be the first time that some users are working with a PC, a browser, or even a mouse. Similarly, this may be the first time that your operations staff is working with a new technology that your system users, such as an EJB application server, and therefore will need to be trained and educated in that technology to qualify them to work with your system.

Develop supporting documentation. Another important effort is the development of operations, support, and user documentationDepending on your corporate documentation standards you will likely find that you need to include one or more technical writers on your team to develop this documentation (hopefully in an agile manner).

Ref: http://publib.boulder.ibm.com/infocenter/dmndhelp/v7r0mx/index.jsp?topic=/com.ibm.websphere.wps.doc/doc/tpln_implementnd.html
http://www.drdobbs.com/architecture-and-design/184414753;jsessionid=N4NQLCW02PCZTQE1GHOSKH4ATMY32JVN?cid=Ambysoft
http://www.ambysoft.com/essays/deploymentTips.html

_SAD 1: Assignment # 10_

2010-06-10T16:46:00.000-07:00

With reference to assignments 8 and 9, what characteristics does an analyst(you) examine when evaluating DFD quality? (1500 words)

The Data Flow Diagram is the most commonly used process model. A Data Flow Diagram is a graphical system model that shows all of the main requirements for an information system in one diagram; inputs and outputs, processes and data storage. Everyone working on a development project can see all aspects of the system working together at once with the DFD. DFD is also easy to read because it is a graphical model and because there are only five symbols to learn. End users, management and all information systems workers typically can read and interpret the DFD with minimal training.

In evaluating DFD quality, a high-quality set of DFD is readable, is internally consistent and accurately represents system requirements. Accuracy of representation is determined primarily by consulting users and other knowledgeable stakeholders. A project team can ensure readability and internal consistency by applying a few simple rules to DFD construction. Analysts can apply these rules while developing the DFDs or during a separate quality check after preparing DFD drafts.

An analyst must know how to minimize complexity. People have a limited ability to manipulate complex information. If too much information is presented at once, people experience a phenomenon called information overload. When information overload occurs, a person has difficulty in understanding. The key to avoiding information overload is to divide information into small and relatively independent subsets. Each subset should contain a comprehensible amount of information that people can examine and understand in isolation. A layered set of DFDs is an example of dividing a large set of information into small independent subsets. Each subset can be examined in isolation. The reader can find additional detail about a specific process by moving down to the next level or find information about how a DFD relates to other DFDs by examining the next-higher level of DFD.

An analyst can avoid information overload within any single DFD by following two simple rules of DFD construction: the 7 + 2 and interface minimization. The rule of 7 + 2 also known as Miller’s Number derives from psychology research which shows that the number of information ‘chunks ’ that a person can remember and manipulate at one time varies between five and nine. A larger number of chunks causes information overload. Information chunks can be many things including names, words in a list, digits or components of a picture. Some application of the rule of 7 + 2 to DFDs includes the following: that a single DFD should have no more than 7 + 2 processes, no more than 7 + 2 data flow should enter or leave a process, data store or data element of a single DFD. These rules are general guidelines not unbreakable laws, DFDs that violate these rule may still be readable but violations should be considered a warning of potential problems.

Minimization of interfaces is directly related to 7 + 2. An interface is a connection to some other part of a problem or description. As with information chunks, the number of connections that a person can remember and manipulate is limited, so the number of connections should be kept to a minimum. Processes on DFD represent chunks of business or processing logic. They are related to other processes, entities and data stores by data flows. A single process with a large number of interfaces maybe too complex to understand. This complexity may show up directly on aprocess decomposition as a violation of the rule 7 + 2. An analyst can usually correct the problem by dividing the process into two or more subprocesses,each of which should have fewer interfaces.

Pairs or groups of processes with a large number of data flows between them are another violation of the interface minimization rule. Such a condition usually indicates a poor partitioning of processing tasks among the processes. The way to fix the problem is to reallocate the processing tasks so that fewer interfaces are required. The best division of work among processes is the simplest and the simplest division is one that requires the fewest interfaces amongprocesses.

An analyst can detect errors and emissions in a set of DFDs by looking for specific types of inconsistency. Three common and easily identifiable consistency erros as follows; differences in data flow content between a process and its process decomposition, data outflows w/o corresponding data inflows, data inflows w/o corresponding outflows. A process of decomposition shows te internal details of a higher level process ina more detailed form. In most cases, the data content of flows to and from a processes at one DFD level shuld be equivalent to the content of data flows to and from all processes in a decomposition. The equivalency is called balancing and the higher level DFD and the process decomposition DFD are said to be in balance. Data flow names can vary among levels for a number of reasons including decomposition of one combined data flow into several smaller flows. Thus, the analyst must be careful to look at the components of data flows,not just data flow names. For this reason, detailed analysis of balancing should not be undertaken until data flows have been fully defined. Unbalance DFDs may be acceptable when the imbalance is due to data flows that were ignored at the higher levels. For example, diagram 0 for a large system usually ignores details of error handling such as when an item is ordered but it is later determined to be out of stock and discontinued by its manufacturer.

Anothertype of DFD inconsistency can occur between data inflows and outflows of a single process or data store. By definition, a process transforms data inflows and data outflows. Analysts sometimes can spot black holes nad miracles simply by examining the DFD in other cases, close examination of data dictionary or process descriptions is required.
In a logical DFD, data should not be needlessly passed into process. The following consistency rules canbe derived from these facts: that all data flows into a process must flow out of the process or be used to generate data that flows out the process, all data that flows out process must have flowed into the process or have been generated from data that flowed into process.

DFD have symbols and these are; Consist of the following entities, data store number and name of data store. The function of data store is to designate the storage of data in a dfd diagram.
• The square is an external agent (a person or organization, outside the boundary of a system that provides data inputs or accepts data outputs)
• The rectangle with rounded corners is a process (named “Look up item available” and can be referred to by its number, 1)
• A process defines rules (algorithms or procedures) for transforming inputs into outputs
• The lines with arrows are data flows (represents movement of data). Slide shows two data flows between Customer and process 1: a process input “Item inquiry” and process output named “Item availability details”
• The flat three-sided rectangle is a data store (a file or part of a database that stores information about data entity)

Data flow is a collection of data elements . Data flow definition is a textual description of data flow’s content and internal structure. Lists all the elements, e.g. a “New Order” data flow consists of Customer–Name, Customer-Address, Credit-Card-Information, Item-Number and Quantity. Often coincide with attributes of data entities included in ERD plus computed values. Algebraic notion is alternative to the list. Describes data elements on data flow plus data structure.
Data type description can be a String, integer, floating point, Boolean. Sometimes very specific written description e.g., special codes (e.g. code A means ship immediately, code B – hold for one day and code C – hold shipment pending confirmation). Length of element (usually for strings). Maximum and minimum values (for numeric values). Data dictionary – repository for definitions of data flows, data stores, and data elements.
A data store on the DFD represents a data entity on the ERD (so, no separate definition is needed, just a note referring to the ERD for details). If a data store are not linked to an ERD, a definition is provided as a collection of elements (like did for data flows).

Guidelines/Gumption Traps:
(Places where DFDing can go astray)
1. System boundary establishment is an important judgment call. External entities aid in determining where the boundary is established. An interfacing system can be shown as an external entity. It may be necessary to dictate the input of the external entity to assure system control. For example, customers may be required to submit orders or refund requests containing specific information which may require that the system aid in completion of a form. Use of output such as reports by management may re quire some agreement on tactics to be performed which may mean the entity becomes part of the system, not external to it. When in doubt, include the external entity as processes within the system and then evaluate with those concerned.
2. Label your processes carefully and vividly. A process that is labeled "Produce Report" and has the output of "Report" tells a reviewer very little. If you have trouble labeling anything on the diagram, it often is because you do not have adequate un derstanding. Choose names carefully.
3. Think logical, not physical. Ignore media, color, font, layout, packaging, time, sequencing, etc. Think "what", not "how". Something logical can be implemented physically in more than one way. Including "when" and "where" and "how" means you are g etting physical.
4. Think data, not control, flow. Data flows are pathways for data. Think about what data is needed to perform a process or update a data store. A data flow diagram is not a flowchart and should not have loops or transfer of control. Think about the data flows, data processes, and data storage that are needed to move a data structure through a system.
5. Concentrate first on what happens to a "good" transaction. Systems people have a tendency to lose sight of the forest because they are so busy concentrating on the branches of the trees.
6. Reviewers will not be convinced by confusion. A quality data flow diagram will be so simple and straightforward that people will wonder what took you so long.
7. Data store to data store, external entity to external entity, or external entity to data store connection usually do not make sense. Data flows with an arrowhead on each end cause confusion in labeling. Do not use them.
8. Do not try to put everything you know on the data flow diagram. The diagram should serve as index and outline. The index/outline will be "fleshed out" in the data dictionary, data structure diagrams, and procedure specification techniques.

What are some of the advantages of using DFD analysis? Here are several:
• Data flows and process consequences. Note how this representation of the data characteristics of banking operations enables us to start at any point in the operation (e.g., deposits, withdrawals, or bill payment), and follow the consequences of that activity through to the point where all appropriate account balances have been adjusted and reconciled. Wherever we start in the process, we can understand the processing steps that the bank would need to take to complete the relevant transaction(s) and to inform its constituents of the results.
• Data inputs and outputs. The DFD also makes it possible to understand what data are needed to provide appropriate inputs to any processing step. If, for example, we were to build an information system to support this individual's banking activities (in the days before Quicken and/or Microsoft Money), we would need to understand exactly what data items are represented by data flows such as "Monthly Statement", "Pay earned", "Withdraw or transfer", and other arrows shown in the diagram.
• Simplifying complexity by isolating process components. Note how the DFD would make it easier to capture the detail of such data flows. By isolating "Withdraw or Transfer" within the larger scheme of the banking process, the DFD makes it possible to consider the details of the data items included in this flow without reference to the flows affecting other processing steps. All of the flows affecting withdrawals (e.g., processing step 3.0, "Withdraw funds from account") are isolated as entering or leaving processing step 3.0. At the time that DFDs were developed, this shift towards modularizing data flows and processing elements represented a major step forward in enabling systems analysts to add useful structure to process representations rapidly and easily.
Disadvantages of data flow diagram
• DFD is likely to take many alteration before agreement with the user
• Physical consideration are usually left out
• It is difficult to understand because it ambiguous to the user who have little or no knowledge
Step in drawing dfd diagrams
1. Make a list of all business activities and use it to determine the various external entities, data flows, process and data store
2. Create a context diagram which shows external entity and data flows to and from the system
3. Do not show any detailed process or data store
4. Draw diagram zero or the next level to show process but keep them general. Show data stores and the level
5. Create a child diagram for each of the process in diagram zero
6. Check for errors and make sure the levels you assign to each process and data flow are meaningful
7. Develop a physical dfd diagram from the logical dfd and distinguish between the manual and automated protocol, describe actual files and report by name and controls to indicate when the process are complete or errors occurs
8. Portion the physical DFD by separating or grouping parts of the diagram in order to facilitate programming and implementation
How to develop Logical data flow diagram
Below are the guidelines in developing data flow diagrams
1. Develop a physical dfd
2. Explore the process for more details
3. Maintain consistency between the process
4. Following meaningful leveling convention
5. Ensure that dfd diagrams clarifies what is happening in the system
6. Remember dfd audience
7. Add control on the lower level dfd only
8. Assign meaningful level
9. Evaluate dfd for correctness

Dos and Don’ts of external entity
• External entity never communicate with each other, this signify that there is no need for the process
• External entity should not communicate directly with data store because external entities can be identifier with the record of files and databases
Evaluating Data Flow Diagrams for Correctness
It is essential to evaluate all DFDs carefully to determine if they are correct. Errors, omissions and inconsistencies can occur for several reasons, including mistakes in drawing the diagrams. But the presence of what appears to be an error may in fact point out a deficiency in the system or a situation in which users are not aware of how certain processes operate.
These questions are useful in evaluating data flow diagrams:
•Are there any unnamed components in the data flow diagram (data flows, processes, stores, inputs or outputs)?
•Are there any data stores that are input but never referenced?
•Are there any processes that do not receive input?
•Are there any processes that do not produce output?
•Are there any processes that serve multiple purposes? If so, simplify by exploding them into multiple processes that can be better studied).
•Are there data stores that are never referenced?
•Is the inflow of data adequate to perform the process?
•Is there excessive storage of data in a data store (more than the necessary details)?
•Is the inflow of data into a process too much for the output that is produced?
•Are aliases introduced in the system description?
•Is each process independent of other processes and dependent only on the data it receives as input?

Diagramming mistakes: Black holes, grey holes, and miracles
A second class of DFD mistakes arise when the outputs from one processing step do not match its inputs. It is not hard to list situations in which this might occur:
• A processing step may have input flows but no output flows. This situation is sometimes called a black hole [3].
• A processing step may have output flows but now input flows. This situation is sometimes called a miracle.
• A processing step may have outputs that are greater than the sum of its inputs - e.g., its inputs could not produce the output shown. This situation is sometimes referred to as a grey hole.
When one is trying to understand a process during the course of an interview (and consequently drafting DFDs at high speed), it is not hard to develop diagrams with each of the above characteristics. Indeed, scanning DFDs for these mistakes can raise questions that provide questions for use in further process analyses (e.g., "Where do you get the data that allows you to do such-and-such...").
DFDs are not flow charts
A last class of DFD mistakes are somewhat more difficult to identify. Many of us have had prior experience developing flow charts. Flow chart diagrams can be useful for describing programming logic or understanding a single sequence of process activities. It is important to recognize, however, that DFDs are not flow charts. Flow charts often show both processing steps and data "transfer" steps (e.g., steps that do not "process" data); DFDs only show "essential" processing steps. Flow charts might (indeed, often do) include arrows without labels: DFDs never show an unnamed data flow. Flow charts show conditional logic; DFDs don't (the conditional decisions appear at lower levels, always within processing steps). Flow charts show different steps for handling each item of data; DFDs might include several data items on a single flow arrow.
Data flow diagrams can assist in
• Isolating the component parts of a business process, reducing the analytical complexity involved in determining the specifications that process support software would have to meet.
• Shifting the focus of a process description to the data flows and processing steps that the process represents.
• Identifying data-related process characteristics that could be candidates for process design improvements.
• Identifying data stores that isolate entities that could be further developed using entity-relationship analysis.

General Data Flow Rules
1. Entities are either 'sources of' or 'sinks' for data input and outputs - i.e. they are the originators or terminators for data flows.
2. Data flows from Entities must flow into Processes
3. Data flows to Entities must come from Processes
4. Processes and Data Stores must have both inputs and outputs (What goes in must come out!)
5. Inputs to Data Stores only come from Processes.
6. Outputs from Data Stores only go to Processes.

ref: http://books.google.com.ph/books?id=-ot62DeCKO4C&pg=PA234&lpg=PA234&dq=characteristics+of+an+analyst+in+evaluating+dfd&source=bl&ots=V0yZMyRzSx&sig=1mBZj2FGtrLcwIjEzazBzwQNmDM&hl=tl&ei=8RURTIKEKca5rAffh4jaBA&sa=X&oi=book_result&ct=result&resnum=5&ved=0CCkQ6AEwBA#v=onepage&q=characteristics%20of%20an%20analyst%20in%20evaluating%20dfd&f=false

_SAD 1: Assignment # 9_

2010-06-10T08:56:00.000-07:00

Data Flow Diagram-a network representation of a system. The system may be automated, manual, or mixed. The DFD portrays the system in terms of its component pieces, with all interfaces among the components indicated. by:Tom DeMarco

_SAD 1: Assignment # 8_

2010-06-10T08:46:00.000-07:00

This activity diagram describes the different processes to enroll in the university.

In order to admit in the university, the applicant should first take the USEPAT exam and above are the steps for scheduling.

After scheduling, entrance examination is to be done to know if the applicant is qualifies to enroll in the university or not.

This activity diagram is for the medical examination. This will takes place either during admission or during EBP.

This activity diagram is for the interview process wherein the applicant is interviewed in the department he/she preferred to enroll.

_SAD 1: Assignment # 7_

2010-06-10T08:35:00.000-07:00

USEPAT- University of Southeastern Philippines Admission Test

Use Case # 1: Get application form for USEPAT exam
Actor: Applicant
Brief Description: To fill out the forms necessary in scheduling to take the USEPAT exam.

Use Case # 2: Pay USEPAT exam/fee
Actor: Applicant
Brief Description: To pay the USEPAT fee in order to take the exam.

Use Case # 3: Issue Receipt
Actor: Cashier
Brief Description: The cashier issues the receipt from the applicant’s payment for the USEPAT exam.

Use Case # 4: Take the exam
Actor: Applicant
Brief Description: The applicant take the exam as the admission test to enroll in the university.

Use Case # 5: Get the result
Actor/s: Applicant, UGTO
Brief Description: After taking the exam, the applicant gets the result to know whether he/she failed or pass the admission test in the UGTO.

Use Case # 6: Fail the Exam
Actor: Applicant
Brief Description: If the applicant fails the USEPAT exam, then he/she can’t enroll in the university.

Use Case # 7: Pass the Exam
Actor: Applicant
Brief Description: The applicant can enroll in the university if he/she passes the exam.

Use Case # 8: Take English Bridge Program
Actor: Applicant
Brief Description: The applicant undergoes EBP as participation before enrollment.

Use Case # 9: Pay EBP fee
Actors: Applicant, Cashier
Brief Description: The applicant pays the EBP fee to the cashier in order to undergo the said program.

Use Case # 10: Take Medical Exam
Actors: Applicant, Medical attendant
Brief Description: It is mandatory to take a medical test in the university as part of the requirements to enroll in the university that is done by the medical attendant assign.

Use Case # 11: Fill up Medical forms
Actor: Applicant
Brief Description: In taking medical test, the applicant should first fill up medical forms in order that the medical attendant will know your health issues.

Use Case # 12: Provide all necessary documents for interview
Actor: Applicant
Brief Description: The applicant gather now all the necessary requirements for the interview in order to be ready for the enrollment process.

_SAD 1: Assignment # 6_

2010-06-10T08:33:00.001-07:00

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

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

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

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

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

Required:

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

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.

From the above conversation about what should they do for a new information system, I will be at the side of John Juan. We know that Peter Pedro is just concern about it for he is the manager of the department and that they end up only in a modified version of the old system. Why is it that I'm taking the point of John Juan? For me, since he is a system professional he knows already what to do and what should be doing to make a new information system. From his designed profession, you can identify whether that person have that knowledge you required or don't have. According to wikipedia, the Information Systems Professional (I.S.P), or Informaticien professionnel agréé (I.P.A. in French), is a professional designation issued by the Canadian Information Processing Society (CIPS). Introduced in 1989, the professional designation is recognised by legislation in most provinces of Canada. Before meeting the entry requirements for professional status an applicant may use the "Candidate Member I.S.P" designation.
CIPS has developed the Computer Science Accreditation Council (CSAC), and the Information Systems and Technology Accreditation Council (ISTAC) to accredite baccalaureate programs in Computer Science, Software Engineering, Management Information System, Computer Systems Technology, Applied Information Technology, and post-diploma type programs in Canada. These accredited programs combined with several years of experience lead to the I.S.P. Designation. From the meaning itself, lots of experience is required to be a systems professional. And it means that since he/she undergone that, we can say that he/she is really an excellent person for he/she surpassed that kind of challenge.

Ref: http://en.wikipedia.org/wiki/Information_Systems_Professional

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

Every thing in this world needs to be analyzed first before going to processing. Analyzing is really need for it is the first stage in which you can go to the second stage, that is for my view as I was living in this world. Even in academic subjects like mathematics, you need to first analyze the certain problem in order to know what to do and what formula is going to take to solve certain kind of problem.

In developing a new information system, it also have what we call formula. A step by step formula that will guide you through developing a system. As what Ma'am said in the anflocor as we interviewed her,
there is no perfect system. And I agree to her for just like we, people are not perfect. Everyone made a mistake and in terms of developing, people doing that also can experience failure. And in order to minimize that failure, programmers, systems analyst and everyone involved, they take step by step formula. And first is systems analysis phase. Systems analysis include requirements analysis. Requirement analysis is the process of understanding the needs of the customer in the company, what is expected output from proposed system and is a well-defined stage in the Software Development Life Cycle model. The Software Requirements Analysis Process covers the complex task of eliciting and documenting the requirements of all these users, modeling and analyzing these requirements and documenting them as a basis for system design. Requirements analysis is needed for an inadequate analyzing of requirements at the beginning of the project is the most common cause of the software project to fail. There are instances of corporations that have spent huge amounts on software projects where the end application eventually does not perform the tasks it was intended for. Software companies are now investing time and resources into effective and streamlined Software Requirements Analysis Processes as a prerequisite to successful projects that align with the client’s business goals and meet the project’s requirement specifications.

First step in the requirements analysis process is to identify how the new application integrates to business processes and also what will be its scope and limitations for without having boundaries result into not finished projects. Second is to know who will use of that new application or system they will be developing. Requirements elicitation is next that refers to the information gathered from the multiple stakeholders identified to know what requirements from the application are and what they expect the application to accomplish. Here also are making of use cases diagrams, data flow diagram and etc. Another is to have requirements analysis process in which after all the stakeholder information gathered, the structured analysis is done after the modeling the requirements. And after the requirements are elicited, proper documenting of requirements is next. It is the written reports. The software requirements specification is a document that lists out stakeholders’ needs and communicates these to the technical community that will design and build the system. The challenge of a well-written requirements specification is to clearly communicate to both these groups and all the sub-groups within. Requirements Specification serves as a starting point for software, hardware and database design. It describes the function (Functional and Non-Functional specifications) of the system, performance of the system and the operational and user-interface constraints that will govern system development. The last is the managing of requirements which is the verification, validation and correcting of errors after all is done.

By simply just following certain kind of steps that will be helpful in developing a system, there will be no problem. Understanding each other and understanding what to do is really a big help!That's it.:-)

Ref: http://www.outsource2india.com/software/RequirementAnalysis.asp

_SAD 1: Assignment # 5_

2010-06-10T08:30:00.000-07:00

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

Before proceeding to some discussions, let us first define what is meant by "life cycle". Life cycle has life and a cycle. Life has different meaning. One is that life is the condition which distinguishes active organisms from inorganic matter, including the capacity for growth, functional activity and the continual change preceding death (in biology). Cycle is the repeating process or event in many fields (vise versa). Life Cycle is a period from one generation of organisms to the same identical...

When we talk of life cycle, it has lots of derivation. Examples, like biological life cycle which talks about the life cycle of people. Another is the life cycle of the animal which talks about the life cycle of the animal, of how they become like that and this. Those things are just one of the happenings that we can see that we are really living in this universe. Not only living things can have that kind of cycle, even the non-living things could have it. Non-living things or the material ones can have the cycle and that by means of the living things. How? By people. Why I said so? Let’s consider USEP.

USEP means University of Southeastern Philippines , a college school where I currently enrolled and studied in. It is asked that if the university/institution developed a life cycle specifically for the school and if it was developed, how we know that it meets the needs of everyone in the university.

For me, based on my observation since I came in this university, I can say that the university has a life cycle of course. And if it was developed?hmmm...let me first think!:-) Well, each university/institution and all other establishments have life cycle which it gives them the reason why they build that kind of thing. Something that they want. And in case of university, like my school USEP, we know that it is a government school which means all that what is needed is from the government. One of the goal of the USEP is to produce globally competitive and morally upright graduates. From that goal alone, we can say that in order to attain that goal, the one who want that kind of thing should give an effort in making something really important so that it can be a successful one.

I think that the first thing to do is to have an analysis. First part of all that a person that he/she should be doing is to have an analysis which from the word itself “analysis”, is the act of analyzing the things that should be going to make or should be doing which can give a reliable and relevant output that can also be useful in everyday activities. The university gets first into analyzing what are the things to do to obtain what is needed to attain and that is from the objectives, goals, vision and mission that they think the best thing to do. After analyzing, there comes the result, the different curriculum for every colleges needed.
After the result are obtain from analyzing and creating what to do, testing is the next thing for that. Before implementing a certain kind of thing, like for example a product, testing takes first given for it determine how is it going. It is to know whether it was effective or not. Creating and testing iWhy? Because if you had created a certain thing, what you should do is to test it. That's why when you create, you test it.
Implementing is next given to testing. After it was tested, if it is ok then why not implement it. In the case of USEP, implementation takes place wherein students are now using what is created and that is curriculum to every department. You can determine here whether it was successful or not by what is said from its goal. To produce competitive graduates.
Another thing that needs attention is the evaluation process. Evaluation in which it evaluates day by day to be updated on what's the latest about the university. It is determining whether the university still obtaining and maintaining and still meet what's created. If it still inline with the goals that want to achieve.
And If I were to ask if it meets our needs, I think it's in the middle. Meaning, it maybe yes or no. Yes, for I can see that from the goal, that is to produce competitive graduates, lots of graduates and we all know that not all graduates find their job. And I think, some graduates are just graduated because of something fishy..hehe..chaar....Well, what I feel is that the university is still in the process of meeting and attaining those needs of the people in the institution.

About USEP

The University of Southeastern Philippines (USEP) is a regional state university created in 1978 through Batas Pambansa Bilang 12. The university is an integration of four state institutions, particularly, the Mindanao State University-Davao, the University of the Philippines-Master of Management Program in Davao, the Davao School of Arts and Trades, and the Davao National Regional Agricultural School.

The university has four campuses, namely, Obrero (main) and Mintal Campuses in Davao City, Tagum-Mabini Campus which has two units – one in Tagum City and one in Compostela Valley Province, and Bislig Campus in Surigao del Sur.

The USEP offers graduate and undergraduate academic programs in the fields of engineering, education, arts and sciences, economics, business, computing, governance, development, resource management, technology, agriculture and forestry.

The University of Southeastern Philippines has the following mandate:

* To provide programs of instruction and professional training primarily in the fields of science and technology, especially medicine, fisheries, engineering and industrial fields.
* To promote advanced studies, research and extension services and progressive leadership in science, agriculture, forestry, fisheries, engineering and industrial fields and other courses needed in the socio-economic development of Mindanao.
* To develop courses at the graduate level along the fields of specialization and to respond to the needs of development workers in the academic community.
* To provide non-formal education and undertake vigorous extension and research programs in food production, nutrition, health and sports development.
* To offer scholarship and/or part-time job opportunities to deserving students from low-income families.

Mission

USEP shall produce world-class graduates and relevant research and extension through quality education and sustainable resource management.

Particularly, USEP is committed to:

* Provide quality education for students to grow in knowledge, promote their well-rounded development, and make them globally competitive in the world of work;
* Engage in high impact research, not only for knowledge’s sake, but also for its practical benefits to society; and,
* Promote entrepreneurship and industry collaboration.

Vision

A PREMIER UNIVERSITY IN THE ASEAN REGION-By becoming a premier university in the ASEAN Region, the USEP shall be a center of excellence and development, responsive and adaptive to fast-changing environments. USEP shall also be known as the leading university in the country that fosters innovation and applies knowledge to create value towards social, economic, and technological developments.

Goals

Aligned with the university 's vision and mission are specific goals for Key Result Areas (KRA) on Instruction; Research, Development, and Extension; and Resource Management:

KRA 1. Instruction

Produce globally competitive and morally upright graduates

KRA 2. Research, Development, and Extension (RDE)

Develop a strong R,D,&E culture with competent human resource and responsive and relevant researches that are adopted and utilized for development

_SAD 1: Assignment # 4_

2010-06-09T21:53:00.002-07:00

What is a software process model?
Software process models often represent a networked sequence of activities, objects, transformations, and events that embody strategies for accomplishing software evolution. Such models can be used to develop more precise and formalized descriptions of software life cycle activities. Their power emerges from their
utilization of a sufficiently rich notation, syntax, or semantics, often suitable for computational processing. Examples of models include the workflow model, the data-flow model, and the role model.

-The workflow model shows the sequence of activities in the process along with their inputs, outputs and dependencies. The activities in the model represent human actions.
-The dataflow model represents the process as a set of activities each of which carries out some data transformation. It shows how the input to the process such as specification is transformed to an output such as design. The activities here maybe lower than in a workflow model. They may represent transformations carries out by people or computers.
-The role model represents the roles of people involved in the software process and the activities for which they are responsible.

Three (3) of the software development models:
1.Waterfall Model

The waterfall model derives its name due to the cascading effect from one phase to the other as is illustrated in Figure1.1. In this model each phase well defined starting and ending point, with identifiable deliveries to the next phase.

The model consist of six distinct stages, namely:

1.In the requirements analysis phase

(a)The problem is specified along with the desired service objectives (goals)
(b)The constraints are identified

2.In the specification phase the system specification is produced from the detailed definitions of (a) and (b) above. This document should clearly define the product function.

3. In the system and software design phase, the system specifications are translated into a software representation. The software engineer at this stage is concerned with:

·Data structure
·Software architecture
·Algorithmic detail and
·Interface representations

The hardware requirements are also determined at this stage along with a picture of the overall system architecture. By the end of this stage the software engineer should be able to identify the relationship between the hardware, software and the associated interfaces. Any faults in the specification should ideally not be passed ‘down stream’

4.In the implementation and testing phase stage the designs are translated into the software domain

·Detailed documentation from the design phase can significantly reduce the coding effort.
·Testing at this stage focuses on making sure that any errors are identified and that the software meets its required specification.

5.In the integration and system testing phase all the program units are integrated and tested to ensure that the complete system meets the software requirements. After this stage the software is delivered to the customer [Deliverable – The software product is delivered to the client for acceptance testing.]

6.The maintenance phase the usually the longest stage of the software. In this phase the software is updated to:

·Meet the changing customer needs
·Adapted to accommodate changes in the external environment
·Correct errors and oversights previously undetected in the testing phases
·Enhancing the efficiency of the software

Advantages

·Testing is inherent to every phase of the waterfall model
·It is an enforced disciplined approach
·It is documentation driven, that is, documentation is produced at every stage

Disadvantages

The waterfall model is the oldest and the most widely used paradigm.
However, many projects rarely follow its sequential flow. This is due to the inherent problems associated with its rigid format. Namely:

·It only incorporates iteration indirectly, thus changes may cause considerable confusion as the project progresses.
·As The client usually only has a vague idea of exactly what is required from the software product, this WM has difficulty accommodating the natural uncertainty that exists at the beginning of the project.
·The customer only sees a working version of the product after it has been coded. This may result in disaster if any undetected problems are precipitated to this stage.

2. The Spiral Model

The spiral model combines the iterative nature of prototyping with the controlled and systematic aspects of the waterfall model, therein providing the potential for rapid development of incremental versions of the software. In this model the software is developed in a series of incremental releases with the early stages being either paper models or prototypes. Later iterations become increasingly more complete versions of the product.The model is divided into a number of task regions.These regions are:

1.The customer communication task – to establish effective communication between developer and customer.
2.The planning task – to define resources, time lines and other project related information..
3.The risk analysis task – to assess both technical and management risks.
4.The engineering task – to build one or more representations of the application.
5.The construction and release task – to construct, test, install and provide user support (e.g., documentation and training).
6.The customer evaluation task – to obtain customer feedback based on the evaluation of the software representation created during the engineering stage and implemented during the install stage.

The evolutionary process begins at the centre position and moves in a clockwise direction. Each traversal of the spiral typically results in a deliverable. For example, the first and second spiral traversals may result in the production of a product specification and a prototype, respectively. Subsequent traversals may then produce more sophisticated versions of the software.

An important distinction between the spiral model and other software models is the explicit consideration of risk. There are no fixed phases such as specification or design phases in the model and it encompasses other process models. For example, prototyping may be used in one spiral to resolve requirement uncertainties and hence reduce risks. This may then be followed by a conventional waterfall development.

Advantages of the Spiral Model

*The spiral model is a realistic approach to the development of large-scale software products because the software evolves as the process progresses. In addition, the developer and the client better understand and react to risks at each evolutionary level.
*The model uses prototyping as a risk reduction mechanism and allows for the development of prototypes at any stage of the evolutionary development.
*It maintains a systematic stepwise approach, like the classic life cycle model, but incorporates it into an iterative framework that more reflect the real world.
*If employed correctly, this model should reduce risks before they become problematic, as consideration of technical risks are considered at all stages.

Disadvantages of the Spiral Model

·Demands considerable risk-assessment expertise
·It has not been employed as much proven models (e.g. the WF model) and hence may prove difficult to ‘sell’ to the client (esp. where a contract is involved) that this model is controllable and efficient.

3. Prototyping Model

A prototype is a working model that is functionally equivalent to a component of the product.In many instances the client only has a general view of what is expected from the software product. In such a scenario where there is an absence of detailed information regarding the input to the system, the processing needs and the output requirements, the prototyping model may be employed. This model reflects an attempt to increase the flexibility of the development process by allowing the client to interact and experiment with a working representation of the product. The developmental process only continues once the client is satisfied with the functioning of the prototype. At that stage the developer determines the specifications of the client’s real needs.

The following sections examines two (2) version of the prototyping model:

Version I: Prototyping is used as a requirements technique.
Version II: Prototype is used as the specifications or a major part thereof.

Version I

This approach uses the prototype as a means of quickly determining the needs of the client; it is discarded once the specifications have been agreed on. The emphasis of the prototype is on representing those aspects of the software that will be visible to the client/user (e.g. input approaches and output formats). Thus it does not matter if the prototype hardly works.

Version II

In this approach the prototype is actually used as the specifications for the design phase. This advantage of this approach is speed and accuracy, as not time is spent on drawing up written specifications. The inherent difficulties associated with that phase (i.e. incompleteness, contradictions and ambiguities) are then avoided.

Disadvantages of prototyping:

1.Often clients expect that a few minor changes to the prototype will more than suffice their needs. They fail to realise that no consideration was given to the overall quality of the software in the rush to develop the prototype.
2.The developers may lose focus on the real purpose of the prototype and compromise the quality of the product. For example, they may employ some of the inefficient algorithms or inappropriate programming languages used in developing the prototype. This mainly due to laziness and an over reliance on familiarity with seemingly easier methods.
3.A prototype will hardly be acceptable in court in the event that the client does not agree that the developer has discharged his/her obligations. For this reason using the prototype as the software specification is normally reserved for software development within an organisation.

To avoid the above problems the developer and the client should both establish a protocol, which indicates the deliverables to the client as well as an contractual obligations.In both versions the prototype is discarded early in the life cycle. However, one way of ensuring that the product is properly designed and implemented is to implement the prototype in a different programming language from that of the product.

ref: http://scitec.uwichill.edu.bb/cmp/online/cs22l/prototype.htm, http://www.ics.uci.edu/~wscacchi/Papers/SE-Encyc/Process-Models-SE-Encyc.pdf

_SAD 1: Assignment # 3_

2010-06-09T21:22:00.000-07:00

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

A systems analyst 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.

Because they must write user requests into technical specifications, the systems analysts are the liaisons between vendors and the IT professionals of the organization they represent[1] They may be responsible for developing cost analysis, design considerations, and implementation time-lines. They may also be responsible for feasibility studies of a computer system before making recommendations to senior management.

A systems analyst performs the following tasks:

* Interact with the customers to know their requirements
* Interact with designers to convey the possible interface of the software
* Interact/guide the coders/developers to keep track of system development
* Perform system testing with sample/live data with the help of testers
* Implement the new system
* Prepare High quality Documentation

In general, the project manager is responsible for the overall success of the project. In some companies, this person might be called a Project Coordinator, or a Team Leader, however, the key aspect is that the person is responsible for ensuring the success of the project.

Depending on the size and complexity of the project, the project manager may take on other responsibilities in addition to managing the work. For instance, the project manager may assist with gathering business requirements. Or they may help design a database management system or they may write some of the project documentation. Project management is a particular role that a person fills, even if the person who is the project manager is working in other roles as well.

For instance, a project manager might manage the project for 45% of their time, perform business analysis for 25%, work on design for 15% and write documentation for 15%. This does not mean that one of the responsibilities of a project manager role is to spend 15% of their time on design. Instead, it just means that the project is not large enough to need a full-time project manager. The project manager spends the rest of their time in other project roles such as Business Analyst, Designer and Technical Writer. Depending on the size of your projects and the way your company is organized, a project manager’ time may be allocated one of three ways.

*They may have a full time role on a large project.
*They may have project management responsibilities for multiple projects, each of which is less than full time, but the combination of which adds up to a full-time role.
*They may fill multiple roles, each of which requires a certain level of skill and responsibility. On one project, for instance, they may be both a project manager and an analyst.

In some organizations, the project manager is accountable for the success of the project, but does not have the right level of responsibility. Managing the team in a matrix organization is an example of that. You are asked to manage a project utilizing people that you do not have direct management responsibility for. In other cases, you may find that your ability to resolve issues is hampered because you are not high enough in the organization to get an issue resolved quickly. In other instances, you may find that your ability to be innovative and flexible is constrained by organizational policies and inertia.

All of these cases can be cause for frustration. One way to deal with this is to define roles and responsibilities as a part of the Project Charter. This can help set and manage expectations. For instance, if you have no budget or expense approval authority, then note that up front, along with a process for expense approval. That way, if problems do arise later, everyone knows who has the right level of authority to resolve them. For most project managers, the frustration level is not caused so much by a lack of power as much as it is caused by ambiguity. If the project manager does not have the authority, it is important to know who does, and what process is needed to gain action.

ref:http://www.lifecyclestep.com/open/407.1TheRoleoftheProjectManager.htm, http://en.wikipedia.org/wiki/Systems_analyst

SAD 1: Assignment # 2

2010-03-17T09:00:00.000-07:00

Interview 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 exlcuding your evidences.

As usual, before I am going to do the task,(chaar) let's first find the meaning of a system analyst. Well, again, as what wikipedia says, a systems analyst 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.

Because they must write user requests into technical specifications, the systems analysts are the liaisons between vendors and the IT professionals of the organization they represent[1] They may be responsible for developing cost analysis, design considerations, and implementation time-lines. They may also be responsible for feasibility studies of a computer system before making recommendations to senior management.

A systems analyst performs the following tasks:

* Interact with the customers to know their requirements
* Interact with designers to convey the possible interface of the software
* Interact/guide the coders/developers to keep track of system development
* Perform system testing with sample/live data with the help of testers
* Implement the new system
* Prepare High quality Documentation

Many systems analysts have morphed into business analysts. As what sir Docdocil said,a system analyst is between technical and business thing. Meaning, a system should know not only in one side but in all things just what is given by the wikipedia. Computer systems analysts start their work by asking people what they need their computers to do. Then, they plan a computer system that can do those tasks well. A system can include many computers working together and different types of software and tools. After analysts understand what the system needs to do, they break down the task into small steps. They draw diagrams and charts to show how information will get into the computers, how that information will be processed, and how it will get to the people who need it. For example, analysts might decide how sales information will get into a store's computers and how the computer will add up the information in a way that makes it useful for store managers. Analysts experiment with different computer system plans. They try various tools and steps until they find the system that is fastest, easiest, and least expensive. Next, analysts decide which computers, software, and tools to buy. They also tell computer programmers how to make any new software that is needed. They give the programmers step-by-step instructions. Some analysts help make the software, too. The main job for some systems analysts is getting computers to work together. They connect them into a network. Analysts decide how to get information from one computer to another. Many help people get data from the Internet. After planning a system, analysts test it to make sure it works. They check to make sure that information is processed quickly and without mistakes. They also watch to see if the system is easy to use. Often, they have to change their plans to make the systems better. Computer systems analysts work in offices or computer labs. Some work from home. Working at the computer for a long time can give these workers eye, back, or wrist problems. Sometimes, these workers work long hours to get a project done on time. Analysts usually work as part of a team.

What do systems analysts do?

The rapid spread of computers has generated a need for highly trained workers to design and develop new hardware and software systems and to incorporate technological advances into new or existing systems. Job titles used to describe the broad category of computer-related occupations evolve rapidly, reflecting new areas of specialization or changes in technology as well as the preferences and practices of employers. Although many narrow specializations exist, this professional specialty group is commonly categorized into computer scientists, computer engineers, and systems analysts. Far more numerous than do computer scientists and computer engineers, systems analysts use their knowledge and skills to solve computer problems and enable computer technology to meet the individual needs of an organization. They study business, scientific, or engineering data processing problems and design new solutions using computers. This process may include planning and developing new computer systems or devising ways to apply existing systems' resources to additional operations. Systems analysts may design entirely new systems, including both hardware and software, or add a single new software application to harness more of the computer's power. They work to help an organization realize the maximum benefit from its investment in equipment, personnel, and business processes. Most systems analysts generally work with a specific type of system depending on the type of organization they work for for example, business, accounting or financial systems, or scientific and engineering systems. Companies generally seek business systems analysts who specialize in the type of systems they use. Analysts begin an assignment by discussing the systems problem with managers and users to determine its exact nature. Much time is devoted to clearly defining the goals of the system and understanding the individual steps used to achieve them so that the problem can be broken down into separate programmable procedures. Analysts then use techniques such as structured analysis, data modeling, information engineering, mathematical model building, sampling, and cost accounting to plan the system. Analysts must specify the inputs to be accessed by the system, design the processing steps, and format the output to meet the users' needs. Once the design has been developed, systems analysts prepare charts and diagrams that describe it in terms that managers and other users can understand. They may prepare cost-benefit and return-on-investment analyses to help management decide whether implementing the proposed system will be financially feasible. When a system is accepted, analysts determine what computer hardware and software will be needed to set it up. They coordinate tests and observe initial use of the system to ensure it performs as planned. They prepare specifications, work diagrams, and structure charts for computer programmers to follow and then work with them to "debug," or eliminate errors from the system. In some organizations a single worker called a programmer-analyst is responsible for both systems analysis and programming. (The work of computer programmers is described elsewhere in the Handbook.) As this becomes more commonplace, these analysts will increasingly work with Computer Aided Software Engineering (CASE) tools and object-oriented programming languages, as well as client/server applications development, and multimedia and Internet technology. Many others specialize in analysis, application, or design of a particular system or piece of the system. Network or systems administrators, for example, may install, configure, and support an organizations systems or portion of a system. Telecommunications specialists generally are involved with the interfacing of computer and communications equipment. Computer security specialists are responsible for planning, coordinating, and implementing an organizations' information security measures. These and other growing specialty occupations reflect the increasing emphasis on client-server applications, the growth of the Internet, the expansion of World Wide Web applications and Intranets, and the demand for more end-user support. An example of this is the growing number of job titles relating to the Internet and World Wide Web such as Internet and Web developers, or Webmasters.

SAD 1: Assignment # 1

2010-01-10T11:23:00.000-08:00

Based on your learnings of chapter 1, identify and discuss some charateristics you have as a good Systems Analyst. (at least 2500 words)

What is a system analyst? Or should I say, Who is/are the system analyst?Defining “system analyst” from wiki, they are the one responsible for researching, planning, coordinating and recommending software and system choices to meet an organization's business requirements. They play important part in the company for a successful development process. They perform lots of task. Included here, they should interact with the customers to know their requirements,interact with designers to convey the possible interface of the software ,interact/guide the coders/developers to keep track of system development perform system testing with sample/live data with the help of testers, implement the new system and prepare high quality documentation.

Ref: http://en.wikipedia.org/wiki/Systems_analyst

In other words, a system analyst is business professional, who uses the techniques of systems analysis
and system design to solve business problems or to facilitate business to gain economically from new business opportunities using the information technology.A good systems snalyst is a precious asset of not only the systems development team, but also of the software development organization. She/he is also an idol in the minds of the juniors and the colleagues and therefore, the future career growth is almost assured. Therefore, cultivating one.s career as a systems analyst is a systematic and self-managed investment for a better future of oneself and of the organization she/he represents. The central task of a systems analyst is to work on the assigned software system development project. However, a systems analyst does a lot of significant work beyond planning and developing programs. She/he has to involve her/him self into the business problems, understand the business strategic issues and recommend technological solution alternatives to the user organization to meet the business goals in spite of the given constraints of budget, time and quality. She/he has to interact with users at various levels and has to demonstrate him/herself as a solution, person to all of them for solving a wide range of business problems.
As a developer the systems snalyst has to perform the following tasks:
A. The systems snalyst has to gather information requirements of the new software system using various techniques.
B. She/he records the information requirements in the form of various models, such as Data Flow Diagrams (DFDs), Entity Relationship Diagrams(ERDs) or Class Diagrams etc. These models in the early stage of systems development help identify ,missing details of requirements, recoding the detailed requirements for future use.
C. Gathering various alternatives for technical environment of the organization for developing and implementing the new software system, comparing them to meet the organizational goals and recommend the best alternative(/s) to the Top Management.
D. For continuing the system development further, the systems snalysts acts as the main link between different development teams, such as Design Team and Testing Team. She/he represents the user requirements domain in the software development project team and the Lead developer as seen by the user groups. She/he is a Friend, a Philosopher and a Guide to the development teams for further
tasks in designing, programming, testing and implementation.

The skills required by a Systems Analyst are listed in different categories as follows:-
A. Technical Knowledge and Skills
B. Business Knowledge and Skills
C. People Knowledge and Skills
D. Integrity and Ethics

A. Technical Knowledge and Skills
a. Though the systems analyst is not required to carry out programming, she/he needs necessary technical expertise to guide and monitor the programming team on one side and to guide the Users on selecting appropriate technological alternatives for the new software system.
b. Fundamental knowledge about the computer hardware, software, operating systems, database management systems, software development phase is required, recent rends and their comparison.
c. The systems snalyst should be well versed with the software system development techniques and tools, such as Integrated Development Environment (IDEs), CASE tools, and other system development tools.
d. In order to complete specific system development activities, the systems analyst needs to know the techniques of project planning, systems analysis, system design, coding and testing , implementation and system support.
B. Business Knowledge and Skills
a. The systems analyst should understand the business organization to be able to solve business problem. In general, therefore, she/he is required to know, the User organization.s activities and business processes, User organization.s structure, Management Styles and Techniques of managing major functions of the organizations, such as Marketing, Finance, Manufacturing, Human Resource Development, Logistics and Distribution etc.
b. The systems analyst should have the knowledge of the industry sector and of the commercial characteristics of that industrial sector, current trends and best business practices in that industry. Eg. Manufacturing industry is segmented broadly into chemical, pharmaceutical, engineering etc, the Services industry into hospitality (eg. hotels, etc.), health care (eg. hospitals, etc.), Tourism industry (eg. pilgrimage tourism, medical tourism, etc.), Financial Services industry (such as mutual funds, share trading etc.) etc. and retailing industry etc. A detailed and recent understanding of these industries would not only help to understand the User.s information requirements quickly but also help understanding the current situations well and recommending useful solution alternatives.
c. The Systems Analyst should understand the specific company, as a User Organization as a whole. The systems analyst should know the business strengths (what it can do better than its competitors?), the organization.scurrent strategies and policies, the traditions and values of the
organizations, etc.
d. The specific information required is who are the Users, their designations,primary responsibilities and role in the software development, etc. It takes very long to know about the organization, bu more the Systems Analyst know ahead of time, more effective is the his/her planning.
e. The Systems Analyst should also know, what is the role of the new software system in the current business strategy (eg. Central or Peripheral? ) and what is the level of significance attached to this software development by the Top Management of the User company. (Highest priority, High, Medium or Low), What are the major business gains the company is aiming to achieve through the use of the new software development system)
C. People Knowledge and Skills
a. A good Systems Analyst should have very strong people skills, since she/he works with people of variety of profiles, and her/his success at work depends a lot upon them she/he works through the people. Therefore, is important to understand how people think, learn, communicate, work at different levels and on variety of tasks, react to change.
b. The systems analyst is required to be good at interpersonal skills, and communication skills to motivate people all over the project teams to cooperate with him/her.
c. The System Analyst is required to be influential person working through various hierarchies of the User organization and Development team.
D. Integrity and Ethics . These are very important aspects of the career of a Systems Analyst for assuring a long term success. Personal integrity of very high level is required. The Systems Analyst refers to very vital information sources while performing his(/er) work. It is important that (s)he follows the User companies privacy policies an procedures very strictly. Eg. certain information resources may be available only for reference and not for photocopying also. Any act of private information.s piracy or theft or even any doubt related to that may harm the career of the Systems Analyst. Some information may be related to persons, such as their salary, medical history etc., it has to be kept confidential. The cpany strategy and policies also need to be kept secret. The integrity and ethical norms are applicable not only for the duration of the software systems development, but
also after it.

ref: http://www.mu.ac.in/sadi.pdf

1.The system analyst must be able to communicate in writing and orally.
Well, system analyst from the word itself, this is one of very difficult thing to do as part in the IT industry for the development process to be successful.He/She must have this four skills which is the analytical, technical, managerial, and interpersonal. And for me, I can communicate with people and also write but not much.Only slight but I can be as good as that if I'm going to let myself do it and learn more.

2. The analyst must easily get along with people. One of the factors to be successful in life is to be with people. Meaning, you have to be an understandable person to which you will feel comfortable to all people you will be dealing of. And as for me, I can't say that I can easily get along with people because sometimes you can't tell exactly that they like you or they understand you. Each of us have unique personality. But I have some of that attitude though. :-)

3. The analyst must be a good listener and be able to react to what people say. In order to have an understanding in every activities, an analyst should be open-minded. Meaning, he/she should be a good listener to which appreciation is a part and give any comments and suggestions if needed to be able to do the task correctly for the development of the company. Well, I am an open-minded person in which I am able to listen what other people will say and able to react if necessary.

4. The analyst must be knowledgeable of technology. The analyst is not expected to know the intricacies of programming, but a decent general knowledge of concepts and terms is essential. I have to admit that I am not as that an intelligent person but I have some knowledge about technology.

5. The analyst must be knowledgeable of business. The analyst is not expected to be an expert in business but a decent understanding of the client's world is required. Hmmm...about business, I know only buy and sell...har2...But a deep one, I have to familiarize and learn more.
Having stated the characteristics of a good systems analyst, it is important to mention that not every one is a born System Analyst. However, with high desire to mould the career systematically and for long term benefits and pleasures of the successful career, a budding Systems Analyst can start cultivating his/her career in this manner today.

_SAD 1:Introduction_

2009-11-29T17:55:00.000-08:00

Hello everyone!

I'm ILYN P. MAPALO taking up Bachelor of Science in Information Technology.I'm 19 years old.I will be one of your classmates in this subject which is SAD 1 or System Analysis and Design 1. From the subject description itself, the very first thing that will come up in your mind is that to expect the unexpected....hehe!For me, this subject will be one of the very challenging,difficult and also a pressure subject in this semester. But even though I said that it is difficult, there's an excitement flows in my veins...chaarmouz!hehe....So, good luck to us and may the LORD BLESS and GUIDE us always...AJAH to us guys!