glexiangmhaya

ten steps for success!

2010-04-08T20:21:00.000-07:00

1 Judge others with kindness
2 Remember to express gratitude
3 Learn to accept criticisms without taking offense
4 Focus on the needs of others
5 Handle interruptions creatively
6 Learn the value of silence
7 Give a little extra
8 Work toward the goal of accepting and loving your self
9 Accept your emotions as valid
10 Accept LIFE

use case diagram of the pre enrollment process of USEP

2010-03-11T23:59:00.000-08:00

GENERAL STRUCTURE

BREAK-DOWN STRUCTURE

Use Case Name: Admission Process
Actors: Aspirant, UGTO Officer and the Cashier
Description: The Use Case describes the flow of event during the admission proper in the university.
Triggering Event: The aspirant arrives to UGTO Office.
Basic Course:

1. Aspirant gets and fill-up form.
2. UGTO Officer receives and checks the form.
3. If correctly filled-up, UGTO provides payment slip
4. Aspirant submits slip and pay bills to cahier.
5. Cashier receives the payment and issue receipt.
6. Aspirant show receipt to UGTO Officer.
7. UGTO Officer assigns examination schedule.
8. Aspirant gets the schedule.
9. End of Use case.

Pre-Condition: none
Post-Condition: The aspirant now has examination schedule.

Use Case Name: Entrance Examination Process
Actors: Aspirant, and Examiner
Description: The Use Case describes the flow of event during the entrance examination proper in the university.
Triggering Event: The aspirant arrives to examination room assigned to her/him.
Basic Course:

1. Examiner checks the validity of aspirant.
2. If valid, aspirant may now take the exam.
3. If done, the examiner assesses the exam.
4. The examiner afterwards generates results.
5. Aspirant gets the exam results.
6. End of use case.
Pre-Condition: The aspirant has his/her assignation for the exam.
Post-Condition: The aspirant has his/her entrance exam result.

Use Case Name: Medical Examination Process
Actors: Aspirant, Clinic In-Charge, Univ. Nurse
Description: The Use Case describes the flow of event during the medical examination proper in the university.

Triggering Event: The aspirant arrives to the clinic.

Basic Course:

1. Aspirant gets and fill-up form.
2. Clinic In-Charge receives and checks the form.
3. If correctly filled-up, aspirant will be check-up by the Univ. Nurse.
4. Univ. Nurse generates Medical Assessment.
5. If passed, aspirant now get the assessment.
6. End of use case.

Pre-Condition: The aspirant passed the entrance examination.
Post-Condition: The aspirant has her/his medical exam result.

Use Case Name: Interview Process
Actors: Aspirant, Interviewer, DEAN
Description: The Use Case describes the flow of event during the interview proper in the university.

Triggering Event: The aspirant arrives to the room allocated for interview.

Basic Course:

1. Aspirant chooses a college and a course.
2. Student must be interviewed.
3. In-charge interviewer conducts the interview.
4. In-charge interviewer assesses the interviewee.
5. If pass, aspirant name will be posted.
6. The result will be seconded by the Dean.
7. End of use case.
Pre-Condition: The aspirant passed the medical examination.
Post-Condition: The aspirant passed the interview and may enroll now as student of the university.

Lightning-fast Internet could be reality

2010-03-10T08:04:00.000-08:00

Cisco Says New Router to "Forever Change the Internet": The Question Is 'When?'

Posted Mar 09, 2010 07:44pm EST by Peter Gorenstein
Reposted Mar 11, 2010 12:08 glecy may dapal

Editor's note: Cisco made headlines today announcing a next generation router that will revolutionize the internet by increasing downloads to unheard of speeds. The Cisco press release makes the following claims about the CRS-3 router:

It enables the entire printed collection of the Library of Congress to be downloaded in just over one second; every man, woman and child in China to make a video call, simultaneously; and every motion picture ever created to be streamed in less than four minutes.

Tech Ticker interviewed Kelly Ahuja, Cisco Senior Vice President and General Manager Service Provider Routing Technology Group about the new product this afternoon. He answered all our questions but one: When will consumers be able to take advantage of this new high speed internet? Perhaps that's because that part of the equation is up to our internet service providers. Until they upgrade it might as well all be a dream.

Below is Kara Swisher's take on the new product.

Provided by All Things D, March 9, 2010:

Cisco today announced a new version of its key routing system, which the networking giant said has a dozen times the traffic capacity of competitors and three times as much as the company’s previous version.

Cisco’s CEO John Chambers said the CRS-3 Carrier Routing System is aimed at the huge growth in video on the Internet, a trend that has also caused slowdowns.

Pankaj Patel, SVP and GM for the service provider business, claimed the system could in just a few minutes deliver all the movies ever made or allow everyone in China to make a video phone call at once.

It had better. The consumption of video online is growing like crazy and a constant bottleneck is likely without some relief.

“Video brings the Internet to life,” said Chambers. “You are moving from a messaging platform to a video platform.”

Along with Chambers and Patel, AT&T (T) Labs CEO and President Keith Cambron was on the call discussing deployment trials the telecom giant has been doing with the CRS-3. CRS-3 (pictured here) will be available within the calendar year, said the Cisco execs on a press and analyst call this morning.

Cisco had said weeks ago that it was making “a significant announcement that will forever change the Internet and its impact on consumers, businesses and governments.”

Significant? We’ll see, of course. For sure, it was a highly hyped announcement by Chambers. But due to the speculation about what Cisco was unveiling, its stock hit a 52-week high yesterday. It dropped slightly this morning after the call.

Many others are getting into the high-speed act on the Web. Google (GOOG) said recently that it is planning on building a superfast broadband service. In addition, the Federal Communications Commission is set to unveil its own ambitious plan to improve high-speed Internet access across the United States.

Cisco has gotten deep into the video business of late, both in pushing its networking gear and in acquiring a video device maker like Pure Digital, the company behind my beloved Flip digital camera.

It is also working on innovative holographic and television-based home telepresence technologies.

Source: http://finance.yahoo.com/tech-ticker/cisco-says-new-router-to-%22forever-change-the-internet%22-the-question-is-%27when%27-438818.html?tickers=CSCO,T,VZ,S,QQQQ,GOOG,^IXIC

an example of an organization that is installing an ERP package

2010-03-09T09:10:00.000-08:00

Here are some typical applications:
Foundries Samples
Work Orders
Pick Tickets
Bills of Lading
Micro-Chips
Computer Print-Outs
Money
Blood Samples
Car Keys

About the Company

You can save a lot of costly steps with an Alpha System. The amount of time and floorspace you cover to move information and materials can add up to lost profit. Alpha cuts down time and distance with the most reliable point-to-point system you'll find anywhere. Plus, Alpha eliminates the risk of hand carrying valuable items in non-secured areas. Jobs that would take a few minutes can be handled in a matter of seconds with the speedy efficiency of an Alpha System

Introduce Yourself to ALPHA! Because Time Is Money!

