Monday, December 21, 2009

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

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



Shown in the figure above is my own perspective of our university’s life cycle. One of the missions of the university is to produce world class graduates thus the university had formulated certain standards which are seen and reflected on the curriculum of each program. The starting point of the life cycle of our school is the formulation of a good curriculum. Formulation of a curriculum includes gathering of data and analysis of data. This phase produces a product which is called a curriculum. A curriculum is made to be a tool to achieve some of the Vision, Mission and Goals of our university. Any school or university needs a good curriculum to set its reputation as a premiere school. University personnel formulates a curriculum which they think meets the standard.

The next phase would probably the testing phase as I assume that all curriculum are tested to see if they really do meet standards. It would be a disgrace to implement a curriculum which is substandard. This is right as any product must undergo a testing first before releasing it to the public. As you can see on the figure above the testing phase is connected to two other phases which are the “Formulate Curriculum” phase and the “Implement Curriculum” phase. It illustrates that after formulating a possible good curriculum it would go undergo several in-depth testing. This is done to make sure that the curriculum is worthy enough to be implemented. Needless to say a bad curriculum is sent back to the initial phase as it again is analyzed and developed further.

The next phase is the implementation of the curriculum wherein students are enrolled in an academic program where the curriculum is used. Implementation of a certain curriculum takes a long time as an average curriculum lasts for four years. Implementation phase is where the data collected and analyzed during the formulation phase is used. If the implementation is successful therefore there is also a chance that world class graduates are also produced.

The next phase is the evaluation of the curriculum which I think is essential and important on the life cycle. This is the phase wherein a curriculum is evaluated and analyzed again to see if it still meets the need of the society and if it still in line with mission of the university. It is known that curriculum changes from time to time as the need of the society is changing. As technology advances there is a great need to reevaluate the curriculum to see if it still meets the standard. I personally believe that this phase is very crucial to the life cycle of this university because this is the phase wherein we realize the current curriculum is obsolete.

On the question, “How do you know that the life cycle was developed specifically for the university?” I think we could see it if it fits and relates to the Vision, Mission, and Goals of the university. A life cycle is made to achieve a certain goal or purpose. For example, when developing a system it also undergoes a certain life cycle which is specifically made for that certain project for the purpose of a certain end product which is a good system. I could say that the life cycle as I see it is made specifically for the university as it certainly aids to reach the goal or the purpose of the university.

How do we know it meets our needs? In my own idea, I think the current life cycle is still meeting our needs as the university is still producing world class graduates as reflected on examination passers and achievements of individuals who graduated from our university. As discussed earlier there is a certain limit on how long could it meet our needs because technology is fast advancing and so must our curriculum. A good curriculum is not only measured by the graduates it produces but also the timeliness or the relevance of the curriculum on the society. For example, past curriculum for Education programs does not include computer subjects but as technology advances the curriculum adapted to the society and was revised to include computer subjects in the curriculum.


USEP’s Roots

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

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

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

The University of Southeastern Philippines has the following mandate:

To provide programs of instruction and professional training primarily in the fields of science and technology, especially medicine, fisheries, engineering and industrial fields.
To promote advanced studies, research and extension services and progressive leadership in science, agriculture, forestry, fisheries, engineering and industrial fields and other courses needed in the socio-economic development of Mindanao.

To develop courses at the graduate level along the fields of specialization and to respond to the needs of development workers in the academic community.

To provide non-formal education and undertake vigorous extension and research programs in food production, nutrition, health and sports development.
To offer scholarship and/or part-time job opportunities to deserving students from low-income families.

Mission

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

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

Vision

A PREMIER UNIVERSITY IN THE ASEAN REGION

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

Goals

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

KRA 1. Instruction

Produce globally competitive and morally upright graduates

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

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

KRA 3. Resource Management


Resources:

usep.edu.ph

Identify and discuss at least 3 systems development models




Identify and discuss at least 3 systems development models


Software process models often represent a networked sequence of activities, objects, transformations, and events that embody strategies for accomplishing software evolution. Such models can be used to develop more precise and formalized descriptions of software life cycle activities. Their power emerges from their utilization of a sufficiently rich notation, syntax, or semantics, often suitable for computational processing.
Software process networks can be viewed as representing multiple interconnected task chains (Kling 1982, Garg 1989). Task chains represent a non-linear sequence of actions that structure and transform available computational objects (resources) into intermediate or finished products. Non-linearity implies that the sequence of actions may be non-deterministic, iterative, accommodate multiple/parallel alternatives, as well as partially ordered to account for incremental progress. Task actions in turn can be viewed a non-linear sequences of primitive actions which denote atomic units of computing work, such as a user's selection of a command or menu entry using a mouse or keyboard. Winograd and others have referred to these units of cooperative work between people and computers as "structured discourses of work" (Winograd 1986), while task chains have become popularized under the name of "workflow" (Bolcer 1998).

