Análise de Sistemas de Informação (ASI)

Transcrição

1 Análise de Sistemas de Informação (ASI) Ano LecFvo 2012/2013 * 1º Semestre Curso de Mestrado em Engenharia InformáFca (10513) Aula 5 1

2 Previously... Content adapted from Systems Analysis and Design with UML, 4th EdiFon InternaFonal Student Version Alan Dennis, Barbara Haley Wixom and David Tegarden, Wiley,

3 Systems Development Life Cycle (SDLC) Planning ImplementaFon Analysis Design 3

4 SDLC: The Planning Phase Project IniFaFon Develop/receive a system request Conduct a feasibility analysis Technical feasibility Economic feasibility OrganizaFonal feasibility Project Management (acer approval) Develop the work plan and produce a project plan Staff the project Monitor & control the project 4

5 Project Management Content adapted from Systems Analysis and Design with UML, 4th EdiFon InternaFonal Student Version Alan Dennis, Barbara Haley Wixom and David Tegarden, Wiley,

6 Project SelecFon Projects are approved, declined or delayed based on value added vs. risks Project porholio management Goals: Maximize cost/benefit rafo Maintain an opfmal mix of projects based on: Risk Size, cost & length of Fme to complete Purpose, scope & business value Limited resources require trade offs Selected projects enter the project management process 6

7 At Marrio), we don t have IT projects we have business ini4a4ves and strategies that are enabled by IT. As a result, the only 4me a tradi4onal IT project occurs is when we have an infrastructure upgrade that will lower costs or leverage be)er func4oning technology. In this case, IT has to make a business case for the upgrade and prove its value to the company. The way IT is involved in business projects in the organiza4on is twofold. First, senior IT posi4ons are filled by people with good business understanding. Second, these people are placed on key business commi)ees and forums where real business happens, such as finding ways to sa4sfy guests. Because IT has a seat at the table, we are able to spot opportuni4es to support business strategy. We look for ways in which IT can enable or be:er support business ini<a<ves as they arise. Therefore, business projects are proposed, and IT is on component of them. These projects are then evaluated the same as any other business proposal, such as a new resort by examining the ROI and other financial measures. At the organiza4onal level, I think of projects as must do s, should do s and nice todo s. The must do s are required to achieve core business strategy, such as guest preference. The should do s help grow the business and enhance the func4onality of the enterprise. The nice to do s are more experimental and look farther out into the future. The organiza<on s project porbolio should have a mix of all three kinds of projects, with a much greater por4on devoted to the must do s. Carl Wilson, CIO, Marrio) Corpora4on 7

8 Project Management Tools Aids in creafng workplans IdenFfy all tasks, their sequence and esfmate the Fme to complete each one Work breakdown structures (WBS): a hierarchy of tasks to idenffy: DuraFon of each task Current status of each task Task dependencies (shows which tasks must be completed before others can begin) Ganl charts: horizontal bar chart that shows the WBS graphically Network diagrams: PERT and CPM

9 Project Effort EsFmaFon EsFmaFon involves trade offs between funcfonality, Fme and cost It is the process of assigning projected values for Fme and effort Most accurate esfmates come from experience Use case point method, based on: Technical complexity factors (13) Environmental factors (8) 9

10 Use case EsFmaFon Example Actors and Use Cases 10

11 Use case EsFmaFon Example Technical complexity factors: 11

12 Use case EsFmaFon Example Environmental factors & final esfmate: 12

13 CreaFng & Managing the Workplan Workplan: a dynamic and sequenfal list of all tasks needed to complete a project The overall objecfves for the system should be listed on the system request, and it is the project manager s job to idenffy all the taks that need to be accomplished to meet those objecfves. Approaches: Modify exisfng or completed projects Derive the tasks from the methodology being used 13

14 Staffing the Project Goals: Determine how many people are required Match skill sets to required acfvifes MoFvate the team to meet the objecfves Minimize conflicts Deliverable The staffing plan, which includes: Number & kind of people assigned Overall reporfng structure The project charter (describes the project s objecfves and rules) 14

15 CreaFng a Jelled Team A team of people so strongly knit that the whole is greater than the sum of its parts CharacterisFcs of a jelled team: Very low turnover rate Strong sense of idenfty A feeling of eliteness Team vs. individual ownership of the project Team members enjoy their work 15

16 The Staffing Plan Calculate the number of people needed: Lines of communicafon increase exponenfally as people are added to a project Create a reporfng structure for projects with large numbers of people assigned Form sub teams as necessary Assign the Project Manager, FuncFonal lead & Technical lead Pay alenfon to technical and interpersonal skills 16

17 MoFvaFng People MoFvaFon is the greatest influence on performance Monetary rewards usually do not mofvate Suggested mofvafng techniques: 20% Fme rule Peer to peer recognifon awards Team ownership (refer to the team as we ) Allow members to focus on what interests them UFlize equitable compensafon Provide for autonomy, but trust the team to deliver 17

18 Handling Conflict PrevenFng or mifgafng conflict: Cohesiveness has the greatest effect Clearly defining roles and holding team members accountable Establish work & communicafons rules in the project charter AddiFonal techniques: Clearly define plans for the project Make sure the team understands the importance of the project Develop detailed operafng procedures Develop a project charter Develop a schedule of commitments in advance Forecast other priorifes and their impact on the project 18

19 Environment & Infrastructure Management Environment Choose the right set of tools Use appropriate CASE tools to: Increase producfvity and centralize informafon (repository) UFlize diagrams more easily understood Establish standards to reduce complexity Infrastructure Document the project appropriately Store deliverables & communicafons in a project binder Don t put off documentafon to the last minute 19

20 Poor naming standards I once started a small project (4 people) in which the original members of the project team had not set up any standards for naming electronic files. Two weeks into the project, I was asked to write a piece of code that would be referenced by other files that had already been wri)en. When a finished my piece, I had to go back to the other files and make changes to reflect my new work. The only problem was that the lead programmer decided to name the files using his ini<als (e.g., GC1.prg, GC2.prg, ) and there were more than 200 files! I spent two days opening every one of those files because there was no way to tell what their contents was. Needless to say, from then on, the team created a code for file names that provided basic informa4on regarding the file s content, and kept a log that recorded the file name, its purpose, the date of the last update, and the programmer for every file on the project. 20

21 Project SelecFon Summary TradiFonal Project Management Tools EsFmaFng Project Effort Create and manage the workplan Staff the project Manage the environment and infrastructure work flows of the project 21