Alpha is a point to point pneumatic tube system
It moves a carrier containing a commodity between two points in either direction through a single tube
The carrier moves about 25 feet per second
Stations can be up to 2500 to 3000 feet apart or more
Weight that may be carried varies per system; (2"1/4 system - 1lb.) (3"1/4 system - 11/2 lb.) (4"1/4 system - 2lb.)
ALPHA enhances profitability by promoting efficiency.

Using ERP to meet the challenges of running an organisation...

With these insights, it was able to both mobilise and motivate employees and the service provider to work jointly towards the successful implementation. Alpha Pneumatics clearly sets an example for many smaller organizations who are aspiring to implement an ERP.

Using ERP to meet the challenges of running an organisationAlpha Pneumatics is a manufacturing company that is based in Mumbai. This is a company that is engaged in the manufacture of pneumatic tools for pumps and the marine industry, operating on tight margins and a turnover of less than Rs 10 crore.
Before going in for Ebizframe, manual data entry in each department caused major worries for the management as no data, either in sales, purchase or inventory tallied with the actuals at hand. This made decision-making for the management of the company impossible or a huge risk.It got out of hand when technical specifications followed by the production team, suppliers, sub-contractors and customers were not coordinated and went a little haywire. This in turn caused complications what with the supplies and materials taken from sub-contractors. The same lead to rejections from the customer¡¯s side therefore causing cost inputs to increase again.
Challenges of understanding the concepts and quick adaptability by staff during implementation of Ebizframe were tackled well by the team from both sides. All specifications for raw material, semi-finished and finished goods are now incorporated into the system. The turn-around time of delivery against order is reduced by 12 to 15 days. Also, the company has now got the required controls over suppliers and sub-contractors. The company has got clear MIS reports of receivables and payables. As of now, sales (including exports), purchase, inventory, production and finance are live.

Correct, uniform and smoother flow of information across suppliers, sub-contractors and customers caused delight in each due to timely receipts and payments against deliveries with precision. Even dead stock has come down by 18% to 20% of the whole. Stock tracking at inventory and sub-contractor¡¯s site was accurate due to live inventory-related reports. Production processes are streamlined, based on the production advice from sales as per order-bookings made.

[b]Improving communication of an organisation by IT
V venkata rao, professor, IIM AHMEDABAD
ALPHA Pneumatics, the Rs 10-crore-engineering company specialising in manufacture of pneumatic tools has been plagued with the problem of inadequate, inaccurate computer applications. [/b]

Several of these applications were perhaps developed using old technologies, which did not permit the software to share the same data. Hence, when two or more tasks required the same data, the information had to be entered over and over again leading to several mistakes and inconsistencies in the output of different computer applications. For example, the raw materials and components procured or manufactured by the company were not compatible with what was required in the products ordered by the customers.

This led to extreme dissatisfaction among users, who would return what they received from Alpha Pneumatics against their orders placed. Further, Alpha¡¯s systems were not linked appropriately with that of their partners, and hence communication and control between them was poor.

To improve the situation, Alpha purchased and installed the Ebizframe package, which is a web-enabled enterprise resource planning (ERP) solution. The ERP package enables an organisation to store, retrieve and analyse data related to all its activities apart from offering integrated transaction-processing capabilities too. Additionally, the web-enabled package facilitates data exchange between the ERP system and organisation¡¯s allied partners. Because of the integrated nature of the package, a task inputted need not be separately entered, but can be directly retrieved by the system.

Despite the power and promise of an ERP system, its implementation is not easy: successful execution requires a lot of involvement, determination and the will to change on the part of the company. An implementation team consisting of representatives from different departments of the company needs to work closely with the vendor or consultant.

All users need to be trained appropriately in using the system and should be prepared to adopt a new way of processing information required by the package. Looking at the business outcome from the package, Alpha seems to have stood up well to the demands of ERP implementation. The quality and timelines of deliveries have dramatically improved, and the information exchange of Alpha with its partners has yielded the expected results.

Customers could be placing and tracking their orders online. Alpha is not only able to track its purchase and sub-contracting orders online, but also control its suppliers better. Alpha could have gone in for a custom-built solution, instead of an ERP, but such a solution would be long in the making, as the required programming would have to be done from scratch. Besides, a customised solution is costly not to mention that the product may not be the best in terms of quality. Upgrading custom-built solutions is an expensive affair too.

The task at hand for Alpha is to move to the next level of ERP implementation. Functions like human resources and payroll management, equipment maintenance and customer care have not been implemented in the first phase. Further, Alpha needs to analyse the gaps in the ERP package, and close them with appropriate off-line solutions.

Full potential of the web-enabled system can be realised only when all its partners are able to use the features effectively. If necessary, Alpha has to train all its partners in using the ERP.

ERP integrates the factory with the customer
pinakiranjan mishra, associate director, ernst & young
ONE of the most difficult decisions which the relatively small companies face today is whether to implement an ERP. More often than not, ERPs are considered as a solution for the very large companies with complex business processes prevalent in need of improvement.

Contrary to this belief, Alpha Pnuematics, a Rs-10 cr business entity has successfully implemented an ERP to achieve significant improvement in its business. The company recognised the challenges and introduced ERP to overcome issues and gain an edge in the market.

The company realised that technical specifications provided by customers were not accurately translated through Production Planning to Procurement resulting in customer rejections.

It is clear why an ERP works well in such situations. By providing a tight integration between what the factory produces and what a customer orders, modern-day ERPs are able to eliminate the different ¡®¡®views¡¯¡¯ of the same product in various departments. Thereby reducing customer rejections and costs.

This brings us to the larger question¡ª ¡®Can small companies like Alpha Pneumatics actually implement an ERP and gain an edge in the market?¡¯ While there are several issues that organisations can solve through ERP implementation, however it is not an answer to all challenges.

A detailed analysis of the cause of the problems and an evaluation of probable solutions paves the way for the right decision towards ERP implementation. Alpha Pneumatics rightly identified lack of information visibility as a key business issue, which could be addressed by ERP. The second issue was to understand what an ERP could offer and how quickly the company could adapt to the changed processes and measures.

This is critical especially for SMEs as the margin of error is small. If the implementation takes longer than expected or the employees are not able to adapt to the new envronment, the same ERP could end up being a drain on the company¡¯s resources. Thirdly, it is also important to implement the core business processes together as an ERP is an enterprise-wide solution.

There is little value in piecemeal implementation since it gets limited just to automation or computerization of existing processes and information. For Alpha Pneumatics, the key to success was to indentify and integrate the core processes viz. Sales, Purchase, Inventory, Production and Finance.

This ensured one version instead of multiple versions of truth. Decision-making not only improved, but the credibility of the decisions was also high. In conclusion, many decisions which Alpha took for its ERP implementation were right, thereby resulting in a successful experience. The company selected a solution based on its size and requirement. Further, they clearly understood the business linkages and how an ERP could help establish them.

With these insights, it was able to both mobilise and motivate employees and the service provider to work jointly towards the successful implementation. Alpha Pneumatics clearly sets an example for many smaller organizations who are aspiring to implement an ERP.

Sources:

http://www.alphapneumatics.com/
http://www.eworksglobal.com/cases_127950691293906250.htm

defining deployment environment

2010-03-03T08:00:00.000-08:00

Defining the Deployment Environment

Analysts consider the configuration of computer equipment, operating systems, and networks that will exist when the new application system is deployed.
Application architecture designs exist as models, documents, and scenarios. However, applications must be deployed into a physical environment where infrastructure limitations may negate some of the architectural decisions. Therefore, you must consider the proposed deployment scenario and the infrastructure as part of your application design process.

It is needed to describe the options available for deployment of different types of applications, including distributed and non-distributed styles, ways to scale the hardware, and the patterns that describe performance, reliability, and security issues. By considering the possible deployment scenarios for your application as part of the design process, you prevent a situation where the application cannot be successfully deployed, or fails to perform to its design requirements because of technical infrastructure limitations.

Once you define systems, you must specify information about the deployment environment, including the database, match engine, and standardization engine vendors.

In choosing or defining deployment environment you must:

1.Identify the deployment pattern or strategy used.

Deployment Strategy

The target deployment environment for an application may already be rigidly defined, and so the application design must reflect the restrictions. Sometimes design tradeoffs are required; for example, because of protocol or port restrictions, or specific deployment topologies. Identify constraints early in the design phase to avoid surprises later, and involve members of the network and infrastructure teams to help with this process. General recommendations are:
Know your target physical deployment environment early, from the planning stage of the lifecycle.

Clearly communicate the environmental constraints that drive software design and architecture decisions.

Clearly communicate the software design decisions that require certain infrastructure attributes.

Non-Distributed Deployment

A non-distributed deployment is where all of the functionality and layers reside on a single server except for data storage functionality.
This approach has the advantage of simplicity and minimizes the number of physical servers required. It also minimizes the performance impact inherent when communication between layers has to cross physical boundaries between servers or server clusters.

A non-distributed deployment does have some disadvantages:

The processing requirements of the layers differ. For example, the presentation layer must cope with multiple concurrent users and short bursts of activity, while the business and data layers should be optimized to deal with a steady stream of requests from a limited number of callers. Processing on one layer could absorb sufficient resources to slow the processing in other layers.
The security requirements of the presentation layer may differ from those of the business and data layers. For example, the presentation layer will not store sensitive data, while this may be stored in the business and data layers.
It is difficult to share business logic between applications.

Distributed Deployment

A distributed deployment is where the layers of the application reside on separate physical tiers. Distributed deployment allows you to separate the layers of an application on different physical tiers as shown in the following figure.

This approach allows you to configure the application servers that host the various layers to best meet the requirements of each layer. Distributed deployment also allows you to apply more stringent security to the application servers; for example, by adding a firewall between the Web server and the applications servers and by using different authentication and authorization options.

In rich client applications, the client may use Web services exposed through a Web server, or may access functionality in the application server tier using DCOM or Windows Communication Foundation (WCF) services.

Distributed deployment provides a more flexible environment where you can more easily scale out or scale up each physical tier as performance limitations arise, and when processing demands increase.

Performance and Design Considerations for Distributed Environments

Distributing components across physical tiers reduces performance due to the cost of remote calls across server boundaries. However, distributed components can improve scalability opportunities, improve manageability, and reduce costs over time.

Consider the following guidelines when designing an application that will run on a physically distributed infrastructure:

Choose communication paths and protocols between tiers to ensure that components can securely interact with minimum performance degradation.
Use services and operating system features such as distributed transaction support and authentication that can simplify your design and improve interoperability.
Reduce the complexity of your component interfaces. Highly granular interfaces ("chatty" interfaces) that require many calls to perform a task work best when on the same physical machine. Interfaces that make only one call to accomplish each task ("chunky" interfaces) provide the best performance when the components are distributed across separate physical machines.
Consider separating long-running critical processes from other processes that might fail by using a separate physical cluster.
Determine your failover strategy. For example, Web servers typically provide plenty of memory and processing power, but may not have robust storage capabilities (such as RAID mirroring) that can be replaced rapidly in the event of a hardware failure.
Take advantage of asynchronous calls, one-way calls, or message queuing to minimize blocking when making calls across physical boundaries.
How best to plan for the addition of extra servers or resources that will increase performance and availability.
Recommendations for locating components within a distributed deployment
Consider the following guidelines when determining where to locate components in a distributed environment:
Only distribute components where necessary. Common reasons for implementing distributed deployment include security policies, physical constraints, shared business logic, and scalability.

In Web applications, deploy business components that are used synchronously by user interfaces or user process components in the same physical tier as the user interface to maximize performance and ease operational management.
Don’t place UI and business components on the same tier if there are security implications that require a trust boundary between them. For instance you may wish to separate business and UI components in a rich client application by placing UI on the client and business components on the server.
Deploy service agent components on the same tier as the code that calls the components, unless there are security implications that require a trust boundary between them.

Deploy asynchronous business components, workflow components, and business services on a separate physical tier where possible.
Deploy business entities on the same physical tier as the code that uses them.

2. Consider Design Implications and Tradeoffs Up Front

You need to consider aspects of scalability that may vary by application layer, tier, or type of data. Know your tradeoffs up front and know where you have flexibility and where you do not. Scaling up and then out with Web or application servers may not be the best approach. For example, although you can have an 8-processor server in this role, economics would probably drive you to a set of smaller servers instead of a few big ones. On the other hand, scaling up and then out may be the right approach for your database servers, depending on the role of the data and how the data is used. Apart from technical and performance considerations, you also need to take into account operational and management implications and related total cost of ownership costs.

3. Examine Stateless Components

If you have stateless components (for example, a Web front end with no in-process state and no stateful business components), this aspect of your design supports scaling up and out. Typically, you optimize the price and performance within the boundaries of the other constraints you may have. For example, 2-processor Web or application servers may be optimal when you evaluate price and performance compared with 4-processor servers; that is, four 2-processor servers may be better than two 4-processor servers. You also need to consider other constraints, such as the maximum number of servers you can have behind a particular load-balancing infrastructure. In general, there are no design tradeoffs if you adhere to a stateless design. You optimize price, performance, and manageability.

4. Know the type of Data

For data, decisions largely depend on the type of data:
Static, reference, and read-only data. For this type of data, you can easily have many replicas in the right places if this helps your performance and scalability. This has minimal impact on design and can be largely driven by optimization considerations. Consolidating several logically separate and independent databases on one database server may or may not be appropriate even if you can do it in terms of capacity. Spreading replicas closer to the consumers of that data may be an equally valid approach. However, be aware that whenever you replicate, you will have a loosely synchronized system.
Dynamic (often transient) data that is easily partitioned. This is data that is relevant to a particular user or session (and if subsequent requests can come to different Web or application servers, they all need to access it), but the data for user A is not related in any way to the data for user B. For example, shopping carts and session state both fall into this category. This data is slightly more complicated to handle than static, read-only data, but you can still optimize and distribute quite easily. This is because this type of data can be partitioned. There are no dependencies between the groups, down to the individual user level. The important aspect of this data is that you do not query it across partitions. For example, you ask for the contents of user A's shopping cart but do not ask to show all carts that contain a particular item.
Core data. This type of data is well maintained and protected. This is the main case where the "scale up, then out" approach usually applies. Generally, you do not want to hold this type of data in many places due to the complexity of keeping it synchronized. This is the classic case in which you would typically want to scale up as far as you can (ideally, remaining a single logical instance, with proper clustering), and only when this is not enough, consider partitioning and distribution scale-out. Advances in database technology (such as distributed partitioned views) have made partitioning much easier, although you should do so only if you need to. This is rarely because the database is too big, but more often it is driven by other considerations such as who owns the data, geographic distribution, proximity to the consumers and availability.

5. Consider Database Partitioning at Design Time

If your application uses a very large database and you anticipate an I/O bottleneck, ensure that you design for database partitioning up front. Moving to a partitioned database later usually results in a significant amount of costly rework and often a complete database redesign.

Partitioning provides several benefits:

The ability to restrict queries to a single partition, thereby limiting the resource usage to only a fraction of the data.
The ability to engage multiple partitions, thereby getting more parallelism and superior performance because you can have more disks working to retrieve your data.
Be aware that in some situations, multiple partitions may not be appropriate and could have a negative impact. For example, some operations that use multiple disks could be performed more efficiently with concentrated data. So, when you partition, consider the benefits together with alternate approaches.

6. Network Infrastructure Security Considerations

Make sure you understand the network structure provided by your target environment, and understand the baseline security requirements of the network in terms of filtering rules, port restrictions, supported protocols, and so on. Recommendations for maximizing network security include:
Identify how firewalls and firewall policies are likely to affect your application's design and deployment. Firewalls should be used to separate the Internet-facing applications from the internal network, and to protect the database servers. These can limit the available communication ports and, therefore, authentication options from the Web server to remote application and database servers. For example, Windows authentication requires additional ports.
Consider what protocols, ports, and services are allowed to access internal resources from the Web servers in the perimeter network or from rich client applications. Identify the protocols and ports that the application design requires and analyze the potential threats that occur from opening new ports or using new protocols.
Communicate and record any assumptions made about network and application layer security, and what security functions each component will handle. This prevents security controls from being missed when both development and network teams assume that the other team is addressing the issue.
Pay attention to the security defenses that your application relies upon the network to provide, and ensure that these defenses are in place.
Consider the implications of a change in network configuration, and how this will affect security.

7. Manageability Considerations

The choices you make when deploying an application affect the capabilities for managing and monitoring the application. You should take into account the following recommendations:
Deploy components of the application that are used by multiple consumers in a single central location to avoid duplication.
Ensure that data is stored in a location where backup and restore facilities can access it.
Components that rely on existing software or hardware (such as a proprietary network that can only be established from a particular computer) must be physically located on the same computer.
Some libraries and adaptors cannot be deployed freely without incurring extra cost, or may be charged on a per-CPU basis, and therefore you should centralized these features.
Groups within an organization may own a particular service, component, or application that they need to manage locally.
Monitoring tools such as System Center Operations Manager require access to physical machines to obtain management information, and this may impact deployment options.
The use of management and monitoring technologies such as Windows Management Instrumentation (WMI) may impact deployment options.

Sources:

http://www.codeplex.com/wikipage?ProjectName=AppArchGuide&title=Chapter+5+-+Deployment+Patterns&referringTitle=Home

http://apparchguide.codeplex.com/wikipage?title=Chapter%205%20-%20Deployment%20Patterns

http://developers.sun.com/docs/javacaps/designing/jcapsdevsmidxm.dsgn_eview-deployment_t.html

Best Laptops and Desktops of 2010

2010-03-02T02:42:00.000-08:00

link here: http://shopping.yahoo.com/articles/yshoppingarticles/344/best-laptops-and-desktops-of-2010/

evaluating quality data flow diagram

2010-02-21T04:02:00.000-08:00

Definition

Use a Data Flow Diagram (DFD) to show the relationships among the business processes within an organization to:

external systems,

external organizations,

customers,

other business processes.

In evaluating the quality of a data flow diagram, the following characteristics and standard must be meet or considered. The methods, components and the structure of a data flow diagram must be well followed as what is stated below.

Method

Data flow diagrams are used to describe how the system transforms information. They define how information is processed and stored and identify how the information flows through the processes.

When building a data flow diagram, the following items should be considered:

where does the data that passes through the system come from and where does it go,

what happens to the data once it enters the system (i.e., the inputs) and before it leaves the system (i.e., the outputs),

what delays occur between the inputs and outputs (i.e., identifying the need for data stores).

COMPONENTS

Whatever convention is used to construct the Data Flow Diagram, all DFDs are composed of the following components:

→EXTERNAL ENTITIES

External entities are also known as terminators, sources/sinks, and actors. External entities define the sources and destinations of information entering and leaving the system. An external entity can be a person, system, or organization that has pre-defined behaviour.

External entities are mandatory on context diagrams but optional on data flow diagrams.

Description

External entities are components that interact with a business process on the DFD but fall outside of the boundaries of the DFD.

External entities can be:

initiators of data (i.e., spontaneous generators) flowing into the business process,

end recipients of data (i.e., data sinks) flowing from the business process.

→ FLOWS

Definition

Flows define the interfaces between the components within the system, and the system and its external components.

Types of Flows

Flows that transport data around the data flow diagram are called data flows.

Description of Data Flows

Data flows are the pipelines through which data are transmitted between any two components on a DFD. The composition of data is known and defined in a data dictionary.

A data flow is also called a data flow vector.

Examples of data flows are:

purchase order,

customer profile,

account number,

product.

Naming Data Flows

Data flows must be given a name that describes the content of the data being transmitted and a description of the data flow listing the data elements.

Data Flows with the Same Name

Multiple data flows can have the same name on a DFD. When this occurs, the data transmitted in all of the flows with the same name must be identical.

Complex Data Flows

Data flows are described as complex when there is more than one data flow going in the same direction between any two entities.

Name the complex data flow to encompass the contents of all the data flowing along the pipeline.

Trivial Data Flows

DFDs do not show trivial (relative to the specification of functional requirements) flows, such as error messages, keys for retrieving data from a data store, or data store updating instructions.

Guidelines for Drawing Data Flows on a DFD

Connect the data flows from/to external entities to/from business processes within the boundary of the DFD.

Connect internal business processes to data stores and other internal processes with appropriate data flows.

Label all data flows with care for they indicate the interface requirements for a process. Use descriptive names for labelling data flows.

Ensure that all flows to external entities on lower level diagrams balance with data flows from external entities on upper level diagrams.In other words, a new data flow cannot be created at a lower level if it was not identified on an upper level diagram.

Double-headed data flows are permitted when the data flowing in both directions are identical.

Data flows from/to external entities to/from data stores are not permitted.All data must flow through a process.

Be careful not to produce long names for complex data flows.

As a rule of thumb, a DFD component (process, data store, or external entity) should not have more than seven data flows connected to it.

Flows that access stored data are called access flows.

Flows that are used to synchronize the system control flow and do not require data are called event flows. Common uses include starting, stopping, and changing the system status. Event flows are also known as control flows.

Flows can be continuous or discrete. A discrete flow is only present for an instant of time. A continuous flow persists over time.

A data flow name should be a singular noun phrase (e.g., delivery list, customer information, credit limit).

Naming access flows is optional.

An event flow name should be a singular verb or noun phrase (e.g., start, stop, item available, processing complete).

If a data flow contains multiple attributes (i.e., data elements), an attribute list should be provided.

→ STORES

Definition

Stores represent information (i.e., data or control) at rest. Stores are used when different processes need to share information but are active at different times. Information can be written to a store and read from a store.

Types of Stores

Stores that contain data are called data stores.

DATA STORES ON A DFD

Identifying Data Stores

Data stores are usually derived from the entities in an entity-relationship diagram.

Creation of Data Stores

Data stores are created to store information for later use. They represent data that is temporarily at rest between processes. For example, a data store is needed to store data that is generated on a daily basis but is required for a process that runs weekly.

Local and Shared Data Stores

Local data stores are data stores whose accesses are contained completely within the boundary of a DFD.

A data store crossing the boundary of a DFD process indicates that it is shared by processes on another DFD.

Drawing Data Stores on a DFD

A data store can be drawn on the same DFD more than once to reduce the visual complexity of the drawing. An extra vertical bar is drawn in the duplicated data stores to indicate that it appears elsewhere on the same diagram.

Stores that contain status or control information are called event stores.Event stores are used to save events that have occurred but have not yet been used. Unlike a data store, an event store has behaviour associated with it which is not apparent when looking at the data flow diagram.If the system accesses an event store and the event has not occurred, the system will be suspended until the event occurs.Once an event has occurred, accessing it will remove it from the event store.

Guidelines

The data stores on the data flow diagram map to the entities on the entity-relationship diagram.

Minimize the use of event stores on the DFD. Try using flags instead.

→ PROCESSES

Definition

Processes are also known as data transforms. Processes transform input flows into output flows in a defined manner.

A process is a distinct activity (or set of activities) described by its inputs and outputs. A process describes a unique behaviour that has a beginning and an end.A process is performed repeatedly.

Types of Processes

A data process transforms input data into output data. Data processes act directly on data, either from flows or stores.They represent the functionality of the system.

A control process transforms input events into output events and is used on a data flow diagram to indicate the presence of a state transition diagram. Control processes cannot transform data but can control processes that do. A state transition diagram describes the behaviour of the control process.

Guidelines

A process name and number must be unique. A process can only exist once on a data flow diagram.

A process must have at least one input and one output. In other words, a process is asked (i.e., triggered) to do something and then must deliver (i.e., respond).

A data process cannot input or output discrete event flows (i.e., a data process should not control the system, it should do the work).

A control process cannot input or output data flows (i.e., a control process should control the system, not do the work).

A process name should start with an active verb (e.g., Produce Items, Control Production).

A process exists to do something (i.e., transform input flows into output flows), therefore a process must have an incoming set of requirements to which it must conform.

An nth-level (i.e., next level of detail) data flow diagram must describe its parent process. An nth-level data flow diagram is a decomposition of its parent process and cannot introduce new functionality.

STEPS TO DRAW A DATA FLOW DIAGRAM

Steps

Start from the context diagram. Identify the parent process and the external entities with their net inputs and outputs.

Place the external entities on the diagram. Draw the boundary.

Identify the data flows needed to generate the net inputs and outputs to the external entities.

Identify the business processes to perform the work needed to generate the input and output data flows.

Connect the data flows from the external entities to the processes.

Identify the data stores.

Connect the processes and data stores with data flows.

Apply the Process Model Paradigm to verify that the diagram addresses the processing needs of all external entities.

Apply the External Control Paradigm to further validate that the flows to the external entities are correct.

Continue to decompose to the nth level DFD. Draw all DFDs at one level before moving to the next level of decomposing detail.

You should decompose horizontally first to a sufficient nth level to ensure that the processes are partitioned correctly; then you can begin to decompose vertically.

Sources:

http://it.toolbox.com/blogs/enterprise-solutions/components-of-data-flow-diagrams-14497

http://it.toolbox.com/blogs/enterprise-solutions/data-flow-diagrams-dfds-14573

Data Flow Diagrams

2010-02-18T11:34:00.000-08:00

DATA FLOW DIAGRAMS

CONTEXT DIAGRAM of Pre-Enrollment Process in USEP

LEVEL-0 Data Flow Diagram of Pre-Enrollment Process in USEP

PRIMITIVE Data Flow Diagram

*kindly assume that all the diagrams shown below are presented as one picture
in which the student is pertaining to the same student presented in the other
processes.

Admission Process

Entrance Examination Process

Medical Examination Process

Interview Process

ActivityDiagram&UseCaseDescriptionPreEnrollment

2010-02-11T07:52:00.000-08:00

Commonly, a pre-enrollment system is divided in different processes which is impost by the organization.
Now, with the university pre-enrollment system, it has been observed that there are four major processes to take up. Namely Admission,Entrance,Medical and Interview.

The student will initially undertake the Admission process in which the student must get and fill-up the form provided by the UGTO in-charge, then pass to them the form.
After checking and assuring that the student filled-up properly the form, the UGTO in-charge will issue a payment slip for examination payment. The student now will
proceed to Cashier to lend the slip as well as the payment. The cashier in-charge will issue a receipt then this will be shown to UGTO in-charge that allows them to issue
the examination schedule for the student. After this, the Admission process is done already.

The student can now proceed to Entrance Examination Process in which the assigned examiner will check and assure the validity of the student. Then the student can now
take the exam. After the exam, the examiner asses and generate results of the exam. If the student pass the exam then the Entrance Examination is done already.

The student can now proceed to Medical Process in which the student will get and fill-up a form that will be collected as they enter the clinic.
The clinic in-charge check and assure that the form is correctly filled-up. Then the student will be check up by the University nurse.
After that, the attending nurse will generate a medical assessment. If the student is healthy. Then the Medical Process is done already.

The student now can choose a college/course and be interviewed. Each college/department has assigned teachers for the interview. After assessing the interviewee
The assigned interviewer will generate results.If the student failed, the student will repeat the Interview process in other department.
if the student pass the interview, it will be seconded by the college dean. Then, the interview process is done already. Thus, the student have just finished the entire
pre-enrollment process.

Consider USEP's pre-enrollment system, develop a use case diagram and write a brief use case description.

2010-02-04T21:51:00.000-08:00

Use case description for Admission:

1.) Student get an application form from UGTO officer
2.) UGTO officer provide the form
3.) Student pay entrance examination fee at the Finance Dept
4.) The cashier receives the payment and issue reciept
5.) Student accepts the the receipt from cashier
5.) Student give the receipt and form to the UGTO officer
6.) UGTO recieves it and issue the examination schedule to the student