Task chains can be employed to characterize either prescriptive or descriptive action sequences. Prescriptive task chains are idealized plans of what actions should be accomplished, and in what order. For example, a task chain for the activity of object-oriented software design might include the following task actions:
_ Develop an informal narrative specification of the system.
_ Identify the objects and their attributes.
_ Identify the operations on the objects.
_ Identify the interfaces between objects, attributes, or operations.
_ Implement the operations.
Clearly, this sequence of actions could entail multiple iterations and non-procedural primitive action invocations in the course of incrementally progressing toward an object-oriented software design.
Task chains join or split into other task chains resulting in an overall production network or web (Kling 1982). The production web represents the "organizational production system" that transforms raw computational, cognitive, and other organizational resources into assembled, integrated and usable software systems. The production lattice therefore structures how a software system is developed, used, and maintained. However, prescriptive task chains and actions cannot be formally guaranteed to anticipate all possible circumstances or idiosyncratic foul-ups that can emerge in the real world of software development (Bendifallah 1989, Mi 1990). Thus, any software production web will in some way realize only an approximate or incomplete description of software development.




Waterfall
The classic software life cycle (or "waterfall chart") and stepwise refinement models are widely instantiated in just about all books on modern programming practices and software engineering. The incremental release model is closely related to industrial practices where it most often occurs. Military standards based models have also reified certain forms of the classic life cycle model into required practice for government contractors. Each of these four models uses coarse-grain or macroscopic characterizations when describing software evolution. The progressive steps of software evolution are often described as stages, such as requirements specification, preliminary design, and implementation; these usually have little or no further characterization other than a list of attributes that the product of such a stage should possess. Further, these models are independent of any organizational development setting, choice of programming language, software application domain, etc. In short, the traditional models are context-free rather than context-sensitive. But as all of these life cycle models have been in use for some time, we refer to them as the traditional models, and characterize each in turn.

The classic software life cycle is often represented as a simple prescriptive waterfall software phase model, where software evolution proceeds through an orderly sequence of transitions from one phase to the next in order (Royce 1970). Such models resemble finite state machine descriptions of software evolution. However, these models have been perhaps most useful in helping to structure, staff, and manage large software development projects in complex organizational settings, which was one of the primary purposes (Royce 1970, Boehm 1976). Alternatively, these classic models have been widely characterized as both poor descriptive and prescriptive models of how software development "in-the-small" or "in-the-large" can or should occur. Figure 1 provides a common view of the waterfall model for software development attributed to Royce (1970).

Waterfall
-Linear sequence of stages/phases
-Requirements – HLD – DD – Code – Test – Deploy
-A phase starts only when the previous has completed; no feedback
-The phases partition the project, each addressing a separate concern\
-Linear ordering implies each phase should have some output
-The output must be validated/certified
-Outputs of earlier phases: work products
-Common outputs of a waterfall: SRS, project plan, design docs, test plan and
reports, final code, supporting docs

-Linear ordering implies each phase should have some output
-The output must be validated/certified
-Outputs of earlier phases: work products
-Common outputs of a waterfall: SRS, project plan, design docs, test plan and reports, final code, supporting docs

-Conceptually simple, cleanly divides the problem into distinct phases that can be performed independently
-Natural approach for problem solving
-Easy to administer in a contractual setup – each phase is a milestone
-Has been used widely
-Well suited for projects where requirements can be understood easily and technology decisions are easy
-I.e. for familiar type of projects it still may be the most optimum

Strength
Simple, Easy to execute, Intuitive and logical, Easy contractually
Weakness
All or nothing – too, risky, Require frozen early, May chose outdated hardware/tech, Disallows changes, No feedback from users, Encourages requirements bloating
Types of Projects
Well understood problems, short duration projects, automation of existing manual systems

In Royce's original Waterfall model, the following phases are followed in order:

1. Requirements specification
2. Design
3. Construction (AKA implementation or coding)
4. Integration
5. Testing and debugging (AKA Validation)
6. Installation
7. Maintenance

To follow the waterfall model, one proceeds from one phase to the next in a purely sequential manner. For example, one first completes requirements specification, which are set in stone. When the requirements are fully completed, one proceeds to design. The software in question is designed and a blueprint is drawn for implementers (coders) to follow — this design should be a plan for implementing the requirements given. When the design is fully completed, an implementation of that design is made by coders. Towards the later stages of this implementation phase, separate software components produced are combined to introduce new functionality and reduced risk through the removal of errors.