Use case description for the Entrance Examination:

1.) Student take the exam
2.) Assigned personnel check the validity of the examinee
3.) Student get the result

Use case description for the Interview:

1.) Student choose a college
2.) In-charge teacher will interview the student
3.) In-charge teacher will give result

Use case for Medical Certification:

1.) Student go to clinic
2.) clinic personnel gives form
3.) Student will fill-up form then give it to the in-charge
4.) Student will be examine by the clinic nurse and dentist.
5.) In-charge will give the result
6.) Student receive it

Use case for Pre-Enrollment:
1.) Student pay miscellaneous fee to OCSC,HeadLight.
2) OCSC,Headlight in-charge issue receipt
3.) Student receive the reciept
4.) receipt will be shown to in-charge advicer of the college
5.) in-charge teacher will give you pre-enrollment form.

Juan and Pedro Dialogue

2010-01-29T20:03:00.000-08:00

The analysis phase defines the requirements of the system, independent of how these requirements will be accomplished. This phase defines the problem that the customer is trying to solve. The analysis phase provide a general idea of the shape of the new
system. The deliverable result at the end of this phase is a requirement document. Ideally, this document states in a clear and precise fashion what is to be built. This analysis represents the ``what'' phase. The requirement document tries to capture the requirements from the customer's perspective by defining goals and interactions at a level removed from the implementation details.

The flow of the conversation:

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

As Juan initialize the discussion, he said that to start the analysis for the new system, an assessment of the old or current system is needed so that he could figure out the flow and through this he could point out what part of the system is working efficiently and which is not. I think Juan wants to follow the standard in implementing this phase in which I find it proper.

“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.”

The manager, Pedro made an emphasis with his angst that the system Juan is planning will be just the same with their previous developed systems in which they find it unsatisfactory. I think this initial reaction must be expected from the client.

”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.”

I think Juan deserves credit for giving an assurance to the client that his fear will not knock him anymore. And it is a good strategy that Juan still insist his goal in a nice way in spite of the pressure he received from the manager.

“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.”

In this response, I can say that the manager knows what he really wants to be done. The manager shows that he is really particular on changing the entire system they are currently using not just do some changes on it. It seems that the manager is constantly reminding Juan about this. As to the systems people, that’s very helpful for them because determination of requirements for that certain project will not be that hard anymore. And reminders will give Juan his standards.

I sympathize with the manager, because if I am the manager it is fair to set and demand what I want for the system that will be implemented soon in my company. However, I will also consider that the systems analyst is foreseeing to fill what I want. Being just particular is a big challenge for them. More than that, gathering the requirements with the cooperation of the manager will set as a catalyst to make the system analysis phase be efficient and effective, a good indication for a success.

But even if I sympathize to the manager, I think following the standard requirements analysis methods will be more suitable. Having consideration in terms of new recommended methods from clients will not be a hindrance to this phase instead gives new ideas to improve the basic methods and finally provides result that satisfies both parties.

Additional Brain Feeding…
System Analysis
In this phase, the current system is studied in detail. A person responsible for the analysis of the system is known as analyst. In system analysis, the analyst conducts the following activities.
Needs Analysis
This activity is known as requirements analysis. In this step the analyst sums up the requirements of the system from the user and the managers. The developed system should satisfy these requirements during testing phase.
Data Gathering
In this step, the system analyst collects data about the system to be developed. He uses different tools and methods, depending on situation. These are:
Written Documents
The analyst may collect the information/data from written documents available from manual-files of an organization. This method of data gathering is normally used if you want to computerize the existing manual system or upgrade the existing computer based system. The written documents may be reports, forms, memos, business plans, policy statements, organizational charts and many others. The written documents provide valuable information about the existing system.
Interviews
Interview is another data gathering technique. The analyst (or project team members) interviews, managers, users/ clients, suppliers, and competitors to collect the information about the system. It must be noted that the questions to be asked from them should be precise, relevant and to the point.
Questionnaires
Questionnaires are the feedback forms used to collect Information. The interview technique to collect information is time-consuming method, so Questionnaires
are designed to collect information from as many people as we like. It is very convenient and inexpensive method to collect information but sometimes the response may be Confusing or unclear and insufficient.
Observations
In addition to the above-mentioned three techniques to collect information, the analyst (or his team) may collect Information through observation. In this collect technique, the working, behavior, and other related information of the existing system are observed. It means that working of existing system is watched carefully.
Sampling
If there are large numbers of people or events involved in The system, we can use sampling method to collect information. In this method, only a part of the people or events involved are used to collect information. For example to test the quality of a fruit, we test a piece of the fruit.
Data Analysis
After completion of â€œData Gatheringâ€ step the collected data about the system is analyzed to ensure that the data is accurate and complete. For this purpose, various tools may be used. The most popular and commonly used tools for data analysis are:
• DFDs (Data Flow Diagrams)
• System Flowcharts
• Connectivity Diagrams
• Grid Charts
• Decision Tables etc.

Analysis Report
After completing the work of analysis, the requirements collected for the system are documented in a presentable form. It means that the analysis report is prepared. It is done for review and approval of the project from the higher management. This report should have three parts.
• First, it should explain how the current system works.
• Second, it should explain the problems in the existing system.
• Finally, it should describe the requirements for the new system and make recommendations for future.

The analysis phase is the building block of a training program. The basis for who must be trained, what must be trained, when training will occur, and where the training will take place are accomplished in this phase. The product of this phase is the foundation for all subsequent development activities.
The analysis phase is often called a Front-End Analysis. That is, although you might perform analysis throughout the ISD process, such as in the design and development phases, this "front end" of the ISD process is where the main problem identification is performed.
When performing an analysis, it is best to take a long term approach to ensure that the performance improvement initiative ties in with the organization's vision, mission, and values. This connects each need with a metric to ensure that it actually does what it is supposed to do. This is best accomplished by linking performance analysis needs with Kirkpatrick's Four Levels of Evaluations, which means their are four categories of analysis (Phillips, 2002):
• Business Needs are linked to results
• Job Performance Needs are linked to behavior
• Training Needs are linked to learning
• Individual Needs are linked to reaction
Business Needs
Investigate the problem or performance initiative and see how it supports the mission statement, leader's vision, and/or organizational goals, etc. Fixing a problem or making a process better is just as good as an ROI, if not better. Organizations that focus strictly on ROI are normally focusing on cost-cutting. And you can only cut costs so far before you start stripping out the core parts of a business. A much better approach is to improve a performance or process that supports a key organization goal, vision, or mission.
When senior executives were asked the most important training initiatives, 77% cited, "aligning learning strategies with business goals"; 75% cited, "ensuring learning content meets workforce requirements"; and 72%, "boosting productivity and agility" (Training Magazine, Oct 2004). Thus, senior leadership is not looking at training to be a profit center (that is what other business units are for), rather they are looking at performance improvement initiatives to help "grow" the organization so that it can reach its goals and perform its mission.
The goal is to make an impact or get some sort of result. So once you have identified the gap between present performance and the organization's goals and vision; create a level 4 evaluation (impact) that measures it -- that is, what criteria must be met in order to show that the gap has actually been bridged?
Job Performance Needs
While the first analysis looked at business needs, this analysis looks at the job performance needs and these two needs could slightly differ. The first need, business, often has a slightly more visionary or future look to it, while the job performance need normally looks at what is needed now. Thus, business needs often tend to be more developmental in nature (future orientated), while job performance needs are normally more related towards the present.
This is perhaps the most important need to look at as it links the performer with the organization. When analyzing job performance, you want to look at the entire spectrum that surrounds the job: processes, environment, actual performance verses need performance, etc, thus it often helps to divide the analysis into three groups: people, data, and things.
Training Needs
As you assess the performance for any needed interventions, look at the Job/Performer requirements, that is, what the performer needs to know in order for the performance intervention to be successful. In addition, look at how you are going to evaluate any learning requirements (level 2). It is one thing to determine the learning needs (skill, knowledge, & self system [attitude, metacognition, etc.]), but it is quite another thing to ensure that those requirements actually take place.
Individual Needs
It ensures that the performance intervention actually conforms to the individual requirements. For example, in the Training Needs analysis, it might be determined that the job holders need to learn a new process. In this need analysis, the target population is looked at more closely to determine the actual content, context, and delivery method of the performance intervention.

The goal of systems analysis is to determine where the problem is in an attempt to fix the system. This step involves breaking down the system in different pieces and drawing diagrams to analyze the situation, analyzing project goals, breaking need to be created and attempting to engage users so that definite requirements can be defined. Requirement Gathering sometimes require individual/team from client as well as service provider side to get a detailed and accurate requirements.

During the Detailed Analysis, the Project Manager and the System Development Manager work closely together to:
a. Complete business process engineering of the functions to be supported,
b. Complete component selection.
c. Develop detailed data and process models,
d. Refine functional and system requirements that are not easily expressed in data and process models,
e. Refine the high level architecture and logical design to support the system, functional, and electronic records management requirements,
f. Continue to identify and mitigate risk that the technology can be phased-in and coordinated with the business.
There are three key reviews during the Detailed Analysis and Design Phase: the Detailed Level Requirements Review, Logical Design Review, and the Technical Design Review. This phase is completed when the Technical Review Board approves the high level architecture and system requirements, revised economic analysis, the logical design including the business process description, and the technical design. This approval is provided at these three reviews.
Detailed logical models of business data and processes needed to guide system development are created in the Detailed Analysis and Design Phase, and a description of the technical architecture is refined to guide the allocation of computing resources and capabilities. When practicable, the deployment of the new AIS should be planned to coincide with the implementation of new business processes and procedures. The Project Manager and the System Development Manager should continue to assess both business and technical risks and seek additional management support as necessary to manage those risks. Both the Project Manager and the System Development Manager may wish to document project risks and risk management activities in a risk management matrix for future reference.

The primary tasks performed during the Detailed Analysis and Design Phase are as follows:
a. Consolidate and affirm business needs,
b. Implement AIS project management infrastructure including requirements, configuration, and data management support services and utilities,
c. Revise plans to document changes in project scope including changes in business, schedule, and technical requirements,
d. Revise plans to document changes in available resources including budget, skills, staff, and training,
e. Update list of candidate reuse components, and complete reuse component selection.
f. Complete electronic records management requirements,
g. Identify data acquisition, conversion, and validation strategies,
h. Refine the technical architecture and build architectural prototype,
i. Identify design tools, techniques, and procedures,
j. Perform detailed AIS analysis and design, and
k. Continue planning for AIS testing, training, deployment, operation and business transition, and
l. Define and refine detailed requirements and allocate requirements to design.