Prototyping
Prototyping addresses the requirement specification limitation of waterfall. Instead of freezing requirements only by discussions, a prototype is built to understand the requirements. Helps alleviate the requirements risk. A small waterfall model replaces the requirements stage.
Development of prototype- Starts with initial requirements. Only key features which need better understanding are included in prototype. No point in including those features that are well understood. Feedback from users taken to improve the understanding of the requirements.
Cost can be kept low- Build only features needing clarification. “quick and dirty” – quality not important, scripting etc can be used. Things like exception handling, recovery, standards are omitted. Cost can be a few % of the total. Learning in prototype building will help in building, besides improved requirements.
Advantages: requirements will be more stable, requirements frozen later, experience helps in the main development.
Applicability: When required to elicit and confidence in reqs is low; i.e. where reqs are not well understood. Prototyping is a technique for providing a reduced functionality or a limited performance version of a software system early in its development (Balzer 1983, Budde 1984, Hekmatpour 1987). In contrast to the classic system life cycle, prototyping is an approach whereby more emphasis, activity, and processing are directed to the early stages of software development (requirements analysis and functional specification). In turn, prototyping can more directly accommodate early 10 user participation in determining, shaping, or evaluating emerging system functionality. Therefore, these up-front concentrations of effort, together with the use of prototyping technologies, seeks to trade-off or otherwise reduce downstream software design activities and iterations, as well as simplify the software implementation effort. (see Rapid Prototyping) Software prototypes come in different forms including throwaway prototypes, mock-ups, demonstration systems, quick-and-dirty prototypes, and incremental evolutionary prototypes (Hekmatpour 1987). Increasing functionality and subsequent evolvability is what distinguishes the prototype forms on this list. Prototyping technologies usually take some form of software functional specifications as their starting point or input, which in turn is simulated, analyzed, or directly executed. These technologies can allow developers to rapidly construct early or primitive versions of software systems that users can evaluate. User evaluations can then be incorporated as feedback to refine the emerging system specifications and designs. Further, depending on the prototyping technology, the complete working system can be developed through a continual revising/refining the input specifications. This has the advantage of always providing a working version of the emerging system, while redefining software design and testing activities to input specification refinement and execution. Alternatively, other prototyping approaches are best suited for developing throwaway or demonstration systems, or for building prototypes by reusing part/all of some existing software systems. Subsequently, it becomes clear why modern models of software development like the Spiral Model (described later) and the ISO 12207 expect that prototyping will be a common activity that facilitates the capture and refinement of software requirements, as well as overall software development.




Spiral Model
The Spiral Model. The spiral model of software development and evolution represents a riskdriven approach to software process analysis and structuring (Boehm 1987, Boehm et al, 1998). This approach, developed by Barry Boehm, incorporates elements of specification-driven, prototype-driven process methods, together with the classic software life cycle. It does so by representing iterative development cycles as an expanding spiral, with inner cycles denoting early system analysis and prototyping, and outer cycles denoting the classic software life cycle. The radial dimension denotes cumulative development costs, and the angular dimension denotes progress made in accomplishing each development spiral. See Figure 3. Risk analysis, which seeks to identify situations that might cause a development effort to fail or go over budget/schedule, occurs during each spiral cycle. In each cycle, it represents roughly the same amount of angular displacement, while the displaced sweep volume denotes increasing levels of effort required for risk analysis. System development in this model therefore spirals out only so far as needed according to the risk that must be managed. Alternatively, the spiral model indicates that the classic software life cycle model need only be followed when risks are greatest, and after early system prototyping as a way of reducing these risks, albeit at increased cost. The insights that the Spiral Model offered has in turned influenced the standard software life cycle process models, such as ISO12207 noted earlier. Finally, efforts are now in progress to integrate computer-based support for stakeholder negotiations and capture of trade-off rationales into an operational form of the WinWin Spiral Model (Boehm et al, 1998). (see Risk Management in Software Development)


(JAD)
Joint Application Development (JAD) is a technique for engaging a group or team of software developers, testers, customers, and prospective end-users in a collaborative requirements elicitation and prototyping effort (Wood and Silver 1995). JAD is quintessentially a technique for facilitating group interaction and collaboration. Consultants often employ JAD or external software system vendors who have been engaged to build a custom software system for use in a particular organizational setting. The JAD process is based on four ideas:
1.People who actually work at a job have the best understanding of that job.
2.People who are trained in software development have the best understanding of the
possibilities of that technology.
3. Software-based information systems and business processes rarely exist in isolation -- they transcend the confines of any single system or office and effect work in related departments. People working in these related areas have valuable insight on the role of a system within a larger community.
4.The best information systems are designed when all of these groups work together on a project as equal partners. Following these ideas, it should be possible for JAD to cover the complete development life cycle of a system. The JAD is usually a 3 to 6 month well-defined project, when systems can be constructed from commercially available software products that do not require extensive coding or complex systems integration. For large-scale projects, it is recommended that the project be organized as an incremental development effort, and that separate JAD's be used for each increment (Wood and Silver 1995). Given this formulation, it is possible to view open source software development projects that rely on group email discussions among globally distributed users and developers, together with Internet-based synchronized version updates (Fogel 1999, Mockus 2000), as an informal variant of JAD.




Timeboxing
- Iterative is linear sequence of iterations
- Each iteration is a mini waterfall – decide the specs, then plan the iteration
- Time boxing – fix an iteration duration, then determine the specs
- Divide iteration in a few equal stages
- Use pipelining concepts to execute iterations in parallel
- General iterative development – fix the functionality for each iteration, then plan and execute it
- In time boxed iterations – fix the duration of iteration and adjust the functionality to fit it
- Completion time is fixed, the functionality to be delivered is flexible
- This itself very useful in many situations
- Has predictable delivery times
- Overall product release and marketing can be better planned
- Makes time a non-negotiable parameter and helps focus attention on schedule
- Prevents requirements bloating
- Overall dev time is still unchanged
- What if we have multiple iterations executing in parallel
- Can reduce the average completion time by exploiting parallelism
- For parallel execution, can borrow pipelining concepts from hardware
- This leads to Timeboxing Process Model
- With this type of time boxes, can use pipelining to reduce cycle time
- Like hardware pipelining – view each iteration as an instruction
- As stages have dedicated teams, simultaneous execution of different iterations is possible
Advantages: Shortened delivery times, other adv of iterative, distr. execution
Applicability: When short delivery times v. imp.; architecture is stable; flexibility in feature grouping


RUP Model
- Rational Unified Process is another iterative model
- Software development is divided into cycles, each cycle delivering a fully working system
- Each cycle executed as separate project
- Execution of a cycle is broken into four consecutive phases, each phase ending with a milestone achievement
- Phases in a project
- Inception phase: ends with Lifecycle Objectives milestone; vision and high level capability of system defined
- Elaboration phase: Lifecycle architecture milestone; most requirements defined and architecture designed
- Construction phase: Initial operational capability milestone
- Transition phase: Product release; transition product from development to production
- Each phase itself can be done in multiple iterations, each iteration having an external/internal customer
- Generally construction has multiple iterations; elaboration can also be meaningfully done in multiple iterations
- Engineering tasks are called core process workflows
- These sub processes correspond to tasks of requirements, design, implementation, testing, project management, etc
- Many sub processes may be active in a phase, the volume of activity generally differs depending on the project
- Sub processes are active in all phases
- Volume of activity in each phase differs depending on the project
- Hence, a project can use RUP to implement waterfall by having requirements process be active only in the elaboration phase
- Or prototyping by having a lot of construction activity in the elaboration phase
- RUP is therefore a flexible framework

Strength
All benefits of iterative
Provides a flexible framework for a range of projects

Weakness
For each project, one has to design the process

Types of Projects
Can be applied to a wide range as it allows flexibility



Extreme Programming or Agile Process Model
- Agile approaches developed in 90s as a reaction to document driven approaches
- Most agile approaches have some common principles
- Working software is the measure of progress
- Software should be delivered in small increments
- Even late changes should be allowed
- Prefer face to face commn over documentation
- Continuous feedback and customer involvement is necessary
- Prefer simple design which evolves
- Delivery dates are decided by the empowered teams
- Many agile methodologies have been proposed; extreme programming (XP) is one of the most popular
- An XP project starts with user stories, which are short descr of user needs
- Details are not included
- Each user story written on a separate card so they can be combined in diff ways
- Team estimates how long it will take to implement a user story
- Estimates are rough
- Release planning is done
- Defines which stories are to be built in which release, and dates for release
- Frequent and small releases encouraged
- Acceptance tests also built from user stories; used to test before release
- Bugs found in AT are fixed in next release
- Development done in iterations of a few weeks each
- Iteration starts with planning, in which stories to be implemented are selected – high risk high value are chosen first
- Details of stories obtained during the development and implemented
- Failed AT of previous iteration are also fixed
- Well suited for situations where volume and pace of requirements is high
- Customer is willing to engage heavily with the team
- The team is collocated and is not too large (less than 20 or so)
- Requires strong capability in team members
Strength
Agile and responsive
Short delivery cycles
Continuous feedback can lead to better acceptance
Weakness
Can tend to become ad-hoc
Lack of documentation can be an issue
Continuous code change is risky
Types of Projects
Where requirements are changing a lot, customer is deeply engaged in development, and where the size of the project is not too large



References:
Process Models in Software Engineering
Walt Scacchi, Institute for Software Research, University of California, Irvine
February 2001