Detailed Analysis activities and documentation requirements as summarized in the following table must conform to the indicated Technical Standard and Guidelines or other standards as noted.

Business requirements are intended to state in a concise, complete, and unambiguous manner what the system must do to meet business needs. Business requirements should not introduce unnecessary design assumptions or technical constraints. In this phase, the high level data and functions defined in the Concept Phase are transformed into a detailed description from which the system can be developed. This description will use a combination of textual and graphical representations to express the requirements in a form that users can readily understand. The functional, data, and support requirements must be approved by the Program Sponsor. Direct involvement of supported users and business area experts is essential to developing functional and data requirements. Requirements Management, for a description of the requirements definition process and documentation requirements.

Special attention must be given to reducing any adverse impact that may result from the transition process. Project Managers should prepare their organization to effectively cope with change by building consensus among key personnel in affected groups. This can be accomplished by establishing more effective communications with internal and external
customers, effectively managing labor relations through early and frequent communications, and by openly discussing anticipated changes with employees.
The Detailed Design must comply with the technical architecture:
a. Define the hardware, software, and network components in which the AIS will operate,
b. Show how functional, data, and electronic records management requirements will be allocated among these components, and
c. Describe the means used to interconnect these components.
Characteristics of the detailed design specified during the Detailed Analysis and Design Phase should establish confidence that the system components, when integrated, will meet all functional, performance, and support requirements. The detailed design establishes a level of uniformity for further AIS design and development. Architectural limitations, such as the ability to handle changing user needs, increased performance, and upward compatibility to new technologies, must be determined, and if necessary, classified as project risks.

The Detailed Design must:
a. Allow for maximum automated generation of application-specific code and databases using the CASE tool.
b. Allow for maximum reuse of existing system components.
c. Employ COTS software products wherever economically feasible.
d. Ensure that the application software can be processed on hardware and system software that is either currently available in the USPTO inventory or has been approved for acquisition and delivery in sufficient lead-time to allow for use during the test process of the Development Phase.
e. Provide for the collection of performance metrics.
f. Provide for including designer added software capabilities for internal controls to facilitate functional and technical audits of the AIS.
g. Specify functional and technical requirements for integration of the AIS with other PTO business processes, as needed.

Analysis should come early in any project, and the most important part of that analysis is the gathering of business requirements. Learn about product and process requirements and how to effectively determine and prioritize customer needs.
Most developers like to follow the Nike creed: Just do it! The customer comes to us with a business need, and we immediately move into problem-solving mode. We want to jump in and start writing code. There is no better feeling than completing an application and showing the customer. Until, of course, the customer informs us that this is not quite what he or she had in mind.

Developers can sometimes forget that the first phase of any development project is gathering business requirements to understand what the customer wants. It is only when we agree on the business needs that we can move on to the fun stuff—design and construction.

This is the first of five articles that look at some of the main concepts of the analysis phase:
• What business requirements are
• How to gather business requirements
• Process modeling
• Data modeling
• Conceptual systems design

At the end of this series, you should have a good sense of what the analysis phase of a large project might include. As always, not all of these concepts need to be applied to all projects. But once you know what the analysis phase may include, you can make a well-informed decision about what to include with your project.
It's all about requirements
Gathering business requirements is the main purpose of the analysis phase. Business requirements are statements that describe what the customer and major stakeholders need and want. If you are automating a business process, the requirements describe the way the process should work. If you are building a house, they describe the size, room layout, lot size, room color, and so on. I like to think of requirements in two groups:
1. Product requirements
2. Process requirements

Between these two types of requirements, everything the customer needs should be identified.
Sources:
www.uspto.gov/web/offices/cio/lcm/lcm2001ch4.doc
http://media.wiley.com/product_data/excerpt/87/04700747/0470074787.pdf
http://infolab.stanford.edu/~burback/watersluice/node4.html
http://www.computerfreetips.com/main_page/System_Analysis.html
http://www.nwlink.com/~donclark/hrd/sat2.html
http://en.wikipedia.org/wiki/Systems_Development_Life_Cycle
http://articles.techrepublic.com.com/5100-10878_11-1045569.html

Considering your school, how do you know that the life cycle was developed specifically for the university.

2010-01-29T00:36:00.000-08:00

What is a Systems Life Cycle?

The SYSTEM LIFE CYCLE is a term used to describe the stages in an IT project. It is the process by which an existing
system is replaced with another. The SYSTEMS LIFE CYCLE is a term used to describe the stages in an IT project. These are:
1.) Definition of the problem

Before a project can begin, there has to be a reason why it should take place. You have to define the problem that the system is meant to be overcome. This phase is called the 'Problem definition phase'. Some formal effort is made to define exactly what the problem is. For example the following statements may appear in the Problem Definition. The existing system cannot transfer data to the new invoice system, staff have to spend three hours loading information or new legislation insist that financial records are kept for this department and so on.

Methods of defining a problem:

-> Interview employees about their issues with the current system
-> Analysing the total costs of the current system
-> Key external factors that may point towards developing a new system.
-> Performance of the existing system.

2.) Feasibility Study

It is one thing to define the problem with an existing system. The next question is what are the alternatives - what are the broad avenues that may be taken? It is very rare that any company will have just one possible solution open to them.

This is the 'Feasibility Study Phase' of the Systems Life Cycle model.

In this phase, alternative solutions are examined. The costs Vs the benefits are compared in order to see which would best suit the company taking into consideration their requirements and the funds available. In order to arrive at a final decision, sometimes a trade-off has to be accepted e.g. less functionality for less cash.

Consider three imaginary (very brief!) alternatives that a company could choose from:

a) Company does not change anything

Benefit: No disruption to the business. Least cost.
Performance: No change, system remains outdated. Process becomes increasingly less efficient.

b) Company makes alterations to half the system

Benefit: Best parts of the system are retained, whilst the least efficient aspects are redesigned to enhance performance.
Cost: Moderate, training moderate.
Performance improvement: 30%

c) Complete overhaul

Benefit: Reduces company cost base (more profitable).
Cost: High, given that new equipment / software will be required. Training for staff needed.
Performance: 70% improvement over the old system.

As you can see, deciding on the best alternative is often not simple - management have to take many factors into account. There are often complicated relationships between cost, performance and benefit. So at this point of the system life cycle, you know what the problem is and you are considering options. The various options are usually presented to management at this stage and it is up to them to make a decision as to how much cash they want to inject into the project. Once a decision has been made, the next phase is to analyze that option in greater detail.

3.) Investigation and Analysis

The management have taken the decision to proceed with the project. The next phase is called the 'Investigation and Analysis' phase. First you define how the old system works (investigation) and the problem(s) it is causing.

This is done by a variety of techniques that include:

-> Questionnaires and interviews
-> Observing people actually using the existing system
-> 'Paper trail' : Following information from the point it enters the system and observing what outputs are created at each point in the system.
-> Noting how / why the defined problem happens.

The investigation part confirms that the true cause of the problem has been correctly defined.
It also confirms that the project will overcome the problem. The next part is to carefully analyse how the existing system works: Not necessarily the hardware or software - but more about how information is handled and how people interact with it. As all this needs to be communicated efficiently to all concerned, a number of standard diagrams / methods are used.

System diagrams:

These show the relationships between the various systems in the company (or even outside if relevant) - how they interact, what depends on what and so on.

Data Flow Diagrams:

Most systems deal with information in one way or another. What really matters is how the information flows through the system. How does it branch and re-join. What outputs are created and so on.
The 'data flow' diagram seeks to show this movement through the system.

Process diagrams:

People handle information in a specific way - they have a 'process'. For example, an employee makes an expense claim. First of all their manager counter-signs the claim. It then goes to the account manager who authorises payment and so on...This is 'process flow' in action.
Process diagrams try to show how people interact with the system - who and when (and why).

4.) Design

Now that the project manager and the client have agreed on the requirements (Requirements Specification), it is time to define how the project is going to be carried out.
This is the Design phase of the project.

In this phase the exact details are defined, for example:

-> The data inputs
-> The data outputs
-> Any documents that are printed out
-> What happens to the data as it flows through the system (procedures)
-> The structure of any files that store data.
-> How information is accessed and indexed or sorted.
-> The operating system to be used
-> The hardware to be used.

And so on ....

So the design phase is really useful for the IT programmers who have to create the system.
Another aspect of creating a system is how are you going to test it?
It is tempting to leave the testing considerations until after the system has been developed but for the people having to develop the system it is really useful to have a test procedure in place before even starting to write a line of code or to design the hardware. This is because you know how it will be tested and so it guides you towards a good design.

-> Prototyping

A 'prototype' is something that represents what you will finally create without having to worry about all the details - it captures the essential details to confirm that the design is likely to work. In software, the prototype is often written in a kind of shorthand English 'Read in the record'. The details do not matter at this stage, but a record must be 'read in'. In hardware, you can test the system on a much cheaper slow computer, knowing that you will be able to run much faster on the final design - but it proves that the system works in principle. The master document that is created in this phase is the 'Systems Requirement Document' In a way, this is the contract between the project managers and the development team.

5.) Development (programming)

Now that the client has agreed on what needs to be done (Requirements Specification), and the Analyst has defined precisely what needs to be done (Systems Requirement Document) - it is time for the project to be actually developed.
The development stage is about taking the design forward and putting it into practice
One thing to note though, is that there may be several teams involved at this stage - so it is sensible to break down the Systems Requirement document into chunks that each teams can develop. It is no use informing the hardware team of the software requirements or vice versa.

At this stage the following things may take place (depending on the how extensive the project is) :

-> The software developers write code
-> The hardware people develop equipment
-> The testing team develop test plans
-> The user-testing groups follow the test plans and check that the system works as expected. If not an error report is sent to the developers and corrections are made. The test is then performed again.

6.) Testing and Implementation

This is an interesting time.... the implementation stage has been reached. The system has been developed and tested. It is working correctly and doing everything that was agreed during the design stage. The business is waiting in eager anticipation for the new system to be handed over to them.

The key events in this stage are:

-> DATA CONVERSION
-> Data stored in files on the old system are now converted into the correct format for the new system.
-> SYSTEM CHANGE-OVER
-> Now it is time to switch off the old system and turn on the new.
-> It sounds simple, but most of the time it isn't!

What are the alternatives?

1) Switch off the old system and switch on the new.

Of course, this is the simplest scenario! All the workers are waiting for the fabulous new system to come 'on -line' but as the minutes tick by, a new customer has just ordered a holiday / medical operation / flight / mortgage.
How do you deal with these last-minute (but vital) clients?
Answer: You must deal with last minute changes and accept that there may be some upheaval and mistakes made in the short term.

2) You run the old and new system in parallel for a time.

A popular method compared to the switch off / switch on approach. After all, the customer does not care what your IT system is made up of - they are only (rightly) concerned with their holiday / medical operation / mortgage etc being booked correctly.
And so, a popular method is to allow the old system to run alongside the new one. Then in the quiet period (say overnight) , the new system absorbs all the old system's information. By the next morning, the system is fully loaded and ready to go.

3) You run only part of the new system

This is the 'phased approach' to system testing. Imagine a system so sensitive to change that only a very careful change can be considered.
Example: A new air traffic control system.
Neither of the other two approaches would be suitable for such a critical system.

-> TRAINING

It is at the implementation stage that staff training takes place. Staff need to be shown how to use the new system and how to access help should they run into difficulties. There may be member of the development team on call for a short period of time or there may be a dedicated help line that staff can ring to get answers.
There will most definitely be a user manual to act as a source of reference.

7.) Evaluation

The implementation stage is over: The system is up and running, Staff are fully trained and bugs have been ironed out.
This new stage is called the 'Evaluation phase'

It is at this point two key questions are considered:

-> Does the finished solution meet its requirements?
-> Does it solve the problem?

These questions are answered by considering details written down in the original Requirements Specification and comparing it to the performance of the new system.

8.) Maintenance

The Evaluation stage is over and the system is running smoothly. However as time passes, it will no doubt need to be looked after.

This is the Maintenance phase of the Systems Life Cycle.

At this stage the following takes place:

-> Problems are cleared as they arise
-> Tweaks to the system are applied to improve performance
-> New circumstances might arise such as an office move. The system has to be moved.
-> Data is backed up and kept safe.
-> Printers, Monitors and other equipment are replaced as required.

This phase never really ends until the Life Cycle of the system is complete i.e. the system is switched off for the last time and a replacement system is introduced.

A Life Cycle Scenario in an Institution …

All things have a beginning, middle and an end. Just so, for an IT system. At some point in the past a wonderful new system was introduced into the company. Everyone was happy. Management could see their business improve. The workflow for employees was smoother and more productive. After the first few months of bedding in, the system worked well... and for a few years the system did everything it was meant to do.Time passed, people moved on, the company changed ... that wonderful system began to show its age... the new manufacturing system had problems exchanging data. Customer invoices no longer flowed effortlessly from their new system into your aging computers. Workers grew tired of using black screens with green text - even their home computers were more modern than this! It was time for a change. And so the life cycle of the system was complete.

Notice that the term 'life cycle' is used. This is because the process never really ends. Systems are created, they become mature, they grow old and are replaced by new ones. It is a cycle.

Why an Institution should consider a New System?

Why do institutions want to change their systems? After all, they have spent a fortune on developing their existing one. All the staff knows how to use it. The technicians know how to fix it. Management understands its capabilities.
As you can imagine, changing things is an expensive, risky undertaking. Staff will have to re-train. Equipment will have to be replaced. Offices may need to be re-wired causing disruption to every-day work.

Some of the reasons for introducing a new system may be:

1. The current system may no longer be suitable for its purpose.

Changes in the way work is carried out means the system is no longer suitable
Happily, the business has grown. Starting out with only ten staff a few short years ago, the system could easily cope with the workload. But now there are a thousand staff in many offices around the world. The system just can't cope
External influences. For example, new regulations have come along which insist that certain records are kept for years. The existing system was never designed for this.

2. Technological developments may have made the current system redundant or outdated.

Competitors are using more advanced systems that perhaps reduce their costs compared to yours, thus placing the company at a disadvantage.
Customers use more modern systems and insist that you upgrade yours to allow for easier data transfer.
The software supplier has warned that the version you are using will no longer be supported after next year. You have to plan for change.

3. The current system may be too inflexible or expensive to maintain.

A company has to to be able to cope with changing circumstances and this includes having the systems in place to deliver what the customer needs at the least internal cost.
For example, the customer has changed the way it sends data to its suppliers - you - and now your employees are having to manually type in invoices because the system cannot cope with the new format. Added costs, less profit, less competitive. Time for a new system.

Internal Factors

-> Reorganisation

When new departments are created or new managers appointed, new systems may be required to support new functionality or new ideas.

-> Users

People who use the systems on a regular basis can become frustrated or dissatisfied with their existing system. This can be due to a number of reasons e.g. constant errors, slowness of the system, inability to deal with new processes.