J.J. Marciniak (ed.), Encyclopedia of Software Engineering, 2nd
Edition, John Wiley and Sons, Inc, New York, December 2001.

Discuss the role of a systems analyst as 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.

A project manager is the person accountable for accomplishing the stated project objectives. Key project management responsibilities include creating clear and attainable project objectives, building the project requirements, and managing the triple constraint for projects, which are; cost, time, and quality (also known as scope). A project manager is often a client representative and has to determine and implement the exact needs of the client, based on knowledge of the firm they are representing. The ability to adapt to the various internal procedures of the contracting party, and to form close links with the nominated representatives, is essential in ensuring that the key issues of cost, time, quality and above all, client satisfaction, can be realized.

A Software Project Manager has many of the same skills as their counterparts in other industries. Beyond the skills normally associated with traditional project management in industries such as construction and manufacturing, a software project manager will typically have an extensive background in software development. Many software project managers hold a degree in Computer Science, Information Technology or another related field and will typically have worked in the industry as a software engineer.

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

A Systems Analyst works directly with different departments in a company to make work sharing, and communication easier, as well as streamlining processes through optimizing systems. To do so, a Systems Analyst needs an intimate knowledge of computers, as well as the ability to work directly with a non-technical audience in their own language.
Systems Analysts are often seen overseeing large projects to make sure that all of the internal elements are running as smoothly and as effectively as possible, and to make them as close to the specification as possible. A Systems Analyst's work is seen anytime a job is completed ahead of schedule, and more effectively than it was previously possible to do so.

A good example of a Systems Analyst is in the evolution of high-tech factories. In many cases, factories started out smaller, with much of the work being done at a high cost to the company and to the consumer because of inefficient assembly lines or badly organized teams. A Systems Analyst will optimize the factories to save their company money and time so they can produce a better, cheaper product for the end user.
Davao Light and Power Company is the third largest privately-owned electric utility in the Philippines. It holds the franchise for distributing electric power to Davao City, the largest city in the world in terms of land area, as well as Panabo City and the municipalities of Carmen, Dujali, and Sto. Tomas in Davao del Norte.
Last December 11, 2009 together with my classmates we went to Davao Light and Power Company at Bajada Davao City to interview a system analyst.

During the interview he told us that a system analyst

Must have communication skills
* a system analyst must know how to deliver soothing to the user
* a system analyst must know how to deal with the people
* a system analyst must know how to deal with the clients

Must have technical skills
a system analyst must know all about the system of the company
it includes system application, administrative work, business functions, and lastly technical functions

He also told us the following:

The nature of relationship includes:
- the cost process of the system, the grow of business process that includes its electric utility, their IS plan, its framework, the business plan of IP management, the support of the business owners, the efficient on one way or another and lastly its technological advance.

We also ask about his frustrations about being a system analyst, he told us that it is a case to case basis, but the frustrations bond with hiring developers in the company to work with the system, another is the product deliverables should satisfy, and lastly in the users part – its slow productivity.

About the Success factors:
-project cost(budget constraints)
-resources
-people
-time
-support from the top management
-resistance of the users

A systems analyst performs the following tasks:
- Interact with the customers to know their requirements
- Interact with designers to convey the possible interface of the software
- Interact/guide the coders/developers to keep track of system development
- Perform system testing with sample/live data with the help of testers
- Implement the new system
- Prepare High quality Documentation


Systems analyst as a project manager
-It includes creating clear and attainable project objectives.
-Also building the project requirements
-And managing the constraint for project costs
-Managing the constraint for projects time
-Managing the constraint for projects quality

References:
http://en.wikipedia.org/wiki/Project_manager
http://en.wikipedia.org/wiki/Project_manager#Software_Project_Manager








Wednesday, December 16, 2009

Interview a Systems Analyst and ask what skills and characteristics must a systems analyst develop in order to be more effective in any design modelin

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


Davao Light and Power Company is the third largest privately-owned electric utility in the Philippines. It holds the franchise for distributing electric power to Davao City, the largest city in the world in terms of land area, as well as Panabo City and the municipalities of Carmen, Dujali, and Sto. Tomas in Davao del Norte.
Last December 11, 2009 together with my classmates we went to Davao Light and Power Company at Bajada Davao City to interview a system analyst.

During the interview he told us that a system analyst

Must have communication skills
* a system analyst must know how to deliver soothing to the user
* a system analyst must know how to deal with the people
* a system analyst must know how to deal with the clients

Must have technical skills
a system analyst must know all about the system of the company
it includes system application, administrative work, business functions, and lastly technical functions

And the last thing he said a system analyst must know how to model process not necessarily good in programming.

Systems analysts are the architects, as well as the project leaders, of an information system. It is their job to develop solutions to users' problems, determine the technical and operational feasibility of their solutions, as well as estimate the costs to develop and implement them.
They develop prototypes of the system along with the users, so that the final specifications are examples of screens and reports that have been carefully reviewed. Experienced analysts leave no doubt in users' minds as to what is being developed, and they insist that all responsible users review and sign off on every detail.


Systems analysts require a balanced mix of business and technical knowledge, interviewing and analytical skills and a good understanding of human behavior.
According also to the book Systems Analysis And Design In A Changing World, 4th Edition, by Satzinger, Jackson, Burd, analysts must certainly know about computers and computer programs. They possess special skills and develop expertise in programming. But they must also bring to the job a fundamental curiosity to explore how things are done and the determination to make them work better. A systems analyst also is a business problem solve.
The book also said that a systems analyst must also have Technical Knowledge and Skills, Business Knowledge and Skills and People Knowledge and Skills.
Technical Knowledge and Skills-
A systems analyst should understand the fundamentals about the following:
• Computers and how they work
• File database, and storage hardware and software
• Input and output hardware and software
• Computer networks and protocols
• Programming languages, operating systems, and utilities
• Communication and collaboration technology such as digital telephones, video-conferencing, and Web-based document management systems

A system analyst also needs to know a lot about tools and techniques for developing systems.

Tools are software products that are used to develop analysis and design specifications and completed system components. Some example tools are software packages, integrated development environments, and CASE tools or support tools.

Techniques are strategies for completing specific system development activities. Some examples of techniques include following:

• Project planning techniques
• Cost/benefit analysis techniques
• Interviewing techniques
• Requirements modeling techniques
• Architectural design techniques
• Network configuration techniques
• Database design techniques


Business Knowledge and Skills-
The analysts need to know:
• Business functions
• Organizational structure
• Management techniques
• Functional work processes

People Knowledge and Skills:
Understand how people
• Think
• Learn
• React to Change
• Communicate
• Work
According to wikipedia:
A systems analyst is responsible for researching, planning, coordinating and recommending software and system choices to meet an organization's business requirements. The systems analyst plays a vital role in the systems development process. A successful systems analyst must acquire four skills: analytical, technical, managerial, and interpersonal. Analytical skills enable systems analysts to understand the organization and its functions, which helps him/her to identify opportunities and to analyze and solve problems. Technical skills help systems analysts understand the potential and the limitations of information technology. The systems analyst must be able to work with various programming languages, operating systems, and computer hardware platforms. Management skills help systems analysts manage projects, resources, risk, and change. Interpersonal skills help systems analysts work with end users as well as with analysts, programmers, and other systems professionals.
Because they must write user requests into technical specifications, the systems analysts are the liaisons between vendors and the IT professionals of the organization they represent. They may be responsible for developing cost analysis, design considerations, and implementation time-lines. They may also be responsible for feasibility studies of a computer system before making recommendations to senior management.
A systems analyst performs the following tasks:
• Interact with the customers to know their requirements
• Interact with designers to convey the possible interface of the software
• Interact/guide the coders/developers to keep track of system development
• Perform system testing with sample/live data with the help of testers
• Implement the new system
• Prepare High quality Documentation
A system analyst is the person who selects and configures computer systems for an organization or business. His or her job typically begins with determining the intended purpose of the computers. This means the analyst must understand the general objectives of the business, as well as what each individual user's job requires. Once the system analyst has determined the general and specific needs of the business, he can choose appropriate systems that will help accomplish the goals of the business.
When configuring computer systems for a business, the analyst must select both hardware and software. The hardware aspect includes customizing each computer's configuration, such as the processor speed, amount of RAM, hard drive space, video card, and monitor size. It may also involve choosing networking equipment that will link the computers together. The software side includes the operating system and applications that are installed on each system. The software programs each person requires may differ greatly between a user, which is why it is important that the system analyst knows the specific needs of each user.

Computer systems analyst is a general job title. Alternate, general titles include computer systems developer and computer systems architect. Specific job titles vary by organization.
Computer systems analyst job duties also vary by organization. But, generally, they customize computer systems to meet specific information-technology needs.
Broadly, computer systems analyst job duties include:
-Planning, designing, installing and developing new computer systems
-Revamping existing computer systems for new tasks
-Networking computer systems with others
-Preparing cost-benefit and return-on-investment (ROI) reports for management
-Testing and debugging new or revamped computer systems and the networks on which they communicate.

A computer systems analyst typically performs his or her job duties by coordinating with other information-technology professionals.

A systems analyst solves business problems using information systems technology. Systems analyst has broad knowledge and variety of skills, including technical, business, and people. Systems analyst encounters a variety of rapidly changing technologies. Integrity and ethical behavior are crucial to success for the analyst.