->New Initiatives

When new products are launched, new systems may be required to support them.

External Factors

-> Legislation

Governments may introduce new laws or requirements that must be complied with.

->Competition

A new market opportunity may be identified.

->Economics
A change in the economic climate may lead to organisational restructuring.

Why System Life Cycle is needed?

As was mentioned in the previous page - change is risky. IT change is particularly risky! Consider the sobering results obtained from a survey of over 14,000 organisations (OASIG study):

-> 80-90% of systems fail to meet performance goals
-> 80% of systems are late and over budget
-> 40% of systems fail or are abandoned
-> Less than 40% of businesses fully address training and skills requirements
-> Less than 25% properly integrate business and technology objectives
-> Just 10-20% of businesses meet all their success criteria.

Therefore only between 1 in 5 and 1 in 10 of the IT projects in the survey were successful.These are the possible queries that will be raised up to achieve change. What could have been done better? What could reduce the chances of failure? As people have learnt from past mistakes, a model has been developed and refined over the years to try and maximize the chances of a successful project. This method / model are called the SYSTEMS LIFE CYCLE.
It consists of a series of stages that take a project from its very first stages to the final outcome of a fully working, fully integrated system.

Considering now the University…

How do I know that the life cycle was developed specifically for the university? How do we know it meets our needs?
A life cycle is truly developed in our university by means of so many improvements in any department that optimizes processing methods to meet a certain goal of a task. As a result, this gives us all ease whenever we are going through these processes. The innovations in our university follows the stages of an IT project mentioned prior to this. Therefore it follows a cycle. And as of now, as we all know, there’s a lot more prospect projects that will come out from the brilliant ideas of many to solve existing constraints in the field of processes in this university.

Sources:
http://www.didcotgirls.oxon.sch.uk/depts/it/gcse/notes/effects/notes.htm
http://www.teach-ict.com/as_a2/topics/system_life_cycle/slc/index.htm
http://www.teach-ict.com/as_a2/topics/system_life_cycle/slc/the_systems_cycle.htm
http://www.teach-ict.com/as_a2/topics/system_life_cycle/slc/why_bother.htm
http://www.teach-ict.com/as_a2/topics/system_life_cycle/slc/what_prompts_a_new_system.htm
http://www.teach-ict.com/as_a2/topics/system_life_cycle/slc/definition_of_the_problem.htm
http://www.teach-ict.com/as_a2/topics/system_life_cycle/slc/feasibility_study.htm
http://www.teach-ict.com/as_a2/topics/system_life_cycle/slc/investigation_and_analysis.htm
http://www.teach-ict.com/as_a2/topics/system_life_cycle/slc/design.htm
http://www.teach-ict.com/as_a2/topics/system_life_cycle/slc/development.htm

Identifying and discussing at least 3 systems development models

2010-01-28T23:29:00.000-08:00

What is System Development Model?

“Specify how the activities of development process are organized in the total system development effort.”

The term process model is used in various contexts. For example, in business process modeling the enterprise process model is often referred to as the business process model. Process models are core concepts in the discipline of Process Engineering.

It is a framework for approaching strategy development.

It is typically used in structured analysis and design methods.

The current process model for data mining provides an overview of the life cycle of a data mining project. It contains the corresponding phases of a project, their respective tasks, and relationships between these tasks. At this description level, it is not possible to identify all relationships. There possibly exists relationships between all data mining tasks depending on goals, background and interest of the user, and most importantly depending on the data.

The software development process

• Investigate user requirements (analysis)

This phase is characterized by review and analysis of a functional document that describes the product. Requirements are reviewed and analyzed and requirements based test-cases are also generated at this stage.

• Clearly set out necessary features of system (specification)

• Create (or adapt) a suitable solution (design)

Design drafts are reviewed and finalized. Test cases for design integrity are also generated at this stage.

• Develop the proposed solution (implementation)

• Ensure that the solution solves the original problem (testing)

All test cases are finalized. The implementation is tested, first at the unit level, then following integration.

• Ensure that the solution works in context (integration)

The system is accepted for release to customers during this phase. This may involve some minimal final acceptance level testing.

• Modify the working solution as new requirements are identified (maintenance)
Regression testing, software evaluations and specifications for evolving the software are generated during this phase.

System Development Models

1.) Waterfall Model

The simplest possible model and therefore the least likely to be correct!

Model the software development process as a stately and sequential progression through the previously mentioned phases.

Traditionally, software development has been based on the "Waterfall" model, shown in figure 1, or its variations. There is a natural tendency among designers to proceed in a highly sequential, linear, and non-iterative manner. Designers tend to adhere to the old adage "Well begun is half done," by trying to make the analysis and design of the product as complete and precise as possible, before even embarking on its implementation. Every iteration, if any, to refine the design is viewed as an indicator of an insufficiency in the design. Tampering with the original conceptual design is discouraged, and though designers do iterate, they do so with a feeling of "guilt/incompetence."

The Waterfall Development Process

a.) Analysis and RequirementsSpecification

Initial Analysis :Developer analyses users requirement and, performs further investigation of requirements, produces developers version of requirements: System Requirements Document (SRD). The SRD is now a specification and part of the contract. Prepare project plan, including costing and schedule. Risk analysis.

Problem: Cost estimation.

Proposal :We are now in the realm of business contracts and the SRD is now a specification and part of the contract and will probably become a technical annex to a business proposal from developer to user.

Detailed Analysis :Starts once business proposal accepted by user.
• Up to this the developer will have been working unpaid.
• The main concern in `Initial Analysis' was the size of the project.
• This is real systems analysis.
• Specification of unambiguous and testable requirements. These will be the criteria for user acceptance, see

Acceptance Test.
• Risk analysis: identify risks, analyse, categorise/prioritise, produce backup-policies.
• Bad risks may need a Pilot Project to resolve them. See Spiral Model.

Problems:
• (Again) Difficulties in capturing requirements.
• The project can get stuck in the `analysis black-hole' [Peters, 1988].
• Difficulties in specifying requirements with precision and lack of ambiguity (testable). See Formal Methods.

Input: URD.
Outputs:
• Revised SRD.
• Tender or Quotation (proposal) from developer.

Milestones:
• Kickoff (project start).
• Software Requirements Review (a Deliverable).

b.) Design

High-Level Design :Decompose into subsystems/modules. Allocate to teams or individuals. Design tests for subsystems. Other names are Architectural Design, Preliminary Design, Product Design.

Input: SRD
Outputs:
• Architectural Design Document (ADD) (Deliverable).
• System Test Document (STD) (Deliverable).

Milestone: Architectural Design Review.
Problem: Does the decomposition technique provide really decoupled modules? I.e. Can teams work independently? The answer to these questions have massive implications for maintenance and reuse . See Object-oriented Analysis and Design.

Detailed Design :Decompose further into subsystems (or units or components) such that approx. one person can cope. Specify these subsystems. Design tests for (sub)subsystems.

Input: ADD.
Outputs:
• Detailed Design Document (DDD).
• Detailed Test Document (specifications and test data).
Milestone: Detailed Design Review.

c.) Implementation

Implementation and Coding :Code and test components - each programmer. Notice how far into project.
Outputs:
• Revised Detailed Design Document (DDD).
• Coded and Tested Software.
• Test documentation.

d.) Testing and Integration
Components and modules are brought together to form higher level systems. And tested. Repeat until you have a working system.

System Test
You should now have a working system! The full system is tested, in the developers environment.

Acceptance Test
Assess the system against the rquirements defined in SRD. Probably done under users control and supervision, and in their environment. Final payment hinges on this.

e.) Operation and Maintenance

Operations :The system gets used - hopefully!

Maintenance :Following [Pressman, 1997], we identify four types of development (change) neccessitated during maintenance.

Correction :Correct defects in the software: defects relating to incorrect requirements, or incorrectly specifications; defects from any of the construction phases - `bugs'.

Adaption :Adapt to changes in the original software and hardware platform. E.g. simpler: MS-DOS to Windows.

Complex: stand-alone to client-server.

Enhancement :Customer identifies additional requirements.

Prevention :After many sets of changes, the software `deteriorates', or otherwise becomes difficult to maintain. See Reengineering, Legacy Systems.

Problems:
• Programmers do not like doing maintenance.
• Maintenance needs a project of its own. It is very uncommon to include maintenance in a (development) contract.
• Cost estimation. Normal software cost estimation is difficult enough; most estimation models do not include maintenance.
• Design deficiencies make system impossible to extend. See Object-oriented ....
• Deterioration of legacy systems.
• When do you decide to start again from scratch, or reengineer?

Advantages:

Easy to understand, easy to use
Provides structure to inexperienced staff
Sets requirements stability
Good for management control (plan, staff, track)
Much better than ``all hands to the keyboards, spend half the budget on the latest hardware, with no planning''.
Misinterpretations may surface early. Errors found during operations may cost one hundred times or more to fix than if caught during Software Requirements Review.
Other problems may surface early; overspend; lack of feasibility; note 90of budget but the next 10

Limitations:

All requirements must be known upfront
System can be frozen before the design begins
Little opportunity for customer to preview the system (until it may be too late)
Maintenance. Much of what goes with the waterfall process. assumes `building something new'. Likewise reuse .

2.) Prototyping

Variations on the theme of "build something and see if that's what's wanted"
May be entire development process (exploratory programming) or merely replace the early design-implement cycle or may take an evolutionary approach (Gall's dictum).

The Prototyping Model is a systems development method (SDM) in which a prototype (an early approximation of a final system or product) is built, tested, and then reworked as necessary until an acceptable prototype is finally achieved from which the complete system or product can now be developed. This model works best in scenarios where not all of the project requirements are known in detail ahead of time. It is an iterative, trial-and-error process that takes place between the developers and the users.

There are several steps in the Prototyping Model:

1. The new system requirements are defined in as much detail as possible. This usually involves interviewing a number of users representing all the departments or aspects of the existing system.
2. A preliminary design is created for the new system.
3. A first prototype of the new system is constructed from the preliminary design. This is usually a scaled-down system, and represents an approximation of the characteristics of the final product.
4. The users thoroughly evaluate the first prototype, noting its strengths and weaknesses, what needs to be added, and what should to be removed. The developer collects and analyzes the remarks from the users.
5. The first prototype is modified, based on the comments supplied by the users, and a second prototype of the new system is constructed.
6. The second prototype is evaluated in the same manner as was the first prototype.
7. The preceding steps are iterated as many times as necessary, until the users are satisfied that the prototype represents the final product desired.
8. The final system is constructed, based on the final prototype.
9. The final system is thoroughly evaluated and tested. Routine maintenance is carried out on a continuing basis to prevent large-scale failures and to minimize downtime.

Advantages:

Customers can “see” the system requirements as they are being gathered
A more accurate end product
Unexpected requirements accommodated
Allows for flexible design and development
Lower overall development costs when requirements change frequently

Limitations:

Prototyping can lead to false expectations.
Prototyping can lead to poorly designed systems.

3.) Iterative Enhancement Model

The iterative enhancement life cycle model counters the third limitation of the waterfall model and tries to combine the benefits of both prototyping and the waterfall model. The basic idea is that the software should be developed in increments, where each increment adds some functional capability to the system until the full system is implemented.

At each step extensions and design modifications can be made. An advantage of this approach is that it can result in better testing, since testing each increment is likely to be easier than testing entire system like in the waterfall model. Furthermore, as in prototyping, the increments provides feedback to the client which is useful for determining the final requirements of the system.

In the first step of iterative enhancement model, a simple initial implementation is done for a subset of the overall problem. This subset is the one that contains some of the key aspects of the problem which are easy to understand and implement, and which forms a useful and usable system. A project control list is created which contains, in an order, all the tasks that must be performed to obtain the final implementation. This project control list gives an idea of how far the project is at any given step from the final system.
Each step consists of removing the next step from the list. Designing the implementation for the selected task, coding and testing the implementation, and performing an analysis of the partial system obtained after this step and updating the list as a result of the analysis. These three phases are called the design phase, implementation phase and analysis phase. The process is iterated until the project control list is empty, at the time the final implementation of the system will be available.

Advantages:
Easier to test
Provide Feedback

Limitations:
Provide incomplete system
Time consuming
High cost

4.) Spiral Model

Spiral model A software life-cycle model devised by Barry Boehm that encompasses a management strategy, a life-cycle development model, and risk assessment. The model takes its name from the spiral representation as shown in the diagram. Beginning at the center of the spiral, where there is limited detailed knowledge of requirements and small costs, successive refinement of the software is shown as a traverse around the spiral, with a corresponding accumulation of costs as the length of the spiral increases. Interaction between phases is not shown directly since the model assumes a sequence of successive refinements coupled to decisions that project risks associated with the next refinement are acceptable. Each 360° rotation around the center of the spiral passes through four stages: planning, seeking alternatives, evaluation of alternatives and risks, and (in the lower right quadrant) activities equivalent to the phases represented in waterfall or V-models.

The spiral model, also known as the spiral lifecycle model, is a systems development lifecycle (SDLC) model used in information technology (IT). This model of development combines the features of the prototyping model and the waterfall model. The spiral model is favored for large, expensive, and complicated projects.

The steps in the spiral model can be generalized as follows:

1. The new system requirements are defined in as much detail as possible. This usually involves interviewing a number of users representing all the external or internal users and other aspects of the existing system.
2. A preliminary design is created for the new system.
3. A first prototype of the new system is constructed from the preliminary design. This is usually a scaled-down system, and represents an approximation of the characteristics of the final product.
4. A second prototype is evolved by a fourfold procedure: (1) evaluating the first prototype in terms of its strengths, weaknesses, and risks; (2) defining the requirements of the second prototype; (3) planning and designing the second prototype; (4) constructing and testing the second prototype.
5. At the customer's option, the entire project can be aborted if the risk is deemed too great. Risk factors might involve development cost overruns, operating-cost miscalculation, or any other factor that could, in the customer's judgment, result in a less-than-satisfactory final product.
6. The existing prototype is evaluated in the same manner as was the previous prototype, and, if necessary, another prototype is developed from it according to the fourfold procedure outlined above.
7. The preceding steps are iterated until the customer is satisfied that the refined prototype represents the final product desired.
8. The final system is constructed, based on the refined prototype.
9. The final system is thoroughly evaluated and tested. Routine maintenance is carried out on a continuing basis to prevent large-scale failures and to minimize downtime.

• Categorizes the many (and repeated) phases of software development into a number of cyclically repeated sectors

• Determining objectives/alternatives/constraints

• Risk analysis

• Prototyping

• Simulation/modelling/benchmarking

• Specification and design

• Planning

• System complexity and size grows with increasing radius, as do investment and risk
• Suggested by Boehm in 1988
• Still regarded as one of the best models

Advantages:
Risk assessment
Users see the system early because of rapid prototyping tools

Limitations:

Time spent for evaluating risks too large for small or low-risk projects
The model is complex
Risk assessment expertise is required

5.) Fountain model

Based on the waterfall model. But observes that the sequence always contains cycles. Reflects the fact that some phases cannot begin before others and that some phases are poorly delineated. A mental image to help visualize what actually happens in many real software development projects.

Once upon a time, software development consisted of a programmer writing code to solve a problem or automate a procedure. Nowadays, systems are so big and complex that teams of architects, analysts, programmers, testers and users must work together to create the millions of lines of custom-written code that drive our enterprises.

To manage this, a number of system development life cycle (SDLC) models have been created: waterfall, fountain, spiral, build and fix, rapid prototyping, incremental, and synchronize and stabilize.

The oldest of these, and the best known, is the waterfall: a sequence of stages in which the output of each stage becomes the input for the next. These stages can be characterized and divided up in different ways, including the following:

• Project planning, feasibility study: Establishes a high-level view of the intended project and determines its goals.
• Systems analysis, requirements definition: Refines project goals into defined functions and operation of the intended application. Analyzes end-user information needs.
• Systems design: Describes desired features and operations in detail, including screen layouts, business rules, process diagrams, pseudocode and other documentation.
• Implementation: The real code is written here.
• Integration and testing: Brings all the pieces together into a special testing environment, then checks for errors, bugs and interoperability.
• Acceptance, installation, deployment: The final stage of initial development, where the software is put into production and runs actual business.
• Maintenance: What happens during the rest of the software's life: changes, correction, additions, moves to a different computing platform and more. This, the least glamorous and perhaps most important step of all, goes on seemingly forever.

But It Doesn't Work!

The waterfall model is well understood, but it's not as useful as it once was. In a 1991 Information Center Quarterly article, Larry Runge says that SDLC "works very well when we are automating the activities of clerks and accountants. It doesn't work nearly as well, if at all, when building systems for knowledge workers -- people at help desks, experts trying to solve problems, or executives trying to lead their company into the Fortune 100."

Another problem is that the waterfall model assumes that the only role for users is in specifying requirements, and that all requirements can be specified in advance. Unfortunately, requirements grow and change throughout the process and beyond, calling for considerable feedback and iterative consultation. Thus many other SDLC models have been developed.

The fountain model recognizes that although some activities can't start before others -- such as you need a design before you can start coding -- there's a considerable overlap of activities throughout the development cycle.

The necessity of an iterative approach to product development requires basic building blocks that do not undergo drastic mutation over iterations. This is an issue of the choice of the "Problem representation domain" in which the model life-cycle is to be represented. The solution to this is to adopt an object-oriented approach since objects are fairly stable building blocks that can be identified at a very early stage in the product life-cycle. In most cases, the analysis, design, and implementation stages can all be mapped into the object-oriented domain without having to make disjoint mappings into the "Structured Analysis Domain". And the "Fountain model," employed with much success in object-oriented projects, is ideally suited for modeling such projects.

Sources:
http://www.scribd.com/doc/15243782/System-Development-Model?autodown=ppt
http://www.csse.monash.edu.au/~jonmc/CSE2305/Topics/07.13.SWEng1/html/text.html
http://codecourse.sourceforge.net/materials/The-Waterfall-Lifecycle-Model.html
http://searchsoftwarequality.techtarget.com/sDefinition/0,,sid92_gci755347,00.html
http://www.freetutes.com/systemanalysis/sa2-iterative-enhancement-model.html
http://www.encyclopedia.com/doc/1O11-spiralmodel.html
http://portal.acm.org/citation.cfm?id=227536
http://searchcio-midmarket.techtarget.com/sDefinition/0,,sid183_gci755441,00.html
http://www.computerworld.com/s/article/71151/System_Development_Life_Cycle
http://en.wikipedia.org/wiki/Process_model
http://sensacom.com/web_glossary.html
http://www.crisp-dm.org/Process/index.htm

Discussing the role of a systems analyst as a project manager.

2010-01-28T23:25:00.000-08:00

What is a project manager?

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

What is project management then?

Is the discipline of planning, organizing, and managing resources to bring about the successful completion of specific project goals and objectives. It is often closely related to and sometimes conflated with program management.

What is a system analyst?

A programmer or consultant who designs and manages the development of business applications. Typically, systems analysts are more involved in design issues than in day-to-day coding. However, systems analyst is a somewhat arbitrary title, so different companies define the role differently.

Management connects project manager and system analyst. They are closely related but they are also different in some ways. This was separated to have a more organize and specific assignment of task.

Role of the Project Manager

The project manager's role in a nutshell is the overall responsibility for the successful planning, execution, monitoring, control and closure of a project.

From a textbook perspective, the role of a project manager is quite easy to describe. A project manager is one, who looks into the application of knowledge, skills, tools, and techniques to describe, organise, oversee and control the various project processes. Having said that, the roles and responsibilities of a project manager differ from company to company. It is important to understand what role a particular project manager will play in a certain company or organisation.

A project manager is the person who has the overall responsibility for the successful planning and execution of a project. He/she must possess a combination of skills including an ability to ask penetrating questions, detect unstated assumptions and resolve interpersonal conflicts as well as more systematic management skills.

Improving Project Success Rates with Better Leadership

Factual and anecdotal evidence confirms that IT investments are inherently risky. On average, about 70% of all IT related projects fail to meet their on-time, on-budget objectives or to produce the expected business results. In one KPMG survey, 67% of the companies who participated said that their programme/project management function was in need of improvement. Why? A number of leading factors for project failure were suggested by the survey, including the "usual suspects": unreasonable project timelines, poorly defined requirements, poor scope management, and unclear project objectives. Granted, all of these factors can play a role in project success.

Project Management Confidence

If you have been doing project management for a while, your confidence has probably gotten an occasional shaking. And the resulting lack of confidence hurts you, but it also hurts your team members who need you to be confident and not self-conscious. You're their leader after all, and they want you to have a strong plan, vision, self-esteem and the confidence to lead.

Project Management Excellence

Project management excellence goes beyond producing project charters, detailed schedules and colourful status reports. Today's project managers must acquire the skills necessary to combat a myriad of modern challenges. Factors such as downsizing, merger mania, restricted finances, an accelerated business pace, a multidisciplinary world, rising competition and seemingly ceaseless change, acting singly and in concert, demand much more.

Be a Smart Project Manager

The key to being a smart project manager is to remember how you are going to manage your project, to know what to do if it does not work, and to win and keep the support of all of the project stakeholders.

The Ideal Project Manager Specification

Successful project management is a combination of approximately 20% hard skills and 80% soft skills. The hard skills relate to the actual processes, procedures, tools and techniques comprising planning, organising, monitoring and controlling, while the soft skills relate to the project managers attitudes and behaviours. In addition, I believe that a truly excellent project manager must become a master of paradox. This article provides a specification of the hard and soft skill along with a listing of the attitudes and behaviours required of a great project manager.

Managing Small Projects

Project management best practices can easily be applied on small projects to enable you to plan and manage your project successfully. This article looks at how to apply these practices without creating too much paperwork or overhead.

Intelligent Disobedience: The Difference Between Good and Great Project Managers

Intelligent disobedience requires taking risks, creativity, flexibility and perseverance. Following this approach can have significant benefits in project management terms and can make the difference between good and great project managers.

Using Feedback as a Tool

As a project manager it is important to be able to give and receive feedback effectively. Feedback is best given on a one to one basis soon after the event that triggers its need. Here are some tips that can help.

Sir Nick is the former system analyst and later on promoted as the project manager of Emcor.

As a former system analyst he said that he has the edge when it comes to planning a particular project because he already have the knowledge of being a system analyst so he can estimate the entire project, if it will be a success or a failure.

These are roles he emphasizes to become an excellent project manager:

An excellent manager taps into talents and resources in order to support and bring out the best in others. An outstanding manager evokes possibility in others.

1.) Leadership for Programme and Project Managers

Effective management is not just about being able to apply budgetary constraints or running projects to time. In fact, 70% of businesses fail to achieve their desired goals and the causes for failure are usually lack of strong leadership, lack of team skills, and lack of stakeholder engagement. These more subtle skills can have a huge effect on successful outcomes.

2.) The Hardest Word in the Project Management Vocabulary

For project managers "no" is often the toughest word in the English language to deploy. We often prefer the classic PM strategy of "Yes, but..." as the softer, kinder, gentler alternative. "No" sounds harsh. Uncooperative. It sounds reticent and recalcitrant. It sounds negative. And yet, for many of us, the time has come as professionals to set "yes, but..." aside and venture into the world of "no."

3.) Successful Projects Are Led Not Managed

More and more in today's environment Project Managers are being judged on how well they operate within, and adhere, to standard practices and disciplines. This is all very well, but let us stand back and think for a moment. If I were to challenge any one of you to think of someone you respect, who consistently delivers projects on time, who always gets called on when things get tough. I am sure that you could name that person without knowing how well they work within the practices and disciplines of your company.

4.) The Project Management Traits to Master "the How"

In project management, we tend to focus on the method. And there is no shortage of methods (Six Sigma, Scrum, Waterfall). The method is the what of project management and is often at the core of an effectively run project. But the method can only take your project so far.

5.) Have a Clear Goal

Just think of the criteria. They had a clear goal and purpose. They had a team of people with defined (if unspoken) roles. All of the team needed to work together to achieve the goal. There was a definite time constraint in terms of when the goal needed to be achieved. Project goals keep the focus on what is most important. However, on some teams these primary goals are lost in their meeting's activities. Make sure each meeting is structured so as to move the project forward. Even if the progress is only inches rather than by huge leaps, the team must be pushing the project forward as quickly, safely, and reasonably as possible.

6.) The Next Generation Project Manager

Are you tired being an average project manager, working on average projects, being passed over for promotion, and getting an average performance review? You need to understand something right now. There are new challenges and expectations today that require every project manager to evolve to the next level. If you do not take action now, you will be left behind.

7.) How to Become a Project Manager

Managing a project is just another branch of business management. There are well understood methodologies, tools, guidelines, and procedures to help you on your way to developing the important life-skill of project management. This article sets out the key skills needed to become a competent project manager.

8.) An effective one

Project management is what project managers do, not what project management software or a methodology does. No software exists that will deliver a project on time and on budget all by itself. No matter how "good" the software or methodology, it is only as good as the people using it.

9.) Get Your Project Approved

What do you do when you have a great idea? You know how to save your company a ton of money or you've thought of a way to really improve a product. The problem is that you know that you have a great idea, but no-one else does. And you can't convert this idea into reality by yourself. You need resources. You need money. You feel that you need permission. What do you do?

10.) Establishing Your Project Management Authority

It's been a tough climb to your project management position. How do you establish your authority and inspire respect? What must be done to influence project results and growth and make your stay long and productive?

Computer and Information Systems Managers

In the modern workplace, it is imperative that Information Technology (IT) works both effectively and reliably. Computer and information systems managers play a vital role in the implementation and administration of technology within their organizations. They plan, coordinate, and direct research on the computer-related activities of firms. In consultation with other managers, they help determine the goals of an organization and then implement technology to meet those goals. They oversee all technical aspect of an organization, such as software development, network security, and Internet operations.

Computer and information systems managers direct the work of other IT professionals, such as computer software engineers and computer programmers, computer systems analysts, and computer support specialists (information on these occupations can be found elsewhere in the Handbook). They plan and coordinate activities such as installing and upgrading hardware and software, programming and systems design, the implementation of computer networks, and the development of Internet and intranet sites. They are increasingly involved with the upkeep, maintenance, and security of networks. They analyze the computer and information needs of their organizations from an operational and strategic perspective and determine immediate and long-range personnel and equipment requirements. They assign and review the work of their subordinates and stay abreast of the latest technology to ensure that the organization remains competitive.

Computer and information systems managers can have additional duties, depending on their role within an organization. Chief technology officers (CTOs),for example, evaluate the newest and most innovative technologies and determine how these can help their organizations. They develop technical standards, deploy technology, and supervise workers who deal with the daily information technology issues of the firm. When a useful new tool has been identified, the CTO determines one or more possible implementation strategies, including cost-benefit and return on investment analyses, and presents those strategies to top management, such as the chief information officer (CIO). (Chief information officers are covered in a separate Handbook section on top executives.)

Management information systems (MIS) directors or information technology (IT) directors manage computing resources for their organizations. They often work under the chief information officer and plan and direct the work of subordinate information technology employees. These managers ensure the availability, continuity, and security of data and information technology services in their organizations. In this capacity, they oversee a variety of technical departments, develop and monitor performance standards, and implementing new projects.

IT project managers develop requirements, budgets, and schedules for their firm’s information technology projects. They coordinate such projects from development through implementation, working with their organization’s IT workers, as well as clients, vendors, and consultants. These managers are increasingly involved in projects that upgrade the information security of an organization.

Work environment. Computer and information systems managers generally work in clean, comfortable offices. Long hours are common, and some may have to work evenings and weekends to meet deadlines or solve unexpected problems; in 2008, about 25 percent worked more than 50 hours per week. Some computer and information systems managers may experience considerable pressure in meeting technical goals with short deadlines or tight budgets. As networks continue to expand and more work is done remotely, computer and information systems managers have to communicate with and oversee offsite employees using laptops, e-mail, and the Internet.

Injuries in this occupation are uncommon, but like other workers who spend considerable time using computers, computer and information systems managers are susceptible to eyestrain, back discomfort, and hand and wrist problems such as carpal tunnel syndrome.

Computer and information systems managers oversee a variety of workers, including systems analysts, support specialists, and software engineers.

Rules of Highly Successful Project Management

A successful project manager is one who can envision the entire project from start to finish, and have the prowess to realise this vision. To keep pace with business and IT, project managers need to make their management practices more flexible.

From my other sources:

Project Manager: Roles and Skills

Generally, the project manager is responsible for the overall accomplishment of the project, and accountable for ensuring objectives of the project's assignment. One foremost responsibility of the project manager is; the very project itself.

Generally, the project manager is responsible for the overall accomplishment of the project, and accountable for ensuring objectives of the project's assignment.

One foremost responsibility of the project manager is; the very project itself.

The person who takes this ultimate responsibility and guarantees for the desired result to be achieved on time, and within budget is the Project Manager. And his job is to coordinate a project from initiation to completion; using maximum utilization of project management tools, techniques, experience, creativity, and management skills, to reach the predetermined objectives.

In a project as a Role his "Leadership quality" and as a Skill his "Management excellence" is accredited. The role a project manager performs is in many ways similar to those performed by other operation managers; however there are some important differences; as Project managers have a wide range of backgrounds and experience levels and are often "generalists" differentiating themselves from an operational type role to one whom specialized in the respective areas of management. In addition, project managers play specific roles to facilitate the project team rather than supervising them.

Role of the Project Manager:

As a role, project managers must satisfy these sets of needs:

Task Needs + Team Needs + Individual Needs

The project manager role; he should meet his "Task Needs" as follows;

Attaining team objectives
Planning work
Allocating resources
Defining tasks
Assigning responsibility
Controlling and monitoring quality
Scrutinizing progress
Checking performance

The project manager role; he should meet his "Team Needs" as follows;

Appointing secondary leaders
Building and upholding team sprit
Setting standards and maintaining regulation
Training the team
Setting up systems to facilitate communication with the team
Developing work methods to craft team function cohesiveness

The project manager role; he should meet his "Individual Needs" as follows;

Developing the individual
Balancing team needs and task needs
Balancing team needs and individual needs
Performance appreciation and rewards
Helping with other team members personal problems

Skills for Project Manager:

Furthermore, in order for an effective project manager, he needs the following core skills;

Leadership skill to arouse action, progress, and change.
Contractual skills to organize subcontractors.
Legal knowledge.
Evaluation of alternatives and ability for decision making.
Planning and controlling for necessary counteractive measures.
Financial familiarity for budget risk management.
High communication skills.
Negotiating abilities.
People management to motivate them towards the project goal.
System designing and maintenance.

Overall, a project manager has responsibilities from the beginning of project initiation, planning, controlling, and executing to both management and to the project team. A project manager must steer his project towards the bigger picture and be responsible for the job; a project manager must be experienced, committed, dependable and flexible, as his position remains in the nucleus of the system and success and failure centralizes on the project manager's shoulders.

Sources:
http://www.buzzle.com/articles/project-manager-roles-skills.html
http://www.angelfire.com/anime3/internet/programming.htm
http://en.wikipedia.org/wiki/Project_management
http://en.wikipedia.org/wiki/Project_manager
http://www.bls.gov/oco/ocos258.htm#nature
http://www.projectsmart.co.uk/role-of-the-project-manager.html

Interviewing a System Analyst about how they construct modeling

2010-01-28T23:14:00.000-08:00

EMCOR Davao (Engineering Machinery Corporation) is the leading company of and market leader in the field of appliances, electronics and motorcycles. EMCOR is a 100% Filipino company whose primary business activity is the retailing of household appliances and motorcycles through the operation of retail stores in the islands of the Visayas and Mindanao, Philippines.

"main branch for Davao"

As we conducted the interview with the system analyst of EMCOR who is Mr Marcelino Vistal Jr , he cited many skills and characteristics an analyst must possess to be effective in developing a particular design in any kind of project. Costumer is the most important people in business industry, since analyst are dealing with any kind of customer, they must be customer oriented, which is actually defined as being understanding to the customer’s angst and difficulties.

To be customer oriented you have to:
• Listen
• Ask questions
• Forget about profit
• Forget about final purchase amount
• Forget commissions
• Forget about time.
• You have to WANT to help them, strictly to make them happy.

As a problem solver, an analyst is tasked to give various possible solutions to each of the problems raised by customers. Handling the problem is not really difficult because there is no one way solution for any problem. The main concern of an analyst is on how to communicate, deal, and understand what the customer really wants. It is easier to adapt their different personalities if there is understanding, patience and willingness.

Another point of Mr Vistal was Management Efficiency. It is being efficient and effective in managing its people who participates in the project. When you have a closed mind, you live in the ideas, opinions and attitudes that you have already created in your mind. You don't know if they are true. Because you make those opinons, attitudes and ideas with whatever feelings and information that you get with your five senses. Your senses can cheat you. No one knows what is the actual truth.

An analyst must be open minded, a good listener and professional with his acts and words.
An analyst should not only have the analysis for the project but he/she must consider the strength and weaknesses of each member of the team into whom his/she’s handling.

Management consists of the five processes, namely, planning, organizing, leading, coordinating and controlling. Management is basically an organization activity, the organization of work and resources, to achieve success. The successful organization of work and resources requires careful planning. Effective planning involves foresight of the potential obstacles and readiness to fight them. It is important to head the team and guide the team members on their way to success. While organizing and leading a group of people, management plays a vital role in the achievement of co-ordination and the exercise of control. Management is such a vast subject that it becomes difficult to restrict the definition of management to a few processes. Management is complex and critical and hence it is not right to confine its description to some management processes. Believing in the vastness of this subject, some prefer defining management as ‘all that managers do’. But what does a manager do? A manager is responsible for the successful implementation of management skills. A good manager needs to adhere to the basic management principles and exhibit the basic management skills in his/her personality.

He/she must be knowledgeable of the techniques on how to make the use of expertise that each member possesses. Of course to disseminate them to the right task. And so if the right people will be put is on the right task. The project will be a success.
There are a wide range of need analysis techniques, drawn from fields such as knowledge management, user-centered design, ethnography and anthropology.

Techniques include:
• facilitated discussions
• focus groups
• surveys
• staff interviews
• workplace observation
• contextual inquiry
• task analysis

In practice, more than one technique should be used with a selected group of staff, to ensure that a complete picture is built up.
This is one of the most important management skills. Leadership comprises of the efficient organization of the resources in achieving a company goal. Leadership involves the management of human resources with an assessment of the strengths and weaknesses of each member of the team. It is about leading the people and guiding them towards the accomplishment of a common goal. Leadership includes a just allocation of work to the resources, planning of the implementation of tasks assigned and helping the team with task completion.

This is another basic management skill that includes dealing with people, the most important asset of an organization. Encouraging the team members to speak up, come up with ideas and allowing them to make mistakes and learn from them can be described as a team building skill. To build a team, one needs to foster the team spirit in all of the team members. For the team to feel motivated to work, it is important for a manager to cater to their expectations, recognize their strengths and understand where they lack. The building of a team is about building the team spirit in members and maintaining it. The skill lies in knowing the team and encouraging them to take initiative and enthusiastically participate in every venture of the company.
He also cited that an analyst must be keen and detailed in terms of specification of the project as well as its entire operational process, effects as to its possible risks and benefits.

Being keen is ability to perceive and understand deeply. Systems Analyst is having systems analysis all the time in which it is a process of understanding in detail what a system should accomplish. Therefore, understanding is a basic characteristic an analyst must have to be effective in doing his/her job.
When something is meaningfully understood, it is retained much longer, can be built upon to acquire further understanding, is usually very versatile in the situations and ways it can be used, and facilitates creativity.

Being detailed is marking by abundant detail or by thoroughness in treating small items or parts when it comes to organizing projects analysis, being detailed oriented is essential. Analyst organizes gathered data before reviewing them or forwarding them to programmers. Attention to details means that you recognize the possible instances may occur during the entire operation of the project. An analyst must have a fundamental curiosity.
Being detailed is very important in keeping the project less risky because you may have prevention measures ahead of the occurrence of the problems in an ongoing project. This is possible if there is a concise analysis on each phase of the project. Curiosity and keen observation will be very useful characteristics an analyst must have.

Another thing, an analyst must have standardization in any phase of the project. Defining benchmarks will be helpful to lift the quality of the project as we must agree to quality over quantity view.
Benchmarking is the process of comparing the business processes and performance metrics including cost, cycle time, productivity, or quality to another that is widely considered to be an industry standard benchmark or best practice. Essentially, benchmarking provides a snapshot of the performance of your business and helps you understand where you are in relation to a particular standard. The result is often a business case and "Burning Platform" for making changes in order to make improvements.

However, having good characteristics will not be enough without proper knowledge to technology. Sir Vistal emphasized that there is no need to be expert in all of the innovations yet knowing the basics and as what it is in general will be already an edge.

The benefits of information technology in business is that Information technology has formed a major place in the different business areas. Most of the businesses have started their own in-house training for IT by their own staff. The different benefits in use includes: The use of IT is evidently a major component of work in businesses; Most responding companies prefer in-house training by their own staff for IT Training above other methods; The most important use of the IT by respondents is in office applications, followed by accounting software and sector-specific applications; and The sector-specific and project-management applications were expected to show the greatest growth in demand over the coming years. 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.

An analyst is not perfect yet should be aiming perfection. An analyst does not know everything, yet must at least familiarize everything. He/she must always be willing to learn to have continuous grow. As learning is a continuous process, an analyst must open to any ideas that he/she will be encountered during each phases. He/she must establish strong foundation of the basics to learn new things easily.

The manager, who is the former system analyst of the company, added that being determined to any task is the root of any successful project.
Then, an analyst must be competitive to achieve a certain goal this is not only to solve the problem but also to provide a solution with quality and efficiency factors.
Being competitive is one of the characteristic an analyst should posses so that he/she will constantly aim for improvement. Competitiveness relies on the flexibility of the persons in charge for a particular project. The higher quality of excellence a team have, the higher quality and competent project they could produced. And most of all, an analyst must have Integrity and Ethics.

The single most important quality you can ever develop that will enhance every part of your life, is the value of integrity. Integrity is the core quality of a successful and happy life. Having integrity means being totally honest and truthful in every part of your life. By making the commitment to become a totally honest person, you will be doing more to ensure your success and happiness in life than anything else you can ever do.

Integrity is a value, like persistence, courage, and intelligence. It is your choice of values and resolution to live by those values that form your character and personality. And it is integrity that enhances all your other values. The quality of person you are is determined by how well you live up to the values that are most important to you. Integrity is the quality that locks in your values and causes you to live consistent with them.
Integrity is the foundation of character. A person who has integrity also has an unblemished character in every area of his or her life. One of the most important activities you can engage in, is developing your character. And one of the best ways to develop your character is by consistently doing the same things that a thoroughly honest person would do in every area of his or her life.

Applying ethics in business makes good sense. A business that behaves ethically induces other business associates to behave ethically as well. If a company (or a manager) exercises particular care in meeting all responsibilities to employees, customers and suppliers it usually is awarded with a high degree of loyalty, honesty, quality and productivity. For examples, employees who are treated ethically will more likely behave ethically themselves in dealing with customers and business associates. A supplier who refuses to exploit its advantage during a seller's market retains the loyalty and continued business of its customers when conditions change to those of a buyer's market. A company that refuses to discriminate against older or handicapped employees often discovers that they are fiercely loyal, hard working and productive.

The best way to promote ethical behavior is by setting a good personal example. Teaching an employee ethics is not always effective. One can explain and define ethics to an adult, but understanding ethics does not necessarily result in behaving ethically. Personal values and ethical behavior is taught at an early age by parents and educators.

By the way, the company implements AGILE modeling process in which they can have deployment even during the development of the system. In which I find it practical and prone to system innovations in which I believe a good factor that should be consider.

Sources:
http://wilstop.info/2007/08/25/emcor-davao-philippines/
http://www.teach-nology.com/edleadership/effective_management/
http://answers.yahoo.com/question/index?qid=20071023175655AAVnb2c
http://www.asqsandiego.org/articles/ethics1.htm
http://www.goal-setting-guide.com/articles/success/importanceofintegrity.html
http://en.wikipedia.org/wiki/Benchmarking

Identifying and discussing some charateristics you have as a good Systems Analyst.

2010-01-28T23:10:00.000-08:00

1.) Problem Solver – An analyst is said to be a problem solver. In my case, as the eldest in our family siblings I practiced being a problem solver financially and emotionally with them. I never let days past without having even little accomplishments in my life or even having undone/hanging task to do. I always put in mind that I can do all the things I need to do or things that I am task to do. Because I trust my self and I know already my limitations. One thing I learned in life, letting things just fall into place is different from making things happen. So having the courage and perseverance to do something, I never take the word impossible as an excuse, because if my mind can think of a possible solution to the problem therefore it maybe existed or will be exist soon if I will do my part.

A great skill to have is the ability to solve problems effectively. Not only that, it's also a great skill to teach students. There are a few key requirements to solve problems effectively. In and out of the classroom, we're often confronted with problems and effective problem solvers often employ a few key remedies. Here are the steps to becoming an more effective problem solver.
a.) Understand 'why' the problem exists. What is the actual root cause for the problem? If you know something about why the problem exists, you'll have a better time of resolving the problem. Let's take the example of a child who doesn't want to come to school. Before you can help identify a solution, it is important to find out why the child doesn't want to come to school. Perhaps there is a bully involved. So one of the first steps to becoming an effective problem solver is delving into the root cause of the problem.
b.) Be able to clearly identify the problem and the obstacles that the problem presents. All too often, individuals refer to a series of problems instead of tackling the actual problem at hand. Clearly state the problem and what obstacles the problem presents to you. Again, the child who doesn't want to come to school has the problem of it having a negative impact on his/her academic success.
c.) Once you have clearly stated the problem, you need to understand what you have control over and what you don't. Your efforts to resolve the problem must be within the areas where you have control. You may not have control over getting a child to come to school, but you do have control over dealing with the bully that is causing the problem of the child not wanting to attend school. Your efforts to solve the problem must focus on the areas for which you have control over.
d.) Do you have all the information you need? Solving problems is often like becoming involved in investigations. Have you thoroughly researched why the problem exists? Do you have all the information you need? If not, be persistent and seek out all information before tackling the problem.
e.) Don't jump to conclusions. Once you have all of your information, analyze it carefully and look at it from various viewpoints. Be as objective as possible and don't be quick to judge. Remain judgment free as much as possible. This is a time for you to use your critical thinking skills.
f.) Now determine your options for solutions. How many options do you have? Are you sure? Which options seem reasonable? Have you weighed the pros and cons of your options? Are there any limitations to your options? Are some options better than others and why? Are there advantages and disadvantages you need to take into consideration?
g.) You should now be ready to act. A well thought out strategy/solution is now in place. However, what is your plan to monitor its outcome? How will you know that your solution is working? Once your solution is in place, it is important to monitor and evaluate the outcome regularly.
h.) In Summary
You can use this approach to many classroom problems. A child that won't comply, a parent that is unhappy with their child's IEP, an educational assistant with whom you are having some conflict with. The strategies used in this problem solving plan are merely good life long skills to have.
i.) Some more tips:
a.) Clearly state the problem.
b.) Know what the obstacles are related to the problem.
c.) Determine what you have control over and what you don't.
d.) Make sure you have ALL the information you need.
e.) Identify all of your options and implement the best option for a solution.

2.) People Oriented – one of the factors that should be consider to become an effective analyst is to establish good interpersonal relationship with his/her team so they can work effectively as they share their ideas and skills with each other. I think I am a considerate and appreciative person. I always establish good relationship with other people. I believe that acknowledging their strength is one way of making them realize what makes them important and how will they become the best that they could be. In which it maybe leads them to be more competitive not only to others but to them selves. So they can be more effective in their career as individuals. Also, I have learned in life that you should not criticized vocally because it will be treated against you, instead let them realized their mistakes as it will give them the impact enough for them to realize and become a better person.

3.) Understanding –Systems Analyst is having systems analysis all the time in which it is a process of understanding in detail what a system should accomplish. Therefore, understanding is a basic characteristic an analyst must have to be effective in doing his/her job. In my case, I always assure my self that I understand things first before I do whatever it is need to be done. I even encounter complicated situations in solving a problem to the point that even if I did already my best, there is still lacking. I don’t have the choice but to go back to step1 in which understanding again the problem flow. Another learning of life, a single moment of understanding can flood a whole life with meaning. And, any fool can criticize, condemn, and complain but it takes character and self control to be understanding. To end, life is the first gift, love is the second, and understanding the third. When something is meaningfully understood, it is retained much longer, can be built upon to acquire further understanding, is usually very versatile in the situations and ways it can be used, and facilitates creativity. For example, the law of supply and demand (understanding that a higher price for something will reduce the amount demanded and increase the amount supplied) is something which one is not likely to forget once it is meaningfully understood. It is important for acquiring an understanding of consumption theory. It can be applied in a broad range of ways, including deciding how much to charge for cutting someone's lawn and deciding for whom to vote. And it helps one to be creative in finding ways to maximize your income. Similarly, once you understand what an atom is, you are not likely to forget it; it is essential for understanding the chemical behavior of matter (atomic theory); it is a broadly useful concept in chemistry; and it greatly facilitates a chemist's ability to develop creative ideas and products.

4.) Management Skills – Coordination is one factor in managing a team. An analyst must have the knowledge of different techniques in coordinating its team. Knowing the strength and weaknesses of his/her team members will give him/her the idea of which part of the project will they become effective. With this the analyst could predict if the project will be a failure or a success. The excellence of each member of the team will not be defining the success of the project but instead it is how they were managed for the project. I know how to manage both things and people that surrounds me now. I also believe that coordination is helping me in making my life manageable. With this, I am practicing already my managing skills, and hopefully make it better if I will experience the real scenario soon.
Management consists of the five processes, namely, planning, organizing, leading, coordinating and controlling. Management is basically an organization activity, the organization of work and resources, to achieve success. The successful organization of work and resources requires careful planning. Effective planning involves foresight of the potential obstacles and readiness to fight them. It is important to head the team and guide the team members on their way to success. While organizing and leading a group of people, management plays a vital role in the achievement of co-ordination and the exercise of control. Management is such a vast subject that it becomes difficult to restrict the definition of management to a few processes. Management is complex and critical and hence it is not right to confine its description to some management processes. Believing in the vastness of this subject, some prefer defining management as ‘all that managers do’. But what does a manager do? A manager is responsible for the successful implementation of management skills. A good manager needs to adhere to the basic management principles and exhibit the basic management skills in his/her personality.

Leadership: This is one of the most important management skills. Leadership comprises of the efficient organization of the resources in achieving a company goal. Leadership involves the management of human resources with an assessment of the strengths and weaknesses of each member of the team. It is about leading the people and guiding them towards the accomplishment of a common goal. Leadership includes a just allocation of work to the resources, planning of the implementation of tasks assigned and helping the team with task completion.

Team Building: This is another basic management skill that includes dealing with people, the most important asset of an organization. Encouraging the team members to speak up, come up with ideas and allowing them to make mistakes and learn from them can be described as a team building skill. To build a team, one needs to foster the team spirit in all of the team members. For the team to feel motivated to work, it is important for a manager to cater to their expectations, recognize their strengths and understand where they lack. The building of a team is about building the team spirit in members and maintaining it. The skill lies in knowing the team and encouraging them to take initiative and enthusiastically participate in every venture of the company.

5.) Detailed – Being detailed is marking by abundant detail or by thoroughness in treating small items or parts when it comes to organizing projects analysis, being detailed oriented is essential. Analyst organizes gathered data before reviewing them or forwarding them to programmers. Attention to details means that you recognize the possible instances may occur during the entire operation of the project. An analyst must have a fundamental curiosity. I believe that curiosity leads us to discover something new or invent something. Most importantly this would promote things to become a better one. I always wanted things be in detailed because I believe that people who are particular with details will give orderliness to his/her life.

6.) Technology Knowledge – The benefits of information technology in business is that Information technology has formed a major place in the different business areas. Most of the businesses have started their own in-house training for IT by their own staff. The different benefits in use includes: The use of IT is evidently a major component of work in businesses; Most responding companies prefer in-house training by their own staff for IT Training above other methods; The most important use of the IT by respondents is in office applications, followed by accounting software and sector-specific applications; and The sector-specific and project-management applications were expected to show the greatest growth in demand over the coming years. 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 maybe not work best with all the things with regards to technology but at least I am familiar with it and I know the basics, as it has been said by one of my professors that if I just know the basics then it is easier to adapt to new technologies. And I always look forward to new learning’s if it is needed to perform a certain task and make it successful. I mean I would not have a second thought on that.

7.) Perseverance – Perseverance is commitment, hard work, patience, endurance. It is being able to bear difficulties calmly and without complaint. And it is trying again and again. An analyst must have the determination to become successful in whatever he is doing. I persevere in life because pressure is with me. Willingness must be present so that the level of perseverance will be trigger. Well, I can say that willingness makes my life. Some of my learning’s in life in lined with this are the following: That failure is the path of least persistence. All things will come round to him who will but wait. (Longfellow). Only those who have the patience to do simple things perfectly will acquire the skill to do difficult things easily. Work hard and give it your best shot; never be a quitter. (Charley Taylor). Victory belongs to the most persevering. (Napoleon Bonaparte). Hitch your wagon to a star. (Emerson).To persevere is trusting in what hopes he has, is courage to a man. (Euripides).You may be disappointed if you fail, but you are doomed if you don't try. (Beverly Sills).Many strokes overthrow the tallest trees. (John Lyly).

8.) Communication Skills - Communication is best achieved through simple planning and control. Most conversations sort of drift along; in business, this is wasteful; as a manager, you seek communication rather than chatter. To ensure an efficient and effective conversation, there are three considerations: you must make your message understood, you must receive/understand the intended message sent to you, and you should exert some control over the flow of the communication .The analyst must be a good listener and be able to react to what people say. The system analyst must be able to communicate in writing and orally. I believe that I can communicate well in both written and oral. As with most personal skills oral communication cannot be taught. Instructors can only point the way. So as always, practice is essential, both to improve my skills generally and also to make the best of each individual presentation I make.

9.) Business Oriented – Being business oriented is realistic, has reliable solutions and customer focused. 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. An analyst should constantly being developed to make business more competitive I have learned already the basics because I did part time jobs in line with this. But I know this is not enough, yet I am willing to learn and I believe learning is a continuous process that’s why it is more effective to learn something through experiences. I am still considering having a part time job in business industry soon, to of course feed my lacking knowledge. I don’t think the key to success is simply producing good content, but being part of a network is also important.

10.) Competitive - As an analyst he/she must foresee things to be better. Being competitive is one of the characteristic an analyst should posses so that he/she will constantly aim for improvement. As a human I am competitive enough because I am surviving in life. Survival is one way of showing competitiveness. Also, dealing with problems in life and the risk we encounter are some factors that mold us to be more competitive.

Best and Worst Brain Foods

2010-01-04T00:21:00.000-08:00

FOR SHORT-TERM MEMORY

Drink This!: COFFEE

Fresh-brewed joe is the ultimate brain fuel. Caffeine has been shown to retard the aging process and enhance short-term memory performance. In one study, British researchers found that just one cup of coffee helps improve attention and problem-solving skills.

Not That!: ENERGY DRINKS/TOO MUCH COFFEE

Ever heard of the concept “too much of a good thing”? If you OD on caffeine—too many cups, a jolt of caf from the late afternoon onward, a Red Bull cocktail—it can mess with your shuteye schedule. Sleep is reboot time for your mental computer, and you don’t want to mess with it.

TO THINK FASTER

Eat This!: SALMON OR MACKEREL

If the Internal Revenue Service picks you for some up-close-and-personal auditing, you’ll want to be on your toes when they vet your deductions list. So put salmon or mackerel on the grocery list. The omega-3 fatty acids found in fatty fishes are a primary building block of brain tissue, so they’ll amp up your thinking power. Salmon is also rich in niacin, which can help ward off Alzheimer’s disease and slow the rate of cognitive decline.

Not That!: FULL-FAT ICE CREAM

Not all fats are created equal: Beware foods high in saturated fats, which can clog blood vessels and prevent the flow of nutrients and blood to the brain. Ice cream is not a brain-health food.

TO ENERGIZE:

Eat This!: HIGH-PROTEIN SALAD WITH VINAIGRETTE

The oil in the dressing will help slow down digestion of protein and carbs in the salad, stabilizing blood-sugar levels and keeping energy levels high. Build your salad on a bed of romaine and spinach for an added boost in riboflavin, and add chicken and a hard-boiled egg for more energizing protein. For other tips on how to build the perfect salad.

Not That!: PANCAKES OR BAGELSM

IT researchers analyzed blood samples from a group of people who had eaten either a high-protein or a high-carbohydrate breakfast. Two hours after eating, the carb eaters had tryptophan levels four times higher than those of the people who had eaten protein. The tryptophan in turkey is one of the reasons you crawl off for an afternoon nap after Thanksgiving dinner. So watch what you gobble.

TO CALM DOWN

Eat This!: LOW-FAT YOGURT OR MIXED NUTS

Scientists in Slovakia gave people 3 grams each of two amino acids—lysine and arginine—or a placebo, and asked them to deliver a speech. Blood measurements of stress hormones revealed that the amino acid-fortified guys were half as anxious during and after the speech as those who took the placebo. Yogurt is one of the best food sources of lysine; nuts pack loads of arginine.

Not That!: SODA

A study from the American Journal of Public Health found that people who drink 2½ cans of soda daily are three times more likely to be depressed and anxious, compared with those who drink fewer. So Mountain Dew is a Mental Don’t.

TO CONCENTRATE

Eat This!: PEPPERMINT TEA

The scent of peppermint helps you focus and boosts performance, according to researchers. Need to reach Chicago before nightfall, and you’re stuck in traffic around Cleveland? One study found that peppermint makes drivers more alert and less anxious.

Not That!: CANDY

Sugary foods incite sudden surges of glucose that, in the long term, cause sugar highs and lows, leading to a fuzzy state of mind. So you’ll need to avoid all the attention-busting sugar bombs on this list of the 20 most sugar-packed foods in America.

FOR GOOD MOODS AND GRINS

Eat This! ARUGULA OR SPINACH SALAD

Leafy greens—arugula, chard, spinach—are rich sources of B vitamins, which are key components on the assembly line that manufactures feel-good hormones such as serotonin, dopamine, and norepinephrine. According to a study published in the Journal of Neuroscience Nursing, a lack of B6 can cause nervousness, irritability, and even depression.

Not That!: WHITE CHOCOLATE

White chocolate isn’t chocolate at all, since it contains no cocoa solids. So it won’t stimulate the euphoria-inducing mood boosters like serotonin, as real chocolate does. Grab the real thing, the darker the better. More cacao means more happy chemicals and less sugar, which will eventually pull you down.

FOR SHARPER SENSES

Eat This!: 1 TBSP OF GROUND FLAXSEED DAILY

Flax is the best source of alphalinoleic, or ALA—a healthy fat that improves the workings of the cerebral cortex, the area of the brain that processes sensory information, including that of pleasure. To meet your quota, sprinkle it on salads or mix it into a smoothie or shake.

Not That!: ALCOHOL

This one’s obvious, but worth mentioning anyway. A drink or two can increase arousal signals, but more than that will actually depress your nervous system. This makes you sloppy, not sharp.

Source: http://health.yahoo.com/experts/eatthis/31477/best-and-worst-brain-foods/

Herbal Remedy to Depression

2010-01-03T23:49:00.000-08:00

Persistent depression is a serious disorder and you should see your doctor for treatment. In the meantime you might like to try a Licorice tea. Simply add some to any of your favorite herbal teas. Using up to approximately 3 cups of tea a day or more or ingesting larger amounts can produce headache, lethargy, sodium and water retention, loss of potassium and high blood pressure. At least eight Licorice compounds are monoamine oxidase (MAO) inhibitors which are compounds capable of potent antidepressant action.

meet the most intelligent man behind microsoft

2009-12-27T05:14:00.000-08:00

Bill Gates

http://www.microsoft.com/presspass/exec/billg/default.aspx

The Biggest Technology Flops of the Decade

2009-12-27T04:52:00.000-08:00

check this out! real and explosive!

http://www.usnews.com/money/personal-finance/slideshows/the-biggest-tech-flops-of-the-decade

amazing software disasters stories!

2009-12-25T05:37:00.000-08:00

http://www.devtopics.com/20-famous-software-disasters/

Interview Experience

2009-12-17T00:49:00.001-08:00

This was taken at the Emcor Davao Branch
frm left: Sir Vistal(systems analyst),Sir Nick(former systems analyst,present mngr),Groupmates

how to Persevere in life...

2009-12-11T20:49:00.000-08:00

Perseverance

What is perseverance?

Perseverance is commitment, hard work, patience, endurance.
Perseverance is being able to bear difficulties calmly and without complaint.
Perseverance is trying again and again.

You show perseverance when you ...

Give up your tv time to spend hours studying
Try a new sport that is very difficult but you don't give up
Have a learning disability but keep studying even when discouraged
Come from a home where there is fighting and unhappiness but you still try your best
Have missed a week of school but you work hard to catch up
Are at the end of a difficult race but you cross the finish line
Save money and make sacrifices to buy something
Spend hours practicing on your music
Study and work hard to raise your grade
Try out for something you weren't successful at the first time

Proverbs and maxims

Failure is the path of least persistence.
All things will come round to him who will but wait. (Longfellow)
Only those who have the patience to do simple things perfectly will acquire the skill to do difficult things easily.
Work hard and give it your best shot; never be a quitter. (Charley Taylor)

More quotes on perseverance

Victory belongs to the most persevering. (Napoleon Bonaparte)
Hitch your wagon to a star. (Emerson)
To persevere, trusting in what hopes he has, is courage to a man. (Euripides)
You may be disappointed if you fail, but you are doomed if you don't try. (Beverly Sills)
Many strokes overthrow the tallest trees. (John Lyly)

People who persevered despite handicaps and disabilities

Beethoven (composer) - was deaf
Ray Charles (musician) - is blind
Thomas Edison (inventor) - had a learning problem
Albert Einstein (scientist) - had a learning disability
Terry Fox (runner) - is an amputee with cancer
Stevie Wonder (musician) - is blind
James Earl Jones (actor) - was a stutterer
Helen Keller (author) - was deaf and blind
Marlee Matlin (actress) - is deaf
Franklin D. Roosevelt (president) - was paralyzed from polio
Vincent Van Gogh (artist) - was mentally ill
Woodrow Wilson (president) - had a learning problem
Itzhak Perlman (concert violinist) - was paralyzed from the waist down
Stephen Hawking (physicist) - had Lou Gehrig's disease (of the nervous system)

Want some more? visit: http://www.k12.hi.us/~mkunimit/perseverance.htm

about understanding....

2009-12-11T02:29:00.000-08:00

"The one who understands does not speak; the one who speaks does not understand."
Chinese Proverb

"Whatever you cannot understand, you cannot possess."
Johann Wolfgang von Goethe

"A single moment of understanding can flood a whole life with meaning."
unknown

"Any fool can criticize, condemn, and complain but it takes character and self control to be understanding and forgiving. "
Dale Carnegie

having bad results?

2009-12-09T21:33:00.000-08:00

"Never entertain ideas which you know would bring no good results
but lots of regrets,heartaches and misery....
If you don't like the ending
Never start!".