Systems Analyst must have knowledge in fields of business such as entrepreneurship, marketing, banking, commerce, finance and the like. Also he/she must have skills on accounting which it is the essential part of business skills. In what the instructor has mentioned about the difference of accounting and account, these differences are based on way of using business skills. Aside from that, money is the important thing in doing analysis in the business systems. Examples of systems which require business skills are e-commerce, banking system, payroll and the like.
In becoming a good systems analyst, you must have to understand the organizational structures, and its functions. This will help to get the opportunity to find the best solutions for the particular organizations. To understand the structure of the organization, you have to know the overview, vision, mission and objectives of a particular organization. You have to know also the history and the people behind the organization. You have also needed more data in the said organization in order to come up with the right organization structure which will be the basis for the particular solution. The said skills requires statistical ability which it computes the particular data. Examples of systems which require analytical skills are population control and monitoring system, whether control and the like.
An Information System Professional has many tasks which are the following:

1. Strategic Consulting
2. Project & Program Management
3. Network Infrastructure
4. Systems Infrastructure
5. Application Development, Integration & Deployment

With the responsibilities of the an Information System Professional it has a possibility that sometimes the Information System Professional is frustrated and can’t work well.

Computer systems analysts start their work by asking people what they need their computers to do. Then, they plan a computer system that can do those tasks well. A system can include many computers working together and different types of software and tools. After analysts understand what the system needs to do, they break down the task into small steps. They draw diagrams and charts to show how information will get into the computers, how that information will be processed, and how it will get to the people who need it. For example, analysts might decide how sales information will get into a store's computers and how the computer will add up the information in a way that makes it useful for store managers. Analysts experiment with different computer system plans. They try various tools and steps until they find the system that is fastest, easiest, and least expensive. Next, analysts decide which computers, software, and tools to buy. They also tell computer programmers how to make any new software that is needed. They give the programmers step-by-step instructions. Some analysts help make the software, too.

During the interview he told us that a system analyst

The nature of relationship includes:
-cost process
-grow of business process
-IS plan
-its framework
-business plan of IP management
-support of the business owners
-efficient on one way or another
-and lastly technological advance

We also ask about his frustrations: (he told us that it is a case to case basis)
-hiring developers
-product deliverables should satisfy
-

About the Success factors:
-project cost(budget constraints)
-resources
-people
-time
-support from the top management
-resistance of the users

A systems analyst performs the following tasks:
- Interact with the customers to know their requirements
- Interact with designers to convey the possible interface of the software
- Interact/guide the coders/developers to keep track of system development
- Perform system testing with sample/live data with the help of testers
- Implement the new system
- Prepare High quality Documentation

A Systems Analyst works directly with different departments in a company to make work sharing, and communication easier, as well as streamlining processes through optimizing systems. To do so, a Systems Analyst needs an intimate knowledge of computers, as well as the ability to work directly with a non-technical audience in their own language.
Systems Analysts are often seen overseeing large projects to make sure that all of the internal elements are running as smoothly and as effectively as possible, and to make them as close to the specification as possible. A Systems Analyst's work is seen anytime a job is completed ahead of schedule, and more effectively than it was previously possible to do so.
A good example of a Systems Analyst is in the evolution of high-tech factories. In many cases, factories started out smaller, with much of the work being done at a high cost to the company and to the consumer because of inefficient assembly lines or badly organized teams. A Systems Analyst will optimize the factories to save their company money and time so they can produce a better, cheaper product for the end user.

Resources:
http://en.wikipedia.org/wiki/Systems_analyst
http://www.bls.gov/oco/ocos287.htm
http://www.techterms.com/definition/systemanalyst
http://www.prospects.ac.uk/p/types_of_job/systems_analyst_job_description.jsp
http://www.ble.dole.gov.ph/jobdetail/system-analyst.htm
http://jobsearchtech.about.com/od/computerjob13/a/systems_analyst.htm


University of Southeastern Philippines Automated Election System

Project e-VOTE

Introduction

Voting system allows voters to choose between options, often in an election where candidates are selected for public office. Voting can be also used to award prizes, to select between different plans of action, or by a computer program to find a solution to a problem. Voting can be contrasted with consensus decision making and hierarchical or authoritarian systems.

Electronic voting systems for electorates have been in use since the 1960s. It may offer advantages compared to other voting techniques. An electronic voting system can be involved in any one of a number of steps in the setup, distributing, voting, collecting, and counting of ballots, and thus may or may not introduce advantages into any of these steps.

Unlike before that people were manually counting and requires a physical ballot that visually represents voter intent and the physical ballots are read and interpreted; then results are individually tabulated. Today, Electronic voting (also known as e-voting) is a term encompassing several different types of voting, embracing both electronic means of casting a vote and electronic means of counting votes.

Problem Statement

During elections conducted within the university there are issues and problems that need to be addressed. The following are the issues and problems of election:

1. Large cost of manual elections

Because it needs many people to conduct an election, it means that it needed large cost for the food of the people in charge and for the school supplies.

2. Time consuming manual election

The ballots are read and interpreted manually and then results are individually tabulated, that would result to a delay in declaring the winners.

3. Election fraud

Since it would need a long time for canvassing the vote’s cast it will have a chance to cheat.

The issues stated above affects all the students in the University of Southeastern Philippines. Specifically the Obrero Campus Student Council (OCSC), Campus Club Organization (CCO), University League of Class Mayors (ULCM), Local Councils of different colleges, and the Academic organizations.

To solve this problem we propose a simple Automated Election System that involves a reliable election procedure, rapid generation of online election and fast and secure canvassing of votes.

The first interface is the login page where the students or the users will validate if he/she is an enrolled student of the school. The interface will be comprised of fields where the user can enter his/her name and ID number. When the users have entered the system, voting system allows voters to choose between options, the user can now vote and then the votes will automatically be counted by the system. The user may also vote through mobile devices, and use a unique format so that the system will know if the user is currently enrolled and a valid voter. If the system accepts the user input then, eventually it will count his votes. The system will send back a confirmation message to the user to confirm if he has voted successfully.

When the voting time is over, the system will generate a statistic result showing the number of votes for each candidate.

Current Scenario



Figure 1.1

Until today, people were manually counting and require a physical ballot that visually represents voter intent and the physical ballots are read and interpreted; then results are individually tabulated. As you can see in the Figure 1.1, the students will go in their respective poll precinct. When voting time is over the ballots will be collected for casting of votes. The day after, declaring of candidate who won.



Economical Analysis


COST

BENEFITS

  • System Development Costs

(Pay check for the developers)

  • Operational Cost

(Installation / deployment cost, maintenance cost, internet connection cost, and other operation costs)

  • Equipment Cost

(Desktop/laptop, mobile devices, servers and other equipment cost)

  • A fully functional E-Voting IS

(An automated election system that is web based and mobile application)

· The system will be more

accessible to the student

  • It would minimize election cost.

· It also minimizes election

fraud

  • It could be integrated with

existing systems and databases

· It could be further develop to

cater other functions

  • No paper use, it can contribute to the green campus computing

We believe that this system is economically feasible. The benefits weigh more than the cost thus, suggesting this system is economically feasible. We also believe that a university with this size is able to fund such developments considering the gains the university could have.

Budget Analysis

Below are estimates of the cost of current manual election:

Cost of manual election

DESCRIPTION

COST

Comelec

20,000 php

Academic Organization (35)

17,500 php

ULCM

5,000 php

CCO

1,000 php

Below are estimates of the cost of proposed automated election:

Cost of E-Vote

DESCRIPTION

COST

System Development

20,000 php

Maintenance

500 php /month

A fully developed E-VOTE system would amount to 20,000 on the first year then 6,000 on preceding years. We believe that it is cost effective considering the benefits of this system give.

Risk Analysis


This system offers features such as simultaneous online elections as it aims to cater more than one election at a time. It features a customizable election page where the administrator may choose to generate a different election page depending on the demand of the organization. It also features an automated storage system that is more efficient in terms of capacity and data security. It features an automated counting of votes thus consumes less time during canvassing. The development of this system is a move that tries to solve the problems faced during elections conducted within the university such as the large cost of manual elections and election fraud. If well develop this system may be an inspiration to other organizations that conducts elections. The first part is the manual system, which involves accepting of candidacy. The second part is the automated system, which involves online casting of votes, automated counting of votes, data storage and also a part of data process. This system caters to a university specifically University of Southeastern Philippines.

Benefits

Project eVOTE provides the following benefits:

  • It minimizes the cost of an election.
  • It minimizes the time needed for canvassing the vote’s cast.
  • Election procedure is automated thus eliminates or minimizes election fraud and cheating.
  • It could cater to any election within the University.
  • It can be integrated with other existing systems and databases.
  • It has a concept of green computing as it minimizes the use of paper materials.
  • It may be developed further to cater future problems concerning elections.

Features

Project eVOTE has the following features:

  • It could and efficiently generate an online election.
  • It could generate customized online election depending on the situation.
  • It could cater to a number of elections at the same time.
  • A picture of a candidate is included for better recognition.
  • It could store previous results through its database that could be used in the future studies.
  • It is targeted to have voting stations on key positions within the university to make the system accessible to all possible users.
  • It has a user- friendly graphical user interfaces and easy to use functions.